To:
dnsop@cafax.se
From:
Gunnar Lindberg <lindberg@cdg.chalmers.se>
Date:
Mon, 28 Jun 1999 15:11:57 +0200 (MET DST)
Sender:
owner-dnsop@cafax.se
Subject:
Primary also being secondary
I'm not sure if this belongs here, but I am sure you'll redirect :-). This is real life, although I've modified some names to make it a little less confusing. SW is bind-8.1.2. : chalmers.se. IN NS ns1.chalmers.se. pri : IN NS ns2.chalmers.se. sec : : hemmet.s-hem.chalmers.se. IN NS glutus.hemmet.s-hem.chalmers.se. pri : IN NS ns1.chalmers.se. sec So, this is a delegated subdomain, where the upper domain's primary is also secondary for the delegated domain. Straight forward. Between them they share NS(hemmet.s-hem.chalmers.se) info, and this is where my report/question comes in. Now, the people at hemmet.s-hem.chalmers.se screwed up their NS info: : hemmet.s-hem.chalmers.se. : IN NS glutus.hemmet.s-hem.chalmers.se.hemmet.s-hem.chalmers.se. : IN NS ns1.chalmers.se.hemmet.s-hem.chalmers.se. We've all done this at least once... ns1.chalmers.se noticed the higher version number and fetched the zone, including the erronous NS(hemmet.s-hem.chalmers.se). This did *not* change the SOA version for zone chalmers.se. Later on, there were other changes made to zone chalmers.se and the SOA version was changed. ns2.chalmers.se noticed and fetched the data; and now got the erronous NS(hemmet.s-hem.chalmers.se) - the erronous one that ns1.chalmers.se fetched some time ago and obviously installed in zone chalmers.se. The people at hemmet.s-hem.chalmers.se soon found the error, fixed it and incremented their SOA version. ns1.chalmers.se fetched again, with correct info this time. However, SOA(chalmers.se) was not updated, so ns2.chalmers.se did NOT fetch any new data; instead it was stuck with the erronous NS(hemmet.s-hem.chalmers.se) info. My conclusion is that, at least in bind-8.1.2, the delegated zone's version of the shared NS-info gets precedence over the delegating zone's version (the config file). Although I can see cases where this may be good and useful I'm not sure this is generally so - the case above is one counter example. I've not found anything in the RFCs that tell which one is considered "correct" or even "better". My 1c is that this is wrong and that the data sent to a secondary, i.e. AXFR, should be the original data from the config file(s), and not be a "copy of a copy". Gunnar Lindberg