Pursuant to https://www.icann.org/resources/pages/name-collision-2013-12-06-en) mentioned in the Scotland thread... it seems there are two major potential points of possible collision: 1) User network uses "fake" TLD which is no longer fake, and local resolver server blows it 2) User network blows it worse, and tries to resolve a monocomponent name off non-local servers. The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*. Is that a requirement for a TLD? If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD? Is there actually *any* good reason why a lookup on a bare TLD ("com.") might return a valid record? And what about Naomi? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Jay, On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra@baylink.com> wrote:
it seems there are two major potential points of possible collision:
1) User network uses "fake" TLD which is no longer fake, and local resolver server blows it
2) User network blows it worse, and tries to resolve a monocomponent name off non-local servers.
A common case of name collision is driven by the “DNS search path”, e.g., if you have a “search path” of “bar.com;foo.bar.com” and you type “telnet baz”, _some_ resolver libraries will try to resolve “baz.bar.com”, if that fails then “baz.foo.bar.com”, if that fails then “baz.”, if that fails return an error to the user. However, the "search path” algorithm was never fully standardized and there are implementations that try “baz.” first (there are even some implementations that will split up the path elements, e.g., if ‘baz.bar.com’ fails, the resolver library will try ‘baz.com’). In my view, given the lack of standardization and the potential security implications, search paths shouldn’t be used at all.
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*.
It is quite rare that a TLD is queried for directly. Resolver libraries generally do not parse the name being queried and send the minimum to the authoritative servers. That is, if a resolver is asked for “foo.bar.com”, it sends the entire string to the root server and gets back a referral to the COM servers — it generally does not parse “foo.bar.com” to get the TLD and send “COM” to the root servers to get the referral. This latter behavior is called “QNAME minimization” and is a good idea for performance and privacy (and other reasons), but not yet generally implemented because it is a bit tricky in the general case.
If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD?
There are a few ccTLDs that provide apex wildcards: they’ll return an “A” record for any random goop (.WS is an example), however this behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
Is there actually *any* good reason why a lookup on a bare TLD ("com.") might return a valid record?
Some of the folks in ICANN’s new gTLD program, typically the folks who’ve gone for “brand” TLDs (e.g., .bmw), have argued for what’s called “dotless” domains: they want people to be able to do stuff like point their browsers at “http://bmw” and have the web page for BMW show up. Unfortunately for them, several oceans have already gone under that particular bridge (see https://www.icann.org/en/system/files/files/sac-053-en.pdf) and ICANN has (to date) resisted those requests. (I actually don’t know if the folks behind .BMW wanted dotless domains — just using BMW as an example)
And what about Naomi?
Never was a big fan of the chair. Regards, -drc
---- Original Message -----
From: "David Conrad" <drc@virtualized.org>
A common case of name collision is driven by the “DNS search path”, e.g., if you have a “search path” of “bar.com;foo.bar.com” and you type “telnet baz”, _some_ resolver libraries will try to resolve “baz.bar.com”, if that fails then “baz.foo.bar.com”, if that fails then “baz.”, if that fails return an error to the user.
However, the "search path” algorithm was never fully standardized and there are implementations that try “baz.” first (there are even some implementations that will split up the path elements, e.g., if ‘baz.bar.com’ fails, the resolver library will try ‘baz.com’).
Yes; this is what I was talking about. If I have a machine inside my network called "aero", and I telnet to it, and for some reason the search path blows it, I might try to resolve "aero." against the Greater Internet, and if the .aero TLD *returns an A record*, then I'm in trouble. Correct?
In my view, given the lack of standardization and the potential security implications, search paths shouldn’t be used at all.
True, but not entirely germane to this level of the issue.
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*.
It is quite rare that a TLD is queried for directly. Resolver libraries generally do not parse the name being queried and send the minimum to the authoritative servers. That is, if a resolver is asked for “foo.bar.com”, it sends the entire string to the root server and gets back a referral to the COM servers — it generally does not parse “foo.bar.com” to get the TLD and send “COM” to the root servers to get the referral. This latter behavior is called “QNAME minimization” and is a good idea for performance and privacy (and other reasons), but not yet generally implemented because it is a bit tricky in the general case.
Sure, but as you pointed out above, we're not talking about that. We're talking, largely, about error cases *that used to break as you wanted, and now might not*.
If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD?
There are a few ccTLDs that provide apex wildcards: they’ll return an “A” record for any random goop (.WS is an example), however this behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
A records being returned for bare TLDs *is* formally banned? (Oh: specifically for cctlds. Got it.) Citation?
Is there actually *any* good reason why a lookup on a bare TLD ("com.") might return a valid record?
Some of the folks in ICANN’s new gTLD program, typically the folks who’ve gone for “brand” TLDs (e.g., .bmw), have argued for what’s called “dotless” domains:
Yeah; that's not a "good" reason. :-)
And what about Naomi?
Never was a big fan of the chair.
Electric Company FTW. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 9/17/14 10:36 AM, Jay Ashworth wrote:
A records being returned for bare TLDs*is* formally banned?
(Oh: specifically for cctlds. Got it.)
No, ICANN doesn't ban anything for the ccTLDs.
Citation?
The gTLD registry contracts describe the fact that they cannot add A records at the zone apex.
Jay, On Sep 17, 2014, at 10:36 AM, Jay Ashworth <jra@baylink.com> wrote:
We're talking, largely, about error cases *that used to break as you wanted, and now might not*.
Yep. Well, it used to break if you happened to be using the right version of resolver library. There have been cases where operating system vendors had different search path behaviors in their resolver libraries depending on version and even patch level. It’s all a bit of a mess.
There are a few ccTLDs that provide apex wildcards: they’ll return an “A” record for any random goop (.WS is an example), however this behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
A records being returned for bare TLDs *is* formally banned?
(Oh: specifically for cctlds. Got it.)
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards). ICANN has no mechanism by which policy can be imposed on ccTLDs.
Citation?
https://www.icann.org/news/announcement-2013-08-30-en Regards, -drc
----- Original Message -----
From: "David Conrad" <drc@virtualized.org>
A records being returned for bare TLDs *is* formally banned?
(Oh: specifically for cctlds. Got it.)
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards). ICANN has no mechanism by which policy can be imposed on ccTLDs.
Yeah; sorry; quoted it backwards.
Citation?
Thanks, Dave. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
David Conrad <drc@virtualized.org> wrote:
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards).
Wildcards are being used for the name collision gubbins. ; <<>> DiG 9.11.0pre-alpha <<>> *.prod ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51904 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;*.prod. IN A ;; ANSWER SECTION: *.prod. 3600 IN A 127.0.53.53 ;; Query time: 66 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Sep 19 10:00:30 BST 2014 ;; MSG SIZE rcvd: 51 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good.
On Sep 19, 2014, at 2:01 AM, Tony Finch <dot@dotat.at> wrote:
David Conrad <drc@virtualized.org> wrote:
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards). Wildcards are being used for the name collision gubbins.
Ah, true. Apologies. There is a waiver from that restriction exclusively for the name collision stuff. I believe the waiver expires 90 days after the initial delegation. Regards, -drc
In article <alpine.LSU.2.00.1409190959570.3000@hermes-1.csi.cam.ac.uk> you write:
David Conrad <drc@virtualized.org> wrote:
To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards).
Wildcards are being used for the name collision gubbins.
;; ANSWER SECTION: *.prod. 3600 IN A 127.0.53.53
Yes, but only for a few months before the TLD goes live to try and flush out prior local use of new TLDs. The rule about wildcards in live TLDs hasn't changed. There was a lot about this at Verisign's name collision workshop after the London IETF. http://namecollisions.net/program/index.html R's, John
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*.
Is that a requirement for a TLD?
No. In fact, a TLD lookup that returned NXDOMAIN would be utterly broken since that would mean the TLD had no SOA, no NS, and no subdomains. Perhaps you're confusing it with NOERROR.
If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD?
Yes. If you'd read RFC 7085, you'd already know which ones do. There have been A and MX records at TLDs nearly as long as there have been TLDs. R's, John
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*.
Is that a requirement for a TLD?
No. In fact, a TLD lookup that returned NXDOMAIN would be utterly broken since that would mean the TLD had no SOA, no NS, and no subdomains. Perhaps you're confusing it with NOERROR.
No, I was confusing you for someone who understood -- as everyone else here seems to have -- that I meant "querying for an A, AAAA, or MX record".
If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD?
Yes. If you'd read RFC 7085, you'd already know which ones do.
There have been A and MX records at TLDs nearly as long as there have been TLDs.
And this is *why* I assumed you knew that, since the RFC is yours, and makes precisely that distinction. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
----- Original Message ----- No, I was confusing you for someone who understood -- as everyone else here seems to have -- that I meant "querying for an A, AAAA, or MX record".
You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA, or MX, and not everything else? Presumably you don't want to do negative caching? A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
In message <20140917211336.GT89960@dyn.com>, Andrew Sullivan writes:
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
----- Original Message ----- No, I was confusing you for someone who understood -- as everyone else here seems to have -- that I meant "querying for an A, AAAA, or MX record".
You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA, or MX, and not everything else? Presumably you don't want to do negative caching?
A
-- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
You want gethostbyname, getaddrinfo to return HOST_NOT_FOUND/EAI_NONAME if a single label is entered and is not matched by <label>.<search-list-element>. localhost is special cased. You want res_search() to return HOST_NOT_FOUND if a single label is entered and is not matched by <label>.<search-list-element>. You want res_query() and other tools that look in the DNS and are *not* searching to return whatever is in the DNS. If you have a new interface that looks for SRV records you want that to fail if <srv-prefix>.<label>.<search-list-element> is not found unless searching is explictly disabled. This allows for things like "_whois._tcp.tld SRV ...." to work. Search lists are for hosts and host like things. Resolver libraries have different interfaces for different purposes. Single label hostnames for reaching non local equipment was deliberately phase out in the 1980's as it was clearly a bad concept. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
Search lists are for hosts and host like things. Resolver libraries have different interfaces for different purposes. Single label hostnames for reaching non local equipment was deliberately phase out in the 1980's as it was clearly a bad concept.
Yes, and we're discussing the practical reason *why* it's a bad concept. :-) My abject apologies to everyone who didn't get that I was talking about the *source* of the problem by synecdoche. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
In message <21906507.2046.1410990673107.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
Search lists are for hosts and host like things. Resolver libraries have different interfaces for different purposes. Single label hostnames for reaching non local equipment was deliberately phase out in the 1980's as it was clearly a bad concept.
Yes, and we're discussing the practical reason *why* it's a bad concept.
:-)
My abject apologies to everyone who didn't get that I was talking about the *source* of the problem by synecdoche.
The source of the problem is bad search list handling. It wouldn't matter what records are there if the search list handling was correct. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Sep 18, 2014 at 07:39:08AM +1000, Mark Andrews wrote:
You want gethostbyname, getaddrinfo to return HOST_NOT_FOUND/EAI_NONAME
I was unaware that getaddrinfo returned "NXDOMAIN", which is what I read in the thread being talked about. Not return values from the OS calls. I guess I missed that message.
You want res_search() to return HOST_NOT_FOUND if a single label is entered and is not matched by <label>.<search-list-element>.
You want res_query() and other tools that look in the DNS and are *not* searching to return whatever is in the DNS.
These are not even remotely the same thing as what was being proposed, which is all I was commenting on. A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
----- Original Message -----
From: "Andrew Sullivan" <asullivan@dyn.com>
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
----- Original Message ----- No, I was confusing you for someone who understood -- as everyone else here seems to have -- that I meant "querying for an A, AAAA, or MX record".
You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA, or MX, and not everything else? Presumably you don't want to do negative caching?
I want to return NXDOMAIN *because there is no record of that type at that node*. That was the underlying point here; I thought that was pretty clear. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 9/17/14 2:48 PM, Jay Ashworth wrote:
----- Original Message -----
From: "Andrew Sullivan" <asullivan@dyn.com>
On Wed, Sep 17, 2014 at 04:57:52PM -0400, Jay Ashworth wrote:
----- Original Message ----- No, I was confusing you for someone who understood -- as everyone else here seems to have -- that I meant "querying for an A, AAAA, or MX record".
You want to return NXDOMAIN for a name only when the QTYPE is A, AAAA, or MX, and not everything else? Presumably you don't want to do negative caching?
I want to return NXDOMAIN *because there is no record of that type at that node*.
That was the underlying point here; I thought that was pretty clear.
But that's not what NXDOMAIN means. :) You get an NXDOMAIN response when there is no label at that point in the tree, period. In the case you specify you get the combination of NOANSWER + NOERROR if there is no address record, but there are other records (like there are at a zone apex). hth, Doug
----- Original Message -----
From: "Doug Barton" <dougb@dougbarton.us>
I want to return NXDOMAIN *because there is no record of that type at that node*.
That was the underlying point here; I thought that was pretty clear.
But that's not what NXDOMAIN means. :) You get an NXDOMAIN response when there is no label at that point in the tree, period. In the case you specify you get the combination of NOANSWER + NOERROR if there is no address record, but there are other records (like there are at a zone apex).
D'oh. Yes; I overspecified. Damn.
hth,
It did; thanks. Well, except for John, but he thinks I'm an idiot dilettante anyway. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Wed, 17 Sep 2014 17:48:58 -0400, Jay Ashworth said:
I want to return NXDOMAIN *because there is no record of that type at that node*.
NXDOMAIN means "There are no records of *any* type at that node". NOERROR means "There are no records of *that* type at that node (but the node exists and there may be records of other types if you ask for them)". The distinction is important.
Doug Barton wrote:
In the case you specify you get the combination of NOANSWER + NOERROR if there is no address record, but there are other records (like there are at a zone apex).
Valdis.Kletnieks@vt.edu wrote:
NXDOMAIN means "There are no records of *any* type at that node".
Not. Though your misunderstanding is common, NXDOMAIN means "no such node exist", while some node may exist without having any data, as is specified in rfc1034: Each node and leaf on the tree corresponds to a resource set (which may be empty). Masataka Ohta
IMHO, since ICANN has created the situation, the ball is in ICANN’s court to say how this works without disrupting name services. Their ill-informed hipshot is not our emergency. On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra@baylink.com> wrote:
Pursuant to
https://www.icann.org/resources/pages/name-collision-2013-12-06-en)
mentioned in the Scotland thread... it seems there are two major potential points of possible collision:
1) User network uses "fake" TLD which is no longer fake, and local resolver server blows it
2) User network blows it worse, and tries to resolve a monocomponent name off non-local servers.
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*.
Is that a requirement for a TLD?
If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD?
Is there actually *any* good reason why a lookup on a bare TLD ("com.") might return a valid record?
And what about Naomi?
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Fred, On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) <fred@cisco.com> wrote:
IMHO, since ICANN has created the situation,
ICANN has created ill-specified domain search path heuristics and truly fascinating implementations of those heuristics? ICANN has caused people to use non-allocated TLDs in environments where queries for those non-allocated TLDs hit the public Internet? ICANN had made applications dependent upon receiving NXDOMAINs in a way that implies the root of the DNS should never be expanded (even for country codes or internationalized domain names)?
the ball is in ICANN’s court to say how this works without disrupting name services.
Actually, name services aren’t disrupted. They are behaving exactly as specified in the DNS and as intended. What is disrupted is (typically unknown) assumptions people have made regarding the composition of the top-level of the domain namespace. ICANN has been working to try to help mitigate the issue for some time now (initial discussions occurred in 2010).
Their ill-informed hipshot is not our emergency.
Hipshots are generally not a good idea, regardless of whether they are ill-informed. Whose emergency it is probably depends on how the delegation of new top-level domains impacts the operation of your network. To date, in cases where there was impact, the affected parties have worked to address the issues and (AFAIK) no emergencies have been experienced. Regards, -drc
On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth <jra@baylink.com> wrote:
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*. [snip]
Not NXDOMAIN. When TLD. is looked up, they should always return NOERROR. And yield, either (1) the NS records for the TLD, for QTYPE NS or 'ANY' For other queries TLD. should return NOERROR with Zero RRs in the answer (Empty response). A NXDOMAIN response would be declaring that the TLD does not exist. -- -JH
On Sep 17, 2014, at 6:01 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth <jra@baylink.com> wrote:
The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*. [snip]
Not NXDOMAIN. When TLD. is looked up, they should always return NOERROR.
Well… A TLD which does not exist should return NXDOMAIN. For example, if I do a query for .NONEXISTANTTLD., then I should get NXDOMAIN… Owens-MacBook-Pro:Downloads owendelong$ dig NONEXISTANTTLD. ; <<>> DiG 9.8.3-P1 <<>> NONEXISTANTTLD. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64254 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;NONEXISTANTTLD. IN A ;; AUTHORITY SECTION: . 3600 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014091701 1800 900 604800 86400 But for any TLD which exists, yes. Owen
participants (13)
-
Andrew Sullivan -
David Conrad -
Doug Barton -
Eric Brunner-Williams -
Fred Baker (fred) -
Jay Ashworth -
Jimmy Hess -
John Levine -
Mark Andrews -
Masataka Ohta -
Owen DeLong -
Tony Finch -
Valdis.Kletnieks＠vt.edu