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

Fri Aug 3 11:39:20 UTC 2007

Lutz Donnerhacke wrote:
> 
> 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.
> 

Looking at .um you can see the mess. (No, it is not the root)

They have a very old "timestamp" but they keep changing the .um zone
nevertheless.

Yes, I know, it is a serialnumber it was never meant to be a timestamp.
Look at the root:

   2007-08-03 (215) 00:39:02 loc
   2007-08-02 (214) 22:39:02 UTC

Root-Servers SOA records

soa(".","2007080200","a.root-servers.net","198.41.0.4").
soa(".","2007080200","b.root-servers.net","192.228.79.201").
soa(".","2007080200","c.root-servers.net","192.33.4.12").
soa(".","2007080200","d.root-servers.net","128.8.10.90").
soa(".","2007080200","e.root-servers.net","192.203.230.10").
soa(".","2007080200","f.root-servers.net","192.5.5.241").
soa(".","2007080200","g.root-servers.net","192.112.36.4").
soa(".","2007080200","h.root-servers.net","128.63.2.53").
soa(".","2007080200","i.root-servers.net","192.36.148.17").
soa(".","2007080200","j.root-servers.net","192.58.128.30").
soa(".","2007080200","k.root-servers.net","193.0.14.129").
soa(".","2007080200","l.root-servers.net","198.32.64.12").
soa(".","2007080200","m.root-servers.net","202.12.27.33").

Rollover will occur in the year 2147 at december 31.
January 1st 2148 will be a negative number on many systems

This is .um

SOA records

error("um","VENERA.ISI.EDU","128.9.176.32","no response").
error("um","NS.UU.NET","137.39.1.3","no soa").
soa("um","2006120115","ns.isi.edu","128.9.128.127").
soa("um","2006120115","flag.ep.net","198.32.4.13").
soa("um","2006120115","unldns.unl.edu","129.93.1.1").
soa("um","2006120115","berkeley.ip4.int","204.61.208.98").

I have an old copy that did not show any dnssec records by
december 2006. Today they have. And they did not increment
the serialnumber. Maybe that is why the root knows only one
of their servers.

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

When web interfaces to let users update their zonefile themselves
came up, it made a lot of sense to use a timestamp as serialnumber.
It always increments in a preditable way. Whenever you touch the
zone-file it "increments" the serialnumber.

>>	The first thing is to only change the serial when it needs
>>	to be changed and not twice daily.

The root-zone is built from a database. It is built twice per day
and it is so easy to use a timestamp as serialnumber.

If we looked for changes and somebody else looked into the same
database at the same time then changes would very likely outtrick
eachother. Then we easyly could create a mess of serialnumbers.

On the other hand you can have your own database and compare your
data with the root data, updating manually. Then you can update
your serialnumber only when needed. That is what we are doing at
the Cesidian Root. Sometimes it stays constant for a week or so

Look at ORSN

soa(".","2007072700","a.orsn-servers.net","217.146.128.77").
error(".","b.orsn-servers.net","62.116.33.87","no response").
soa(".","2007072700","c.orsn-servers.net","212.7.160.13").
soa(".","2007080100","d.orsn-servers.net","195.226.7.66").
soa(".","2007072700","e.orsn-servers.net","213.161.0.90").
soa(".","2007072700","f.orsn-servers.net","91.143.115.242").
soa(".","2007072700","g.orsn-servers.net","72.232.109.50").
soa(".","2007072700","h.orsn-servers.net","213.144.148.130").
soa(".","2007072700","j.orsn-servers.net","193.93.167.222").
soa(".","2007072700","k.orsn-servers.net","217.173.157.225").
soa(".","2007072700","l.orsn-servers.net","192.83.249.100").
soa(".","2007072700","m.orsn-servers.net","213.145.82.34").

They do keep their serialnumber constant for a very long time.
And they do double check before migrating their data.

It would be fun to use their data id they only allowed axfr
or ftp of the root-zone data.

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

That is one of the problems with DNS mutating to a flatfile.

DNS was designed a hirarchical tree. Root and nodes should have
very much the same size.

With more than 85% of all hosts having at least one .com entry we
could easyly get rid of the root and automatically append ".com"
to every entry we are looking for. If we dont find it simply try
".net", ".org" and ".info" on the same servers.

With working people beeing on the move most of their time ccTLDs
dont make sense. Try to get an .aero domain when you reading your
emails aboard an airplane most of your time.

.eu is a domain for namesquatters only. Two sunrise fiascos helped
the bastards to get whatever they wanted. The 2000 dollar regulation
in case of somebody fighting for his right on a name helped them
to keep it.

.su will be the next fiasco. Most of them are non russians so moving
to .com is best they can do.

.ru is so wellknown that most of the rest will run for .com too.

Dont forget .su is one of the biggest ccTLDs. Nevertheless they
are looking into sunset.

Cheers
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
mail: peter at echnaton.arl.pirates
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/