Re: Bare TLD resolutions
In article you write: >David Conrad 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. 3600IN 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
Re: Bare TLD resolutions
On Sep 19, 2014, at 2:01 AM, Tony Finch wrote: > David Conrad 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bare TLD resolutions
David Conrad 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. 3600IN 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.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good.
Re: Bare TLD resolutions
On Sep 17, 2014, at 6:01 PM, Jimmy Hess wrote: > On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth 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: . 3600IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014091701 1800 900 604800 86400 But for any TLD which exists, yes. Owen
Re: Bare TLD resolutions
On Wed, Sep 17, 2014 at 11:09 AM, Jay Ashworth 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
Re: Bare TLD resolutions
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 .. > > 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. asulli...@dyn.com v: +1 603 663 0448
Re: Bare TLD resolutions
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.kletni...@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
Re: Bare TLD resolutions
Fred, On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bare TLD resolutions
In message <21906507.2046.1410990673107.javamail.r...@benjamin.baylink.com>, Ja y Ashworth writes: > - Original Message - > > From: "Mark Andrews" > > > 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: ma...@isc.org
Re: Bare TLD resolutions
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 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
> j...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Bare TLD resolutions
- Original Message - > From: "Doug Barton" > > 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 j...@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
Re: Bare TLD resolutions
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. pgp5HBHLyaSV2.pgp Description: PGP signature
Re: Bare TLD resolutions
On 9/17/14 2:48 PM, Jay Ashworth wrote: - Original Message - From: "Andrew Sullivan" 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, , or MX record". You want to return NXDOMAIN for a name only when the QTYPE is A, , 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
Re: Bare TLD resolutions
- Original Message - > From: "Mark Andrews" > 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 j...@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
Re: Bare TLD resolutions
- Original Message - > From: "Andrew Sullivan" > 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, , or MX record". > > You want to return NXDOMAIN for a name only when the QTYPE is A, , > 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 j...@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
Re: Bare TLD resolutions
In message <20140917211336.gt89...@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, , or MX > > record". > > You want to return NXDOMAIN for a name only when the QTYPE is A, , > or MX, and not everything else? Presumably you don't want to do > negative caching? > > A > > -- > Andrew Sullivan > Dyn, Inc. > asulli...@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 .. localhost is special cased. You want res_search() to return HOST_NOT_FOUND if a single label is entered and is not matched by .. 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 .. 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: ma...@isc.org
Re: Bare TLD resolutions
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, , or MX > record". You want to return NXDOMAIN for a name only when the QTYPE is A, , or MX, and not everything else? Presumably you don't want to do negative caching? A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: Bare TLD resolutions
- Original Message - > From: "John Levine" > >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, , 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 j...@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
Re: Bare TLD resolutions
>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
Re: Bare TLD resolutions
On Sep 17, 2014, at 11:08 AM, Eric Brunner-Williams wrote: > On 9/17/14 10:45 AM, David Conrad wrote: >> To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or >> wildcards). > um. .museum. … .MUSEUM gave up their wildcard some time ago. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bare TLD resolutions
On 9/17/14 10:45 AM, David Conrad wrote: To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or wildcards). um. .museum. ...
Re: Bare TLD resolutions
- Original Message - > From: "David Conrad" > > 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? > > https://www.icann.org/news/announcement-2013-08-30-en Thanks, Dave. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
Re: Bare TLD resolutions
Jay, On Sep 17, 2014, at 10:36 AM, Jay Ashworth 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bare TLD resolutions
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.
Re: Bare TLD resolutions
Original Message -
> From: "David Conrad"
> 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 j...@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
Re: Bare TLD resolutions
Jay,
On Sep 17, 2014, at 9:09 AM, Jay Ashworth 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
Bare TLD resolutions
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 j...@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
