major improvements in DynDNS from Bind9 til Bind9

Kevin Darcy kcd at daimlerchrysler.com
Fri Feb 24 23:50:43 UTC 2006


Roman Mashak wrote:

>Hello,
>
>what are the main improvements in DDNS functions happened since last
>version of Bind8 was released? I wonder this cause I'm planning to
>upgrade our current DNS server serving solely DynDNS requests and
>zones and would like to know perfectly where to expect pitfalls.
>
>Sure I checked Changelogs, but they seems to be too terse to give
>detailed descriptions. As people here already claimed about painless
>upgrade from 8.x to 9.x I want to be ensured neveretheless :-)
>  
>
One *big* gotcha is that if you are serving both a child and a parent 
zone on BIND 8, and the parent zone is Dynamic Update-enabled, 
*there*are*no*delegation*records* for the child in the parent zone's 
zonefile. This is relatively harmless on BIND 8, since NS records from 
the child will be mixed into any zone transfers of the parent zone. 
Upgrade to BIND 9, however, it enforces better zone boundaries, those NS 
records are *no*longer* replicated to the slaves, so for any of the 
parent-zone slaves that don't happen to also be slaves for the child 
zone, the child zone doesn't exist, as far as they are concerned, and 
they will give an NXDOMAIN answer for the zone to any iterative resolver 
that asks them. In our case, right after we upgraded to BIND 9, but 
before we allowed any zone transfers from the newly-upgraded master 
server, we wrote a script to duplicate the apex NS records from each 
child zone as delegation records in the corresponding parent zone.

I guess this gotcha is hinted at in "6. No Information Leakage Between 
Zones" in doc/misc/migration, but my opinion is that the entry should be 
rewritten to be less focused on stub zones and more emphatic, like "YOUR 
CHILD ZONES MAY DISAPPEAR FROM THE FACE OF THE EARTH IF YOU DON'T DEAL 
WITH THIS!". It's a very dangerous trap for the unwary. We were 
fortunate to have caught this in testing before we actually upgraded 
production.

                                                                         
                                                - Kevin




More information about the bind-users mailing list