kcd at daimlerchrysler.com
Tue Mar 6 19:05:09 UTC 2001
Kevin M Shortt wrote:
> I am having some difficulties understanding some of the workings
> that are happening with BIND 8. (currently testing with 8.2.2p5)
> I exhaustedly searched archives and even read RFC2136.
> I am having trouble accepting the following behavior.
> Concisively put, I have win2k boxes updating a zone on BIND 8.2.2p5
> server. When the win2k box attempts to update an RRSET for itself, the
> prerequisite RCODE from BIND 8.2.2p5 is (NXRRSET) gets returned when
> the RRset (or A record) was not in the zone already.
> NXRRSET as defined in section 2.4.1 (RFC2136) and further explained in
> section 3.2.1 (RFC2136) is:
> Some RRset that ought to exist, does not exist.
> My Questions:
> Why (oh why) must the server error when an attempted update of an RR
> doesn't exist. The only known way (to me) to avoid these errors is to
> preexist the RR's in my zones. Wouldn't that defeat the purpose of DDNS?
NXRRSET isn't really an "error", it's just a return code. There's no
particular reason to try and avoid NXRRSET return codes. Everything is
working as designed.
> Also when the RCODE NXRRSET rears up, the DDNS seems to work fine, with
> exception that the zone file doesn't update until the server process is
> stopped or restarted. Why does work and keep in cache, but the zone file
> doesn't reflect a serial increment or the changed record?
Dynamic Update changes are written immediately to the ".log" file. The zone
is then dumped periodically to the zonefile. Why do you care when this
dumping occurs? You shouldn't be using the contents of the zone file for
any kind of time-sensitive process -- instead, you should be querying the
nameserver, which always has the latest version of the zone assembled in
More information about the bind-users