Domain unresolved in Singapore

[Mark Andrews]

> This is something I get asked from time to time: How big a deal is it  
> that the servers have one set of names in the delegation, and another  
> set of names in the authoritative NS records? I mean, assuming the  
> names all resolve to the same set of addresses, as is the case here?
> 
> $ dig +short ns1.guentner.co.id ns1.guentner-asiapacific.com  
> ns2.guentner.co.id ns2.guentner-asiapacific.com
> 222.124.211.227
> 222.124.211.227
> 222.124.211.228
> 222.124.211.228
> 
> Now granted, using the .id names in the delegation means there's no  
> glue with the delegation, so this adds 3 extra queries to the  
> resolution, but we're still talking about roughly the same amount of  
> work for the resolver as www.yahoo.com.

	There is no glue for those nameservers.  All that is required
	for this delegation to break is for the address records to
	be remove from the cache before the NS records.

	There is nothing that requires that it does not happen.  A
	cache is free to remove any RRset at anytime.  Not all
	removals from the cache are TTL based.  Some are random.
	Some are LRU based.

	Add to that caches prefer the child's NS RRset, you get
	into states where you can't get the address records for
	the nameservers.

	Now registries are supposed to check for this sort of error
	or ensure that the check are made.  Some actual do.  Many
	however don't.  RFC 1034 places this requirement on the
	registry as it is the parent zone in this case.

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org