(no subject)
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Tue Mar 6 22:46:32 UTC 2001
> I am having some difficulties understanding some of the workings
> that are happening with BIND 8. (currently testing with 8.2.2p5)
See http://www.isc.org/products/BIND/bind-security.html
>
> 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?
Basically the client only wanted the action to succeed if
the record was there. This is not a error. It is just a
way of ensuring the zone has not changed between testing
and performing the update.
>
> 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?
Kevin already addressed this.
>
>
> Thanks,
> -k
>
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at nominum.com
More information about the bind-users
mailing list