[dns-operations] When TLDs have apex A records

[Mark Andrews]

In message <alpine.BSF.2.00.0907020022000.12772 at in1.dns-oarc.net>, Duane Wessel
s writes:
> Recently someone asked me if I knew of any problems when a TLD zone has
> an A record at its apex.  I did a quick scan and found the following:
> 
> AC has address 193.223.78.210
> AF has address 65.219.4.91
> AI has address 209.59.119.34
> BI has address 196.2.8.205
> CM has address 195.24.192.17
> DK has address 193.163.102.23
> GL has address 194.177.224.25
> HK has address 203.119.2.28
> IO has address 193.223.78.212
> PH has address 203.119.4.7
> PN has address 80.68.93.100
> PW has address 203.199.114.33
> SH has address 64.251.31.234
> TK has address 217.119.57.22
> TM has address 193.223.78.213
> UZ has address 195.158.1.25
> WS has address 63.101.245.10
> 
> I can imagine that the primary motivation doing this is so that
> users can enter http://tld/ in a browser and find themselves at an
> appropriate page.
> 
> But I expect the user's domain search list takes priority if one
> of the searched domains has a name matching the TLD.

	Correct.  Single label host names were supposed to disappear
	in the conversion to heirarchical host names.  All the above
	are not valid heirarchical host names (label count less
	than 2).
 
> But I'm wondering if there are any negative side-effects?

	Yes.  You can't use single label hostnames reliably in a
	global context.  Single label hostnames have local context
	only.

	http://tld/, then user at tld then ...

	It's a slippery slope we don't want to go down.  I don't
	want to have to rename machines just because ICANN creates
	a new TLD that happens to matches a name I've chosen for the
	last label.

> Do these TLDs receive traffic that they shouldn't or don't want
> because of the apex A record?  Maybe some mis-directed SMTP?

	Possibly.  More likely if there are AAAA records due to
	running AAAA searches first.

	The records are just plain dangerous to have and the TLD's
	should know better.  This is akin to the problems that
	resulted in RFC 1535 being written.  Unexpected matches
	occuring.

	Mark
 
> Duane W.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org