.dk-TLD-problems

Hi djb-people

Sorry if this is off-topic, but we are a little desperate since the
Danish NIC, DK-Hostmaster has changed their procedures.

Since Aug. 30th redelegation has included 'check for handeling lame 
delegations'. This entails asking for a RR that is definetly not
hosted on the authoritative nameserver you want to redelegate to, 
and expecting an NXDOMAIN answer. If the new authoritative 
nameservers do not answer and the client has to timeout, the
redelegation procedure fails (output below), thus it is AFAIK not 
possible to redelegate to namesevers running tinydns at all.

We have not had confirmation from the NIC that this is exactly what
is going on, but this is how it looks from our dialogue with their
supporters, error messages, sniffing and general knowledge.

The way tinydns works if asked for a domain not hosted on the server, 
is just not answering and the client has to time out. The principle 
is - if you ask a tinydns server for a domain not delegated to it, 
it is you who are doing something wrong, authoritative and recursive
are two different things, so there is no need for NXDOMAIN's there. 

If I have misunderstood something, our tinydns' are misconfigured 
and the validation procedure is justified, things would be easier - 
so feel freee to confirm that, neither I nor the djbdns-people I know 
are experts on the matter.  

Another part of the check involves checking if serial in the SOA is 
the same on all of the new authoritative nameserveres, and we have 
a special setup which means that the serials are normally not the 
same. This should also not be any of the NIC's business, but it is 
easier to work around.

If there is anybody on the list with this problem or anyone who has
an elegant solution, or can tell us if we are the ones who are doing
something wrong, we are a few DNS-hosters/ISP's in Denmark who would 
appreciate your input.

Regards,
Tommy Mogensen

---
No reply from name server [gtld-servers.net,NS,IN].
Packet loss, high latency, misconfigurations or firewalls are a common
cause for errors like this. Timeouts on a lame delegation makes it take
even longer for others to find the desired RRs, and highly increase the
vulnerability to the July 2008 "Kaminsky"-attack. Some name server
implementations also believe they should not reply to lame delegations,
but this is against the spirit of the DNS protocol (RFC1034 section 3.7) 
and hinders attempts of lame delegation detection the way it has been 
recommended in e.g. BCP123/RFC4697 section 2.2.1.