(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