Re: [UNsolved] was: what does dig +trace do?
On 9/6/2011 8:40 PM, Mark Andrews wrote: In message4e66b5b5.30...@chrysler.com, Kevin Darcy writes: On 9/1/2011 7:57 PM, Mark Andrews wrote: In message4e5fb1ab.4040...@data.pl, Torinthiel writes: On 09/01/11 17:56, Tom Schmitt wrote: =20 I found the cause of my problem (and a solution): =20 dig +trace actually has another behaviour than doing the trace manually= step by step with dig. =20 =20 For a trace, dig is asking for the NS-records, then for the IP-address = of the nameserver found and then go on asking this nameserver. Till the d= estination is reached. =20 In my case, dig is asking for the nameservers of the root-zone and is g= etting the answer: . IN NS root1 . IN NS root2=20 etc =20 Next dig is asking for the A-record of root1. And here is the differren= ce: =20 If I do dig root1 dig is asking exactly this, it is asking for the A-= record of root1. And of course I get the correct answer from named. =20 The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf= and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. =20 After deleting the searchsuffix in resolv.conf, dig +trace is working f= ine without any error. =20 In my oppinion it's a bug that dig +trace behave in a differrent way th= an doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say =2E IN NS root1. =2E IN NS root2. (with dots appended) and you should be home. dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Actually, RFC 1123 requires a way to suppress domain suffixing, and mentions the trailing dot convention: 6.1.4.3 Interface Abbreviation Facilities User interfaces MAY provide a method for users to enter abbreviations for commonly-used names. Although the definition of such methods is outside of the scope of the DNS specification, certain rules are necessary to insure that these methods allow access to the entire DNS name space and to prevent excessive use of Internet resources. If an abbreviation method is provided, then: (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. But it appears that getaddrinfo() doesn't, apparently (according to a quick wrapper program I tested with) support the trailing dot convention for suppressing domain suffixing, or, AFAIK, any other way to suppress domain suffixing, therefore dig +trace is stuck either -- as you said -- implementing a full iterative resolver itself, or calling getaddrinfo() and confusing the user with unwanted domain suffixing, in the special case of a delegation to a root name. Let's be clear, though: dig +trace *should* be able to deal with a delegation to a root name, as twisted and obscure as that is. It only fails to do so because of some design decisions/tradeoffs made with getaddrinfo() and/or dig itself. Not because the user is doing something wrong. Well really they are. Address records on TLD labels will *never* work reliably unless you can get the world to agree to stop using search lists. Seriously, if a TLD label *only* appears in the RDATA of NS records, and *never* as a hostname (in the RFC 952/1123 sense), why would we worry about searchlisting complications? And even if a TLD label is presented at the user-to-program interface, as long as the prevailing convention for disabling searchlists (mandatory as per RFC 1123) is present (e.g. trailing dot), it too can be unambiguously resolved. So there's really no *technical* reason for dig to malfunction when encountering a delegation to a TLD label. IMO, this smacks more of prioritizing a personal preference against the use of TLD labels, over fixing a _bona_fide_ bug in the dig +trace algorithm. You may not like TLD labels, but they should still work regardless. - Kevin P.S. Don't get me wrong, as a general rule I hate shortnames and searchlisting, and I've been trying to eradicate their use here for decades, but in the spirit of dig's give me what I ask for, not what you think is best for me, and mere consistency, I think that if named itself can handle delegations to TLD labels, dig +trace should be able to handle them too. People do, after all, use dig +trace to mimic an
Re: [UNsolved] was: what does dig +trace do?
On 9/1/2011 7:57 PM, Mark Andrews wrote: In message4e5fb1ab.4040...@data.pl, Torinthiel writes: On 09/01/11 17:56, Tom Schmitt wrote: =20 I found the cause of my problem (and a solution): =20 dig +trace actually has another behaviour than doing the trace manually= step by step with dig. =20 =20 For a trace, dig is asking for the NS-records, then for the IP-address = of the nameserver found and then go on asking this nameserver. Till the d= estination is reached. =20 In my case, dig is asking for the nameservers of the root-zone and is g= etting the answer: . IN NS root1 . IN NS root2=20 etc =20 Next dig is asking for the A-record of root1. And here is the differren= ce: =20 If I do dig root1 dig is asking exactly this, it is asking for the A-= record of root1. And of course I get the correct answer from named. =20 The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf= and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. =20 After deleting the searchsuffix in resolv.conf, dig +trace is working f= ine without any error. =20 In my oppinion it's a bug that dig +trace behave in a differrent way th= an doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say =2E IN NS root1. =2E IN NS root2. (with dots appended) and you should be home. dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Actually, RFC 1123 requires a way to suppress domain suffixing, and mentions the trailing dot convention: 6.1.4.3 Interface Abbreviation Facilities User interfaces MAY provide a method for users to enter abbreviations for commonly-used names. Although the definition of such methods is outside of the scope of the DNS specification, certain rules are necessary to insure that these methods allow access to the entire DNS name space and to prevent excessive use of Internet resources. If an abbreviation method is provided, then: (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. But it appears that getaddrinfo() doesn't, apparently (according to a quick wrapper program I tested with) support the trailing dot convention for suppressing domain suffixing, or, AFAIK, any other way to suppress domain suffixing, therefore dig +trace is stuck either -- as you said -- implementing a full iterative resolver itself, or calling getaddrinfo() and confusing the user with unwanted domain suffixing, in the special case of a delegation to a root name. Let's be clear, though: dig +trace *should* be able to deal with a delegation to a root name, as twisted and obscure as that is. It only fails to do so because of some design decisions/tradeoffs made with getaddrinfo() and/or dig itself. Not because the user is doing something wrong. - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
In message 4e66b5b5.30...@chrysler.com, Kevin Darcy writes: On 9/1/2011 7:57 PM, Mark Andrews wrote: In message4e5fb1ab.4040...@data.pl, Torinthiel writes: On 09/01/11 17:56, Tom Schmitt wrote: =20 I found the cause of my problem (and a solution): =20 dig +trace actually has another behaviour than doing the trace manually= step by step with dig. =20 =20 For a trace, dig is asking for the NS-records, then for the IP-address = of the nameserver found and then go on asking this nameserver. Till the d= estination is reached. =20 In my case, dig is asking for the nameservers of the root-zone and is g= etting the answer: . IN NS root1 . IN NS root2=20 etc =20 Next dig is asking for the A-record of root1. And here is the differren= ce: =20 If I do dig root1 dig is asking exactly this, it is asking for the A-= record of root1. And of course I get the correct answer from named. =20 The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf= and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. =20 After deleting the searchsuffix in resolv.conf, dig +trace is working f= ine without any error. =20 In my oppinion it's a bug that dig +trace behave in a differrent way th= an doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say =2E IN NS root1. =2E IN NS root2. (with dots appended) and you should be home. dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Actually, RFC 1123 requires a way to suppress domain suffixing, and mentions the trailing dot convention: 6.1.4.3 Interface Abbreviation Facilities User interfaces MAY provide a method for users to enter abbreviations for commonly-used names. Although the definition of such methods is outside of the scope of the DNS specification, certain rules are necessary to insure that these methods allow access to the entire DNS name space and to prevent excessive use of Internet resources. If an abbreviation method is provided, then: (a) There MUST be some convention for denoting that a name is already complete, so that the abbreviation method(s) are suppressed. A trailing dot is the usual method. But it appears that getaddrinfo() doesn't, apparently (according to a quick wrapper program I tested with) support the trailing dot convention for suppressing domain suffixing, or, AFAIK, any other way to suppress domain suffixing, therefore dig +trace is stuck either -- as you said -- implementing a full iterative resolver itself, or calling getaddrinfo() and confusing the user with unwanted domain suffixing, in the special case of a delegation to a root name. Let's be clear, though: dig +trace *should* be able to deal with a delegation to a root name, as twisted and obscure as that is. It only fails to do so because of some design decisions/tradeoffs made with getaddrinfo() and/or dig itself. Not because the user is doing something wrong. Well really they are. Address records on TLD labels will *never* work reliably unless you can get the world to agree to stop using search lists. One could tweak dig to disable searching when resolving these addresses, as the answers from the dns are absolute, but it is good practice to never expect them to work in the first place. ssh tld or mail user@tld or browser http://tld/; will never work reliably as long as search lists exist. This is as much about expectation setting as anything else. Mark - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
In my case, dig is asking for the nameservers of the root-zone and is getting the answer: . IN NS root1 . IN NS root2 etc Next dig is asking for the A-record of root1. And here is the differrence: If I do dig root1 dig is asking exactly this, it is asking for the A-record of root1. And of course I get the correct answer from named. The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say . IN NS root1. . IN NS root2. (with dots appended) and you should be home. No. Sorry: The answer quoted above I typed by hand instead of copypaste and so I forgot the dots at the end. In my root zone there are of course dots at the end of the names. But the +trace option is ignoring these dots. As this bug is only visible if you have your own root-zone and Nameservers directly in this zone, I think there are not many people out there who will stumble over this. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
dig +trace calls getaddrinfo() and that needs to be able to resolve the hostname (without dots at the end). getaddrinfo() is called so that we don't have to have a full blown iterative resolver in dig. I see. So no way to solve this one in dig itself. The Internet moved from being a flat namespace (names without dots) for hostnames to a heirachical namespace (names with *internal* dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 Hostnames without dots are now local (e.g. localhost) or need to be qualified (resolv.conf: search). Yes, I heard something about a Internet that was invented some time ago... :-) But seriously: I don't see in the RFC that it is forbidden to have a hostname directly in the root-zone (without a internal dot). -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
Hi Tom, At 23:42 01-09-2011, Tom Schmitt wrote: But seriously: I don't see in the RFC that it is forbidden to have a hostname directly in the root-zone (without a internal dot). From RFC 921: The names are being changed from simple names, or globally unique strings, to structured names, where each component name is unique only with respect to the superior component name. Because of the growth of the Internet, structured names (or domain style names) have been introduced. Each element of the structured name will be a character string (with the same constraints that previously applied to the simple names). The elements (or components) of the structured names are separated with periods, and the elements are written from the most specific on the left to the most general on the right. The above discusses about hierarchical names. It is about how the system was designed to work and not about what is forbidden. The syntax of a legal Internet host name was specified in RFC-952, updated by RFC 1123. Regards, -sm ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
I found the cause of my problem (and a solution): dig +trace actually has another behaviour than doing the trace manually step by step with dig. For a trace, dig is asking for the NS-records, then for the IP-address of the nameserver found and then go on asking this nameserver. Till the destination is reached. In my case, dig is asking for the nameservers of the root-zone and is getting the answer: . IN NS root1 . IN NS root2 etc Next dig is asking for the A-record of root1. And here is the differrence: If I do dig root1 dig is asking exactly this, it is asking for the A-record of root1. And of course I get the correct answer from named. The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. After deleting the searchsuffix in resolv.conf, dig +trace is working fine without any error. In my oppinion it's a bug that dig +trace behave in a differrent way than doing the queries with dig one by one. Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
