[dns-operations] FreeBSD and the slaving of the root zone

Lutz Donnerhacke lutz at iks-jena.de
Fri Aug 3 08:40:58 UTC 2007

* Mark Andrews wrote:
>> 	1) Resolvers usually only ask for records they know about.
>> 	What happens if they AXFR from the root and it contains
>> 	records they don't understand?
> 	See RFC 3597, Handling of Unknown DNS Resource Record (RR) Types.

Mircosoft DNS Server on Windows 2003 does understand DNAME, but handle it in
the wrong way (failing to parse and concluding to SERVFAIL). There is a
hotfix (only available via Mircosoft Partners on explicit request) which
changes the DNAME code number to an experimental one in the parser code.

Other applications, like qmail, assume every DNS packet to fit into 512
bytes and do only provide such a buffer, while ignoring the truncation flag.
Sending mail to DNSSEC domains fails with "Temporary CNAME error".

*.GTLD-SERVERS.NET did not respond to EDNS0 queries at all until a few
months ago.

Summary: This world contains a lot of broken software.

>>         3) If someone screws up the serial number of the root zone,
>>         there could be an interesting mess to clean up.
> 	What mess?  Serial numbers roll over.

A lot of "home brew" software authors do not understand the serial number
arithmetics and count it senseless, because in the rare case of problems you
have to contact your administrator anyway. Therefore there is a lot of
simple minded comparation code out there. (even several of my scripts.)

>>         4) Are there sensible values for expire, retry and refresh
>>         if this scheme was in use? How often should the serial
>>         number really be incremented?
> 	The first thing is to only change the serial when it needs
> 	to be changed and not twice daily.

We are going to sign the root, changes will occur nearly daily.
(I do have an average of serial increments every two days at my signed root)

For COM the classical IXFR and AXFR distribution mechanisms are not
applicable at all. Other TLDs share the same problem.

More information about the dns-operations mailing list