Domain unresolved in Singapore

[Chris Buxton]

Mark, I believe you're mistaken. There are glue records for these  
servers, in the .id zone; they do not depend on cache.

$ dig guentner.co.id +norec @NS1.id

;; AUTHORITY SECTION:
guentner.co.id.		1800	IN	NS	ns2.guentner.co.id.
guentner.co.id.		1800	IN	NS	ns1.guentner.co.id.

;; ADDITIONAL SECTION:
ns1.guentner.co.id.	13300	IN	A	222.124.211.227
ns2.guentner.co.id.	13300	IN	A	222.124.211.228

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to which  
it is addressed. If the reader of this message is not the intended  
recipient, you are hereby notified that any retention, dissemination,  
distribution or copy of this e-mail is strictly prohibited. If you  
have received this e-mail in error, please notify us immediately by  
reply e-mail and immediately delete this message and all its attachment.



On Feb 19, 2008, at 4:15 PM, Mark Andrews wrote:

>
>> 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