Now that more people are involved in discussions, this bare name / DNS search list area seems to look like quite a deep swamp without clear IETF consensus.
Perhaps we should discuss first if this particular topic (=section 4.6) is
needed in this document at all, because, after all, the focus is on
selecting the DNS server based on matching domains.
Best regards,
Teemu
> -----Original Message-----
> From: ext Keith Moore [mailto:mo...@network-heretics.com]
> Sent: 21. lokakuuta 2011 17:10
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: brian.e.carpen...@gmail.com; m...@ietf.org; dnsop@ietf.org;
> dns...@ietf.org; p...@isoc.de; john_brzozow...@cable.comcast.com;
> dh...@ietf.org; denghu...@hotmail.com
> Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection
> document
>
>
> On Oct 21, 2011, at 3:15 AM, <teemu.savolai...@nokia.com> 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 mo...@host.cs). Once the .CS TLD
> was defined it became obvious that domains containing any dots should not
> be subject to search.
>
> Keith
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
