Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
Teemu, I think that the spirit of what you propose is correct, but as Keith points out it really isn't appropriate to use RFC 2119 language about a pragmatic approach that clearly lies outside the definition of the DNS namespace. If an implementor is willing to take the risk of transforming www.example into www.example.com, because at the time of writing there is no TLD "example", that's the implementor's risk, but it shouldn't be dignified with normative keywords IMHO. Regards Brian Carpenter On 2011-10-21 20:15, 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. > >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. > -- > > Best regards, > > Teemu > >> -Original Message- >> From: ext Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >> Sent: 21. lokakuuta 2011 00:50 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: ray.bel...@nominet.org.uk; 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 >> >> Teemu, >> >> I don't believe this is a topic where consensus in MIF is very relevant. >> It needs to be decided in a much wider community rather than as a subsidiary >> question in a MIF document. I suggest leaving it FFS (for further study) in >> MIF. >> >> Regards >>Brian Carpenter >> >> On 2011-10-20 20:01, teemu.savolai...@nokia.com wrote: >>> Hi Ray, >>> -Original Message- From: ext Ray Bellis [mailto:ray.bel...@nominet.org.uk] Sent: 19. lokakuuta 2011 13:40 To: Savolainen Teemu (Nokia-CTO/Tampere) Cc: ; ; ; ; ; ; Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection document I have concerns about §4.6: "A bare name (a name without any dots) MUST be first treated as a pre- >>> DNS hostname, and only after that the name SHALL be appended with domain information and described DNS server selection logic be utilized." When new gTLDs are introduced it is likely for brand-name gTLDs that they will wish to use bare names in the DNS (i.e. a single label hostname) for >>> their primary web sites. Hence bare names may become much more frequently used as DNS >> names, and §4.6 wouldn't permit those to work unless '.' is also in the suffix >>> list. I'd like to hear the authors' thoughts on these. I'm not sure that this >>> draft necessarily needs any significant changes - it may only require changes to ensure that bare names are also considered as potential DNS names in their own right. >>> Okay, I understand there is no clear consensus yet how these single >>> label names should be handled by the resolvers at the first place? >>> Should resolver first treat them as pre-DNS hostnames, then as DNS >>> hostnames, and then try search list? The DNS server selection logic >>> would be applied already when resolving single label name, i.e. the >>> network could provide a single label domain "brand" in the domains list. >>> >>> Maybe section 4.6 could be like this, perhaps (changes in second >>> paragraph and title)? >>> -- >>> 4.6. Interactions with DNS search lists and single label hostnames >>> >>>A node may be configured with DNS search list by DHCPv6 >>>OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >>>[RFC3397]. >>> >>>A bare name (a name without any dots) MUST be first treated as a pre- >>>DNS hostname, after which resolution of the name SHALL be attempted >>>with DNS, and as a last resort the name SHALL be appended with >>>domain information. DNS server selection logic SHALL be >>>utilized for both of the latter two DNS using
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
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, 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
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
On Oct 21, 2011, at 3:15 AM, 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
On 21 Oct 2011, at 08:21, wrote: > Do you agree that nodes' behavioral differences between "foo" and "foo." > names is out of the scope of this particular MIF draft? In my view neither the draft nor MIF should be encoding any changes to client name resolution behaviour that depend on the "bareness" of a supplied name. Existing OSes have many varying algorithms for deciding which name service(s) to use to resolve any particular name, some of which have user-configurable knobs (e.g. "options: ndots" in /etc/resolv.conf). By all means use server selection once the OS has decided that "DNS" is the correct name service, but that algorithm shouldn't IMHO impact or otherwise specify the prior name service selection algorithm. > There could perhaps be another draft, which would say that if name is "foo" > it should not be appended with search lists but "foo." might? If anything it would be the other way around - 'foo.' is explicitly already full qualified, and MUST NOT be appended with search lists. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
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. 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. -- Best regards, Teemu > -Original Message- > From: ext Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: 21. lokakuuta 2011 00:50 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: ray.bel...@nominet.org.uk; 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 > > Teemu, > > I don't believe this is a topic where consensus in MIF is very relevant. > It needs to be decided in a much wider community rather than as a subsidiary > question in a MIF document. I suggest leaving it FFS (for further study) in > MIF. > > Regards >Brian Carpenter > > On 2011-10-20 20:01, teemu.savolai...@nokia.com wrote: > > Hi Ray, > > > >> -Original Message- > >> From: ext Ray Bellis [mailto:ray.bel...@nominet.org.uk] > >> Sent: 19. lokakuuta 2011 13:40 > >> To: Savolainen Teemu (Nokia-CTO/Tampere) > >> Cc: ; ; ; > >> ; ; ; > >> > >> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server > >> selection document > >> > >> I have concerns about §4.6: > >> > >> "A bare name (a name without any dots) MUST be first treated as a > >> pre- > > DNS > >> hostname, and only after that the name SHALL be appended with domain > >> information and described DNS server selection logic be utilized." > >> > >> When new gTLDs are introduced it is likely for brand-name gTLDs that > >> they will wish to use bare names in the DNS (i.e. a single label > >> hostname) for > > their > >> primary web sites. > >> > >> Hence bare names may become much more frequently used as DNS > names, > >> and §4.6 wouldn't permit those to work unless '.' is also in the > >> suffix > > list. > >> I'd like to hear the authors' thoughts on these. I'm not sure that > >> this > > draft > >> necessarily needs any significant changes - it may only require > >> changes to ensure that bare names are also considered as potential > >> DNS names in their own right. > > > > Okay, I understand there is no clear consensus yet how these single > > label names should be handled by the resolvers at the first place? > > Should resolver first treat them as pre-DNS hostnames, then as DNS > > hostnames, and then try search list? The DNS server selection logic > > would be applied already when resolving single label name, i.e. the > > network could provide a single label domain "brand" in the domains list. > > > > Maybe section 4.6 could be like this, perhaps (changes in second > > paragraph and title)? > > -- > > 4.6. Interactions with DNS search lists and single label hostnames > > > >A node may be configured with DNS search list by DHCPv6 > >OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option > >[RFC3397]. > > > >A bare name (a name without any dots) MUST be first treated as a pre- > >DNS hostname, after which resolution of the name SHALL be attempted > >with DNS, and as a last resort the name SHALL be appended with > >domain information. DNS server selection logic SHALL be > >utilized for both of the latter two DNS using methods. > > > >Resolution for the name containing any dots SHOULD first be attempted > >with DNS servers of all interfaces. Only if the resolution fails the > >node SHOULD 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. > > -- > > > > Best regards, > > > > Teemu > > > > > > > > -- > > -- > > > > ___ > > mif mailing list > > m...@ietf.org > > https://www.ietf.org/mailman/listinfo/mif smi
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
It might that IETF should consider "bare names" out of its scope, except perhaps to say that they're not DNS names, they don't have to necessarily be mappable to DNS names, and that their use and behavior is host and application-dependent. Keith On Oct 20, 2011, at 5:50 PM, Brian E Carpenter wrote: > Teemu, > > I don't believe this is a topic where consensus in MIF is very relevant. > It needs to be decided in a much wider community rather than as a subsidiary > question in a MIF document. I suggest leaving it FFS (for further study) > in MIF. > > Regards > Brian Carpenter > > On 2011-10-20 20:01, teemu.savolai...@nokia.com wrote: >> Hi Ray, >> >>> -Original Message- >>> From: ext Ray Bellis [mailto:ray.bel...@nominet.org.uk] >>> Sent: 19. lokakuuta 2011 13:40 >>> To: Savolainen Teemu (Nokia-CTO/Tampere) >>> Cc: ; ; ; >>> ; ; ; >>> >>> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection >>> document >>> >>> I have concerns about §4.6: >>> >>> "A bare name (a name without any dots) MUST be first treated as a pre- >> DNS >>> hostname, and only after that the name SHALL be appended with domain >>> information and described DNS server selection logic be utilized." >>> >>> When new gTLDs are introduced it is likely for brand-name gTLDs that they >>> will wish to use bare names in the DNS (i.e. a single label hostname) for >> their >>> primary web sites. >>> >>> Hence bare names may become much more frequently used as DNS names, >>> and §4.6 wouldn't permit those to work unless '.' is also in the suffix >> list. >>> I'd like to hear the authors' thoughts on these. I'm not sure that this >> draft >>> necessarily needs any significant changes - it may only require changes to >>> ensure that bare names are also considered as potential DNS names in their >>> own right. >> >> Okay, I understand there is no clear consensus yet how these single label >> names should be handled by the resolvers at the first place? Should resolver >> first treat them as pre-DNS hostnames, then as DNS hostnames, and then try >> search list? The DNS server selection logic would be applied already when >> resolving single label name, i.e. the network could provide a single label >> domain "brand" in the domains list. >> >> Maybe section 4.6 could be like this, perhaps (changes in second paragraph >> and title)? >> -- >> 4.6. Interactions with DNS search lists and single label hostnames >> >> A node may be configured with DNS search list by DHCPv6 >> OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >> [RFC3397]. >> >> A bare name (a name without any dots) MUST be first treated as a pre- >> DNS hostname, after which resolution of the name SHALL be attempted >> with DNS, and as a last resort the name SHALL be appended with >> domain information. DNS server selection logic SHALL be >> utilized for both of the latter two DNS using methods. >> >> Resolution for the name containing any dots SHOULD first be attempted >> with DNS servers of all interfaces. Only if the resolution fails the >> node SHOULD 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. >> -- >> >> Best regards, >> >> Teemu >> >> >> >> >> >> ___ >> mif mailing list >> m...@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > > ___ > mif mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mif ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
Teemu, I don't believe this is a topic where consensus in MIF is very relevant. It needs to be decided in a much wider community rather than as a subsidiary question in a MIF document. I suggest leaving it FFS (for further study) in MIF. Regards Brian Carpenter On 2011-10-20 20:01, teemu.savolai...@nokia.com wrote: > Hi Ray, > >> -Original Message- >> From: ext Ray Bellis [mailto:ray.bel...@nominet.org.uk] >> Sent: 19. lokakuuta 2011 13:40 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: ; ; ; >> ; ; ; >> >> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection >> document >> >> I have concerns about §4.6: >> >> "A bare name (a name without any dots) MUST be first treated as a pre- > DNS >> hostname, and only after that the name SHALL be appended with domain >> information and described DNS server selection logic be utilized." >> >> When new gTLDs are introduced it is likely for brand-name gTLDs that they >> will wish to use bare names in the DNS (i.e. a single label hostname) for > their >> primary web sites. >> >> Hence bare names may become much more frequently used as DNS names, >> and §4.6 wouldn't permit those to work unless '.' is also in the suffix > list. >> I'd like to hear the authors' thoughts on these. I'm not sure that this > draft >> necessarily needs any significant changes - it may only require changes to >> ensure that bare names are also considered as potential DNS names in their >> own right. > > Okay, I understand there is no clear consensus yet how these single label > names should be handled by the resolvers at the first place? Should resolver > first treat them as pre-DNS hostnames, then as DNS hostnames, and then try > search list? The DNS server selection logic would be applied already when > resolving single label name, i.e. the network could provide a single label > domain "brand" in the domains list. > > Maybe section 4.6 could be like this, perhaps (changes in second paragraph > and title)? > -- > 4.6. Interactions with DNS search lists and single label hostnames > >A node may be configured with DNS search list by DHCPv6 >OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option >[RFC3397]. > >A bare name (a name without any dots) MUST be first treated as a pre- >DNS hostname, after which resolution of the name SHALL be attempted >with DNS, and as a last resort the name SHALL be appended with >domain information. DNS server selection logic SHALL be >utilized for both of the latter two DNS using methods. > >Resolution for the name containing any dots SHOULD first be attempted >with DNS servers of all interfaces. Only if the resolution fails the >node SHOULD 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. > -- > > Best regards, > > Teemu > > > > > > ___ > mif mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mif ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document
On Oct 19, 2011, at 6:39 AM, Ray Bellis wrote: > > When new gTLDs are introduced it is likely for brand-name gTLDs that they > will wish to use bare names in the DNS (i.e. a single label hostname) for > their primary web sites. I don't see why IETF should give a flying *#&(*#$ what the owners of brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid idea, and treating single label names as anything other than local abbreviations flies in the face of 25+ years of practice. The best thing that IETF could do is to make sure that use of single-label gTLDs is so unreliable that no megacorporation would dare use them. Keith ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
