[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
Thanks for your feedback, Peter; my comments in line...
- Ralph
At 08:27 PM 2/10/2003 +0100, Peter Koch wrote:
> draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for
> DHCPv6: the Domain Name Server option and the Domain Search List
> This document uses terminology specific to IPv6 and DHCPv6 as defined
> in section "Terminology" of the DHCP specification.
Might want to add an explicit normative reference here?
OK.
> 4. Domain Name Server option
>
> The Domain Name Server option provides a list of one or more IP
> addresses of DNS servers to which a client's DNS resolver MAY send
>From a purist's point of view I'm tempted to say that you're not really
looking
for a DNS server here but instead for a (list of) recursive resolvers.
Should this sentence read (I'm not a DNS purist!):
The Domain Name Server option provides a list of one or more IP
addresses of DNS recursive resolvers to which a client's DNS resolver
MAY send DNS queries [2].
> DNS-server: IP address of DNS server
(change to "DNS recursive resolver"?)
I did not follow the DHCPv6 effort too close, so I must admit not knowing
the usual "culture", but wouldn't it be better to say IPv6 address here?
Yes; also see follow up by Alain Durand.
> A server sends a Domain Search List option to the DHCP client to
> specify the domain search list the client is to use when resolving
> hostnames with DNS. This option does not apply to other name
> resolution mechanisms.
The draft does not say for which kind of domain names the client is expected
to process the list, i.e. one-label names only, n-label names (how to
communicate the 'n', aka 'ndots', then?) or whether this is left to the
application(s).
> Because the Domain Search List option may be used to spoof DNS name
> resolution in a way that cannot be detected by DNS security
> mechanisms like DNSSEC [5], DHCP clients and servers MUST use
Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it
wouldn't be able to detect spoofing. If, however, you want to say that
using domain names in the search list you don't control is a dangerous
thing, that could be emphazised by a reference to RFC 1535.
The idea here (note that I'm not a DNSSEC expert, either) is that
a search list that the host doesn't control might still pass DNSSEC
authentication while yielding unexpected results.
I would be happy to hear that DNSSEC can prevent the problem and would
be willing to follow your suggestion and replace the reference to
DNSSEC with a more general reference to untrusted search lists.
> authenticated DHCP when a Domain Search List option is included in a
> DHCP message.
Why is this a MUST while there's a SHOULD only for the server option?
They probably both should have the same level of requirement; I would
think SHOULD would be sufficient for both.
-Peter
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>