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