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 [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
