Re: [DNSOP] [Dailydave] DNS Poisoning via Port Exhaustion (fwd)
Paul Wouters; I think the following ID solves the problem. http://www.ietf.org/id/draft-ohta-practically-secure-dns-00.txt Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Oct 24, 2011, at 2:08 AM, sth...@nethelp.no wrote: >>> I can't agree with this statement. As others have said, the practice of >>> using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' >>> isn't going anywhere, and there are a lot of people that make extensive use >>> of the convenience. >> >> It needs to die because it's fundamentally broken. Vanity TLDs will only >> make it worse. I understand that there are sites that use it and people >> who are accustomed to it. I don't pretend that we can stop them. We can, >> however, explain the negative consequences of doing this (some of which >> might be specific to systems with multiple interfaces), and recommend that >> they transition away from that practice. And recommendations for systems >> with multiple interfaces can be chosen in such a way as to allow search >> lists to break even more. > > I routinely use short names (and thus search lists) in my work. I am > aware of vanity domains, and of RFC 1535. Have I stopped using short > names and search lists? No, the convenience is just too great. > > In trying to stop the use of short names and search lists I believe > you're trying to fight human nature. It's a waste of time, and unlikely > to be productive. Just to be clear, I'm not trying to forbid the use of search lists with "bare" (single-label) names. I'm just pointing out that for the vast majority of the contexts in which domain names are used, the expectation is that a domain name that contains a "." is fully-qualified. The need for domain names to behave consistently from one host to another and one application to another is much, much more important, than the need to apply search lists to queries of domain names that contain "."s. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
--On 24 October 2011 06:53:05 -0400 Keith Moore wrote: I'm just pointing out that for the vast majority of the contexts in which domain names are used, the expectation is that a domain name that contains a "." is fully-qualified. This is sampling bias. In the vast majority of contexts where domain names (term used loosely) are used, those domain names contain at least one dot. In the vast majority of contexts where domain names (term used loosely) are used, those domain names are fully qualified. It is therefore statistically unsurprising that in the vast majority of contexts where domain with a dot in them, are used they are fully qualified. The question here should be "where search lists are used, are they frequently used in combination with domain names that are not fully qualified". I would suggest the answer to this question is "yes". If so, then to the extent that search lists are supported, you need to make them interwork names with dots in them. Moreover, with a search list of "example.com", having "mail" work, but not "mail.dev" is going to be a pretty surprising outcome. I think the two options are either deprecating search lists (or not supporting them), or supporting them properly, in which case they must be used whatever domain name is specified, and the way to avoid using a search list is the same old hack as before (i.e. putting a dot on the end). -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
--On 22 October 2011 19:41:58 + Ted Lemon wrote: Yes. But if a bare name is used, a bogus search list can also bypass DNSSEC validation. For the hard of understanding, please could you expand on this? Doesn't the client know the full name being looked up, even with a search list? -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Oct 24, 2011, at 7:19 AM, Alex Bligh wrote: > --On 24 October 2011 06:53:05 -0400 Keith Moore > wrote: > >> I'm just pointing out that for the vast majority of the contexts in which >> domain names are used, the expectation is that a domain name that >> contains a "." is fully-qualified. > > This is sampling bias. No, I don't think so. The vast majority of contexts where domain names are used, are contexts in which the domain is supplied by one party and (at least potentially) used by another party. Email addresses, URLs, domain names written on advertisements and business cards, etc. > The question here should be "where search lists are used, are > they frequently used in combination with domain names that > are not fully qualified". I would suggest the answer to this > question is "yes". That's not a useful way to phrase the question, because there's no way for software to know whether or not the user intends that a name containing "." is fully-qualified. > If so, then to the extent that search lists > are supported, you need to make them interwork names with > dots in them. Moreover, with a search list of "example.com", > having "mail" work, but not "mail.dev" is going to be a > pretty surprising outcome. It will be surprising to that relatively small portion of users that relies on search lists being applied to multi-label names. But overall, having a clear, visible distinction between names for which searching is potentially applied (i.e. bare or single-label names), and names for which searching is not applied (multi-label names) results in less surprising behavior for everyone. > I think the two options are either deprecating search lists > (or not supporting them), or supporting them properly, in > which case they must be used whatever domain name is > specified, and the way to avoid using a search list > is the same old hack as before (i.e. putting a dot on the > end). Supporting search lists "properly" is NOT using them whenever a domain name is specified. That makes all domain names context-sensitive, and breaks every application that uses domain names supplied by other parties or in other contexts. Keith ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
--On 24 October 2011 07:29:55 -0400 Keith Moore wrote: I'm just pointing out that for the vast majority of the contexts in which domain names are used, the expectation is that a domain name that contains a "." is fully-qualified. This is sampling bias. No, I don't think so. The vast majority of contexts where domain names are used, are contexts in which the domain is supplied by one party and (at least potentially) used by another party. Email addresses, URLs, domain names written on advertisements and business cards, etc. Of course, but that explicitly excludes every case where a search list is useful. That's why I'm saying you have to look at the cases were a search list is used. In large organisations "domain names" (used loosely) can have dots in and be expected to have search list items appended. Given search list use is rare, it's obviously going to be rare to have them with dots. The question here should be "where search lists are used, are they frequently used in combination with domain names that are not fully qualified". I would suggest the answer to this question is "yes". That's not a useful way to phrase the question, because there's no way for software to know whether or not the user intends that a name containing "." is fully-qualified. You are begging the question. Of course the name "foo.bar" is ambiguous. That's precisely /why/ there is a search list, so foo.bar is only looked up if foo.bar.example.com (or whatever) does not exist. The existence of the "if" step means that the software cannot know what the domain means (in the sense of what it will ultimately resolve to) without doing a lookup. If so, then to the extent that search lists are supported, you need to make them interwork names with dots in them. Moreover, with a search list of "example.com", having "mail" work, but not "mail.dev" is going to be a pretty surprising outcome. It will be surprising to that relatively small portion of users that relies on search lists being applied to multi-label names. But overall, having a clear, visible distinction between names for which searching is potentially applied (i.e. bare or single-label names), and names for which searching is not applied (multi-label names) results in less surprising behavior for everyone. I do not think you have established that a relatively small number of users of search lists use multi-label names. I suspect that is not true. I think the two options are either deprecating search lists (or not supporting them), or supporting them properly, in which case they must be used whatever domain name is specified, and the way to avoid using a search list is the same old hack as before (i.e. putting a dot on the end). Supporting search lists "properly" is NOT using them whenever a domain name is specified. That makes all domain names context-sensitive, and breaks every application that uses domain names supplied by other parties or in other contexts. I don't have RFC references to hand, but precisely for the reasons you have set out above, I do not believe there is anything within them that search lists should only be used if "a domain name is specified", precisely because it's impossible to tell whether a string with dots in it is "a domain name", or merely something to go on the front of search lists. What you are, I think, saying, is that you want to change the behaviour of search lists so they only work with single labels. What I'm saying is that there are likely to be a significant number of users of search lists who are affected by that, as they currently pass things with dots in them. A completely unscientific analysis I know, but every internet company I have worked with since we moved out of uucp naming has done this, and not because I have told them to. Even current 20 person software house does this. So, if you are going to substantially break search lists (which is not inherently a bad idea - they have caused all sorts of trouble in times past), you might as well just deprecate them or not support them. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Oct 24, 2011, at 7:55 AM, Alex Bligh wrote: > > > --On 24 October 2011 07:29:55 -0400 Keith Moore > wrote: > > I'm just pointing out that for the vast majority of the contexts in which domain names are used, the expectation is that a domain name that contains a "." is fully-qualified. >>> >>> This is sampling bias. >> >> No, I don't think so. The vast majority of contexts where domain names >> are used, are contexts in which the domain is supplied by one party and >> (at least potentially) used by another party. Email addresses, URLs, >> domain names written on advertisements and business cards, etc. > > Of course, but that explicitly excludes every case where a search > list is useful. That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. The presence or absence of a '.' is a simple and easily-understood convention. It might be somewhat inconvenient for large organizations that currently rely on search lists for multi-label names, but overall that's a small price to pay in exchange for having consistent behavior of domain names across the board. The only reason that those organizations have managed to get away with it so far is that TLDs (particularly TLDs with more than 2 characters) have been relatively few in number. But with vanity TLDs this will no longer be the case. >>> The question here should be "where search lists are used, are >>> they frequently used in combination with domain names that >>> are not fully qualified". I would suggest the answer to this >>> question is "yes". >> >> That's not a useful way to phrase the question, because there's no way >> for software to know whether or not the user intends that a name >> containing "." is fully-qualified. > > You are begging the question. Of course the name "foo.bar" is > ambiguous. No, it's not ambiguous. It's fully qualified. > That's precisely /why/ there is a search list, so > foo.bar is only looked up if foo.bar.example.com (or whatever) > does not exist. That's insane. That allows a local enterprise to change the meaning of every domain name. Domain names are supposed to have the same meaning everywhere in the Internet. >>> If so, then to the extent that search lists >>> are supported, you need to make them interwork names with >>> dots in them. Moreover, with a search list of "example.com", >>> having "mail" work, but not "mail.dev" is going to be a >>> pretty surprising outcome. >> >> It will be surprising to that relatively small portion of users that >> relies on search lists being applied to multi-label names. But overall, >> having a clear, visible distinction between names for which searching is >> potentially applied (i.e. bare or single-label names), and names for >> which searching is not applied (multi-label names) results in less >> surprising behavior for everyone. > > I do not think you have established that a relatively small number > of users of search lists use multi-label names. I suspect that > is not true. My assumption is that search lists in conjunction with multi-label names are mostly used within fairly large enterprises, but search lists are potentially in much wider use. >>> I think the two options are either deprecating search lists >>> (or not supporting them), or supporting them properly, in >>> which case they must be used whatever domain name is >>> specified, and the way to avoid using a search list >>> is the same old hack as before (i.e. putting a dot on the >>> end). >> >> Supporting search lists "properly" is NOT using them whenever a domain >> name is specified. That makes all domain names context-sensitive, and >> breaks every application that uses domain names supplied by other parties >> or in other contexts. > > I don't have RFC references to hand, but precisely for the reasons you have > set out above, I do not believe there is anything within them that search > lists should only be used if "a domain name is specified", precisely > because it's impossible to tell whether a string with dots in it is "a > domain name", or merely something to go on the front of search lists. > > What you are, I think, saying, is that you want to change the behaviour of > search lists so they only work with single labels. What I'm saying is that > there are likely to be a significant number of users of search lists who > are affected by that, as they currently pass things with dots in them. No disagreement on that point. But search lists always have been broken. It's just unfortunate that DNS APIs have supported them for so long, and their behavior has become entrenched in several organizations (including some that ought to know better). My belief is that local names (i.e. bare or single-label names) are useful and necessary but their beh
Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On 10/23/2011 7:49 PM, Mark Andrews wrote: > > In message <96472fb7-8425-4928-8f55-2abf2cb59...@conundrum.com>, Matthew > Pounse > tt writes: >> >> On 2011/10/22, at 15:21, Keith Moore wrote: >> >>> >>> On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: >>> 1. I think we're all in agreement that dot-terminated names (e.g., example.) should not be subject to search lists. I personally don't have any problems with any document mentioning that this is the expected behavior. >>> >>> agree. however there are standard protocols for which a trailing dot in a >> domain name is a syntax error. >> >> Any protocol that makes a standard FQDN a syntax error is itself in error. N >> ot to say that these don't exist, but if people are writing protocols that ca >> n't deal with a properly formatted FQDN they need to stop. Now. > > Except it isn't a standard hostname. Periods *seperate* labels in > hostnames RFC 952. They DO NOT appear at the end of hostnames. > > Appending a period to the end of a name is user interface hack to > prevent searching. If is also a way to prevent the appending of > the current origin to all names in a DNS master file as the current > origin is always appended if it isn't done. > > In addition single labels are not HEIRACHICAL / DOMAIN STYLE names > as envisioned when we went from a flat namespace of simple hostnames > to a heirarchical namespace. > > foo.bar is a heirachical hostname. > bar is a simple hostname. > > Why are we trying to bring them back on a global context? I'm not even sure why we are having this discussion. You are right, of course. DNS doesn't know anything about search lists, nor does it care. Any valid string presented to DNS is by definition a FQDN and DNS will proceed accordingly. If the application choosing to consult a domain search list it's up to that application, but DNS is not involved in the consultation. Danny ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > On 10/24/2011 05:16, Keith Moore wrote: >> That's the point - search lists are not appropriate most of the time, and >> it's very hard for software to distinguish the cases where they are >> potentially appropriate from the cases when they're not, and it's not >> possible for software to do this in all cases. > > There's been something missing from this discussion, and I finally put > my finger on it. TMK most stub resolvers have an option similar to this > one from ISC's: > > ndots:n >sets a threshold for the number of dots which >must appear in a name given to res_query() (see >resolver(3)) before an initial absolute query >will be made. The default for n is “1”, mean‐ >ing that if there are any dots in a name, the >name will be tried first as an absolute name >before any search list elements are appended to >it. > > So it seems that this question is already a matter of local policy, > which given the number and quality of the divergent views seems > eminently reasonable. Can we move on now? No, because relying on "local policy" is not sufficient for interoperability. I think there's a need for IETF to document why any other value than 1 is a Bad Idea, and more to the point, why it will break things.The problem isn't entirely specific to hosts with multiple interfaces. But given that using multiple interfaces makes the problem worse, MIF might want to take on some of the work of documenting why it will break things. Keith ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On 10/24/2011 05:16, Keith Moore wrote: > That's the point - search lists are not appropriate most of the time, and > it's very hard for software to distinguish the cases where they are > potentially appropriate from the cases when they're not, and it's not > possible for software to do this in all cases. There's been something missing from this discussion, and I finally put my finger on it. TMK most stub resolvers have an option similar to this one from ISC's: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. The default for n is “1”, mean‐ ing that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. So it seems that this question is already a matter of local policy, which given the number and quality of the divergent views seems eminently reasonable. Can we move on now? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On 10/24/2011 13:58, Keith Moore wrote: > > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > >> On 10/24/2011 05:16, Keith Moore wrote: >>> That's the point - search lists are not appropriate most of the time, and >>> it's very hard for software to distinguish the cases where they are >>> potentially appropriate from the cases when they're not, and it's not >>> possible for software to do this in all cases. >> >> There's been something missing from this discussion, and I finally put >> my finger on it. TMK most stub resolvers have an option similar to this >> one from ISC's: >> >> ndots:n >>sets a threshold for the number of dots which >>must appear in a name given to res_query() (see >>resolver(3)) before an initial absolute query >>will be made. The default for n is “1”, mean‐ >>ing that if there are any dots in a name, the >>name will be tried first as an absolute name >>before any search list elements are appended to >>it. >> >> So it seems that this question is already a matter of local policy, >> which given the number and quality of the divergent views seems >> eminently reasonable. Can we move on now? > > No, because relying on "local policy" is not sufficient for interoperability. I don't see how local resolution issues feed into interoperability here. > I think there's a need for IETF to document why any other value than 1 is a > Bad Idea, and more to the point, why it will break things.The problem > isn't entirely specific to hosts with multiple interfaces. But given that > using multiple interfaces makes the problem worse, MIF might want to take on > some of the work of documenting why it will break things. That seems to be an opinion of yours that isn't widely shared. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
Hi there Doug, Keith, folks, Speaking of broken mechanisms ... how many dots? arstechnica.com is OK co.uk is not OK ndots strikes me as a chocolate soldier in the fire used to warm the chocolate teapot that is search lists. At best these are context dependent (and keep IT support in business). At worst ... one day I WILL be arrested for tazering the bean counter (why is it always one of those?) who insists that "intranet" is a fine web server name useful anywhere. [I came damn close a few times with Yankee hotel reservations accessible only via 1-800 'phone numbers] Speaking of interoperability -- the comment "it works for everyone here" is not a good sign that the solution is interoperable. IMO, search lists and ndots are both abominations, and should not be given the oxygen of publicity. all the best, Lawrence On 24 Oct 2011, at 21:52, Doug Barton wrote: > On 10/24/2011 05:16, Keith Moore wrote: >> That's the point - search lists are not appropriate most of the time, and >> it's very hard for software to distinguish the cases where they are >> potentially appropriate from the cases when they're not, and it's not >> possible for software to do this in all cases. > > There's been something missing from this discussion, and I finally put > my finger on it. TMK most stub resolvers have an option similar to this > one from ISC's: > > ndots:n >sets a threshold for the number of dots which >must appear in a name given to res_query() (see >resolver(3)) before an initial absolute query >will be made. The default for n is “1”, mean‐ >ing that if there are any dots in a name, the >name will be tried first as an absolute name >before any search list elements are appended to >it. > > So it seems that this question is already a matter of local policy, > which given the number and quality of the divergent views seems > eminently reasonable. Can we move on now? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote: >>> So it seems that this question is already a matter of local policy, >>> which given the number and quality of the divergent views seems >>> eminently reasonable. Can we move on now? >> >> No, because relying on "local policy" is not sufficient for interoperability. > > For interoperability, one can use absolute names, with the trailing dot, uh, no. Names with trailing dots aren't allowed in many contexts. And in some of the contexts in which they are allowed, they get "canonicalized" to names without trailing dots. > or specify that in the context of whatever protocol, all names are to be > taken as relative to the root, or use other than a printed > representation. ...so a DNS name means different things in one context than in another. Bad Idea. > In some cases this may require that implementations use > resolver interfaces which make it clear that a name to be resolved is > absolute, or that they append the empty label to relative names before > passing them on to the resolver. > > On the other hand, in user interface, which is primarily where relative > names are intended to be used, local policy is quite sufficient. no. Domain names are written on buses, billboards, business cards. They do get transcribed, quite often actually, and they need to have the same meanings when typed in as they do when clicked on. In a small number of cases, where a user gets immediate feedback after he types in the name and before a host attempts to contact a server, it might be sufficient to "canonicalize" a name, show the user how the name will actually be interpreted, and let him click "ok" before contacting the server. But even then, what if the "canonicalization" is wrong? How is the user supposed to know how to tell the software to treat the name as an FQDN? If he types in the '.', the dot will disappear when the name is canonicalized. That's not exactly effective reinforcement. It says to the user "you should not have typed in that final dot". And the practice of not using a trailing "." is nearly universal. Changing that practice is much harder than changing from IPv4 and IPv6. Some people are working way too hard to try to save something that was never a good idea in the first place. I'm not arguing that all software that currently applies searching to names with dots in them has to die a violent death, and immediately either be updated or deleted from all computers everywhere (as if...). I'm just saying that IETF should recommend against the practice of using search lists with multi-label names, and document the harm that it does. Sites can still do it if they want to, or they can manage their own transitions away from using search paths for such names, on their own timeframes. After all, this has been a practice for ~30 years in some places, nobody should expect it all to change overnight. > As long as I and the software on my machine agree on what a name I type > means, it's none of the IETF's business. (So what? It's also none of IETF's business if you ___ < pick anything that is utterly senseless here) Of course, you can do whatever you want. But IETF should promote practices that make good sense, even though we realize that some people will decide for themselves to not follow them. > Can an enterprise change the name of every domain name? On machines > they control, yes. Of course they can. But it makes absolutely no sense for IETF to bless that practice or to ignore it when we know that it does harm. The presumption of the standards is that you want your machines to interoperate with other machines. If you don't want interoperability, have a day - screw things up however you want. (as long as you only affect your own machines, of course.). Nobody's forcing you to keep your machines conforming. > While I agree wholeheartedly with the notion of a unique domain name > space, I also believe that mapping a relative or abbreviated name onto > that namespace is _entirely_ a matter of local policy. That's a convenient philosophy if you _only_ care that local things interoperate with one another. > It is perhaps > appropriate for the IETF to provide mechanisms for distributing that > policy, for those who wish to use them, but not to dictate what the > policy must be. IETF's job is to help the Internet work, not to endorse every bit of local brain damage that people are attached to. > Do things get worse as new TLDs appear? Yes, sometimes. Be prepared for it to happen more often. Do you really want to rethink your naming scheme every time someone creates a vanity TLD that happens to collide with some subdomain of cmu.edu? Even if that's only once every year or three, how often does it need to happen before it's no longer worth the trouble? I mean, I'm sure that the relevant people at CMU are quite capable of evaluating that decision for thems
Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
In message , Lawrence Con roy writes: > Hi there Doug, Keith, folks, > Speaking of broken mechanisms ... how many dots? > arstechnica.com is OK > co.uk is not OK > > ndots strikes me as a chocolate soldier in the fire used to warm the > chocolate teapot that is search lists. > > At best these are context dependent (and keep IT support in business). At > worst ... > one day I WILL be arrested for tazering the bean counter (why is it > always one of > those?) who insists that "intranet" is a fine web server name useful > anywhere. > > [I came damn close a few times with Yankee hotel reservations accessible > only via > 1-800 'phone numbers] > > Speaking of interoperability -- the comment "it works for everyone here" > is not > a good sign that the solution is interoperable. > > IMO, search lists and ndots are both abominations, and should not be > given the oxygen of publicity. > > all the best, > Lawrence > > > > On 24 Oct 2011, at 21:52, Doug Barton wrote: > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, > and it's very hard for software to distinguish the cases where they are > potentially appropriate from the cases when they're not, and it's not > possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > >sets a threshold for the number of dots which > >must appear in a name given to res_query() (see > >resolver(3)) before an initial absolute query > >will be made. The default for n is â1â, meanâ > >ing that if there are any dots in a name, the > >name will be tried first as an absolute name > >before any search list elements are appended to > >it. > > > > So it seems that this question is already a matter of local policy, > > which given the number and quality of the divergent views seems > > eminently reasonable. Can we move on now? > > ___ > dnsext mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext In many cases when ndots is not 1 there are no DNS entries that will match .. That said the set of is growing so it is going to get harder and harder to ensure that this condition is being met. Walled gardens shouldn't be creating their own TLDs. ISP's, hotspots, etc. should not be search list at all. The definitely should not be relying on "label" being found on a search list. As far as I can tell there are only two places where setting search list make sense. 1. Enterprises. 2. Homes. Everywhere else you DO NOT control the machine requesting the address and setting search lists could actually result in criminal prosecution. Just because the machine requested a search list it doesn't mean that you should be supplying one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Mon, 2011-10-24 at 16:58 -0400, Keith Moore wrote: > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, and > >> it's very hard for software to distinguish the cases where they are > >> potentially appropriate from the cases when they're not, and it's not > >> possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > >sets a threshold for the number of dots which > >must appear in a name given to res_query() (see > >resolver(3)) before an initial absolute query > >will be made. The default for n is “1”, mean‐ > >ing that if there are any dots in a name, the > >name will be tried first as an absolute name > >before any search list elements are appended to > >it. > > > > So it seems that this question is already a matter of local policy, > > which given the number and quality of the divergent views seems > > eminently reasonable. Can we move on now? > > No, because relying on "local policy" is not sufficient for interoperability. For interoperability, one can use absolute names, with the trailing dot, or specify that in the context of whatever protocol, all names are to be taken as relative to the root, or use other than a printed representation. In some cases this may require that implementations use resolver interfaces which make it clear that a name to be resolved is absolute, or that they append the empty label to relative names before passing them on to the resolver. On the other hand, in user interface, which is primarily where relative names are intended to be used, local policy is quite sufficient. As long as I and the software on my machine agree on what a name I type means, it's none of the IETF's business. Can an enterprise change the name of every domain name? On machines they control, yes. While I agree wholeheartedly with the notion of a unique domain name space, I also believe that mapping a relative or abbreviated name onto that namespace is _entirely_ a matter of local policy. It is perhaps appropriate for the IETF to provide mechanisms for distributing that policy, for those who wish to use them, but not to dictate what the policy must be. > I think there's a need for IETF to document why any other value than 1 > is a Bad Idea, and more to the point, why it will break things. It's not a Bad Idea, and it doesn't break things, or at least not so badly that the convenience isn't worth it. In this, I speak from years of operational experience, not only of personal use of also that of the many users of systems I operate support. Do things get worse as new TLDs appear? Yes, sometimes. Have we mostly had to abandon use of relative names ending in .cs and other two-letter suffixes? Yes, but we _mostly_ didn't use them anyway, due to our deep namespace and the appearance of those domains in our search list (here, "foo.bar" usually means "foo.bar.cs.cmu.edu"). Does that mean we're abandoning "options ndots:2"? Not aggressively. It has faded over time, but more due to a failure to actively apply it to newer systems than to any conscious decision that it's a problem. Further, given this position, I wonder why you think even a value of 1 is acceptable in the face of vanity TLDs. I know why I do, both from the perspective of an IETF (it's a local policy matter, period) and for myself (search for local names first, don't trust DNS results (yet) for security, and write absolute names when you want to bypass search lists). > The > problem isn't entirely specific to hosts with multiple interfaces. > But given that using multiple interfaces makes the problem worse, MIF > might want to take on some of the work of documenting why it will > break things. I can see how using an untrusted search list makes it worse. I can also see how using multiple sets of nameservers which provide different views of the namespace makes things worse, and I can see how using multiple interfaces makes this more likely. But, that has nothing to do with search lists and occurs even if every name is always treated as absolute. I can see two answers to this: 1) Use DNSSEC 2) Don't trust results from unsecured DNS for anything important. I fail to see how using multiple interfaces makes the problem worse, in itself. Can you elaborate? -- Jeff ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Mon, 2011-10-24 at 19:30 -0400, Keith Moore wrote: > On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote: > > >>> So it seems that this question is already a matter of local policy, > >>> which given the number and quality of the divergent views seems > >>> eminently reasonable. Can we move on now? > >> > >> No, because relying on "local policy" is not sufficient for > >> interoperability. > > > > For interoperability, one can use absolute names, with the trailing dot, > > uh, no. Names with trailing dots aren't allowed in many contexts. > And in some of the contexts in which they are allowed, they get > "canonicalized" to names without trailing dots. Yup; that's a problem. And I agree that changing it may not be the most practical solution to the problem. > > > or specify that in the context of whatever protocol, all names are to be > > taken as relative to the root, or use other than a printed > > representation. > > ...so a DNS name means different things in one context than in another. Bad > Idea. Hm? Not at all. Really, only unambiguous names ought to ever appear on the wire. One way for a protocol to do that is too use absolute names exclusively; another is to use "relative" names which are always relative to the root; this is the same as using absolute names without the trailing dot. Another is to use names relative to some unambiguous origin, as is done in DNS master files. The important thing is that a name always mean the same thing, not that it be represented the same way in all protocols. > > In some cases this may require that implementations use > > resolver interfaces which make it clear that a name to be resolved is > > absolute, or that they append the empty label to relative names before > > passing them on to the resolver. > > > > On the other hand, in user interface, which is primarily where relative > > names are intended to be used, local policy is quite sufficient. > > no. Domain names are written on buses, billboards, business cards. > They do get transcribed, quite often actually, and they need to have > the same meanings when typed in as they do when clicked on. Yup, that's a problem, too, in many ways. Of course, such names should always be fully-qualified; you can't expect useful results if you use a relative name on the side of a bus. Or at least, you can't unless you really meant an absolute name but left off the trailing dot, which is what everyone will think you meant anyway. > Some people are working way too hard to try to save something that was > never a good idea in the first place. > > I'm not arguing that all software that currently applies searching to > names with dots in them has to die a violent death, and immediately > either be updated or deleted from all computers everywhere (as > if...). I'm just saying that IETF should recommend against the > practice of using search lists with multi-label names, and document > the harm that it does. Sites can still do it if they want to, or they > can manage their own transitions away from using search paths for such > names, on their own timeframes. After all, this has been a practice > for ~30 years in some places, nobody should expect it all to change > overnight. Right. That's what local policy _is_. Of course it's reasonable for the IETF to recommend default policy, and describe some of the pitfalls associated with other possible policies. And I certainly agree that ndots:1 is a reasonable default policy that will work for most people while causing few problems. Which makes it convenient that it's what most vendors already do today. > > While I agree wholeheartedly with the notion of a unique domain name > > space, I also believe that mapping a relative or abbreviated name onto > > that namespace is _entirely_ a matter of local policy. > > That's a convenient philosophy if you _only_ care that local things > interoperate with one another. I only care that abbreviated names work for local things. For non-local things, I find it acceptable that fully-qualified names must be used to obtain interoperability. > > Further, given this position, I wonder why you think even a value of 1 > > is acceptable in the face of vanity TLDs. > Because (a) local names are essential, (b) the ability to distinguish > local names from FQDNs is also essential, and (c) use of a > single-label name as a local name (meaning, a name subject to local > interpretation) is a very widespread and well-entrenched practice. > Sites that associate address (or MX) records with vanity TLDs will > lose, and they deserve to lose. OK; on these points we agree. Note, however, that to me "local interpretation" means as defined by me and whoever else is involved in setting policy for me, and _not_ as defined by the coffee shop I happen to be sitting in. IMHO, local names are useless if I cannot depend on their meaning. Ideally, it would be desirable to have an interoperable way to
Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document
On Sat, 2011-10-22 at 11:42 -0700, Doug Barton wrote: > In regards to 3, let's say I have a domain, example.org. In my network I > have various subdomains that represent various network segments, let's > say foo, bar, and baz. Personally, I find it convenient to put > 'example.com' in the search list for all of my hosts, and then type 'ssh > host.bar' and go off on my merry way. Yes, I understand that in my > simple example I could theoretically put all 3 subdomains in the search > list. Now assume that my network isn't actually that simple ... For example, suppose that each of foo, bar, and baz in turn has a number of subdomains, and that the total number of such 4th-level domains is over 250. Now, imagine that major resolver implementations limit the search list to a total of 6 domains... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
