[pkg-dhcp-devel] Bug#516200: dhcp3-common: dhcp-eval update, .SH SECURITY
apollock at debian.org
Sun Jul 25 17:11:10 UTC 2010
This bug (and patch) was sent to us some time ago.
Please maintain the Cc to keep our BTS in the loop.
On Thu, Feb 19, 2009 at 12:37:24PM -0700, Justin T Pryzby wrote:
> Package: dhcp3-common
> Version: 3.0.6.dfsg-1ubuntu9
> Severity: normal
> Tags: patch
> File: /usr/share/man/man5/dhcp-eval.5.gz
> The SECURITY section is bogus. See dhcpd.conf for the updated
> content (which probably shouldn't be duplicated here).
> --- /usr/share/man/man5/dhcp-eval.5.gz
> +++ - 2009-02-19 12:36:06.026375979 -0700
> @@ -433,25 +433,16 @@
> how you want the Domain Name System to be updated. These updates are
> RFC 2136 compliant so any DNS server supporting RFC 2136 should be
> able to accept updates from the DHCP server.
> -.SH SECURITY
> -Support for TSIG and DNSSEC is not yet available. When you set your
> -DNS server up to allow updates from the DHCP server or client, you may
> -be exposing it to unauthorized updates. To avoid this, the best you
> -can do right now is to use IP address-based packet filtering to
> -prevent unauthorized hosts from submitting update requests.
> -Obviously, there is currently no way to provide security for client
> -updates - this will require TSIG or DNSSEC, neither of which is yet
> -available in the DHCP distribution.
> Dynamic DNS (DDNS) updates are performed by using the \fBdns-update\fR
> expression. The \fBdns-update\fR expression is a boolean expression
> that takes four parameters. If the update succeeds, the result is
> -true. If it fails, the result is false. The four parameters that the
> -are the resource record type (RR), the left hand side of the RR, the
> -right hand side of the RR and the ttl that should be applied to the
> +true. If it fails, the result is false. There are four parameters:
> +the resource record type (RR), the left hand side of the RR, the
> +right hand side of the RR, and the ttl that should be applied to the
> record. The simplest example of the use of the function can be found
> in the reference section of the dhcpd.conf file, where events are
> -described. In this example several statements are being used to make
> +described. In this example, several statements are being used to make
> the arguments to the \fBdns-update\fR.
> In the example, the first argument to the first \f\Bdns-update\fR
> @@ -460,7 +451,7 @@
> option with a text string containing the local domain, in this case
> "ssd.example.net". The third argument is constructed by converting
> the address the client has been assigned from a 32-bit number into an
> -ascii string with each byte separated by a ".". The fourth argument,
> +ASCII string with each byte separated by a ".". The fourth argument,
> the TTL, specifies the amount of time remaining in the lease (note
> that this isn't really correct, since the DNS server will pass this
> TTL out whenever a request comes in, even if that is only a few
> @@ -468,10 +459,10 @@
> If the first \fBdns-update\fR statement succeeds, it is followed up
> with a second update to install a PTR RR. The installation of a PTR
> -record is similar to installing an A RR except that the left hand side
> -of the record is the leased address, reversed, with ".in-addr.arpa"
> -concatenated. The right hand side is the fully qualified domain name
> -of the client to which the address is being leased.
> +record is similar to installing an A RR, except that the left hand
> +side of the record is the leased address, reversed, with
> +".in-addr.arpa" suffixed. The right hand side is the fully qualified
> +domain name of the client to which the address is being leased.
> .SH SEE ALSO
> dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-options(5), dhcpd(8),
> dhclient(8), RFC2132, RFC2131.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 827 bytes
Desc: Digital signature
More information about the pkg-dhcp-devel