On Oct 21, 2011, at 3:15 AM, <[email protected]> wrote: > Brian, > > Would the following text be then ok? Please note I changed the domain > addition from SHOULD to MAY, if there is going to be attempt to > deprecate/redefine/update search list logics. Or do you think it should > remain SHOULD? > -- > 4.6. Interactions with DNS search lists > > A node may be configured with DNS search list via DHCPv6 > OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option > [RFC3397]. > > A bare name (a name without any dots) MUST be first treated as a pre- > DNS hostname or handled by other means that, as of this writing, are > under discussion in the IETF and that are out of the scope of this > document. If the bare name resolution fails, the name MAY then be > appended with the domain information. If the bare name is appended > with the domain information the described DNS server selection logic > SHALL be utilized for the resulting name.
Associating MUST with undefined behavior makes no sense at all. > Resolution for the name containing any dots SHOULD first be attempted > with DNS servers of all interfaces. Only if the resolution fails the > node MAY append the name with search list domain(s) and then again > utilize improved DNS server selection algorithm to decide which DNS > server(s) to contact. Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to searches. They should already be considered fully qualified. Just because a lookup "fails" does not mean that the name is not valid. It could fail for temporary reasons, or because the TLD server wasn't reachable. Back before there was a .CS TLD, searching on names containing dots was common. Lots of computer science departments had .CS subdomains (e.g. cs.utk.edu used to be my mail domain), and people were accustomed to being able to send mail to moore@cs or [email protected]). Once the .CS TLD was defined it became obvious that domains containing any dots should not be subject to search. Keith _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
