Subject: Re: RFC2136 question as it relates to QIP

From: [email-masked] (Mike Dooley)
Date: Thu, 11 Nov 1999 16:28:25 -0500

From: Paul A Vixie <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: namedroppers <[email-masked]>
Date: Thursday, November 11, 1999 3:22 PM
Subject: Re: RFC2136 question as it relates to QIP

>> Recently I learned that (Lucent) QIP port of BIND 8.1 implemented DNS
>> Update "execution" in cached zone on the slave server. This fits into
>> their larger DNS management scheme, where the sender of DNS Update
>> packets knows about all nameservers authoritative for the domain and
>> sends update packet to each of them, removing the need for NOTIFY (and
>> subsequent IXFR) traffic.
> this will lead to incoherence among so-called "authority" servers, and is
> bad.  (a client may not be able to reach all servers, and may not be able
> to back out changes committed on one server after failing to reach one of
> the others.)  >

Just for clarification ... Paul is correct for a DNS only environment ...
however in this case, the authority is the QIP database, not DNS.

>> RFC 2136 doesn't really discuss such a case, but doesn't seem to
>> explicitely prohibit it either. Below is the closest statement to the
>> issue I found:
>>
>> 3.1.1. The Zone Section is checked to see that there is exactly one
>>    RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
>>    requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
>>    so named is one of this server's authority zones, else signal NOTAUTH
>>    to the requestor.  If the server is a zone slave, the request will be
>>    forwarded toward the primary master.
>>
>> It seems to be "compatible" as long as the slave keeps forwarding the update
>> message to the master and sends response to the update packet only after
>> receiving the response from the master. There is a question of SOA serial
>> number - QIP slave server doesn't increase the serial number after executing
>> the update locally - this makes the whole thing a bit non-transparent, but
>> doesn't break anything.
>
> since the slave doesn't know whether the master actually will honour the
> update (for reasons of reliability, or policy change), the update can NOT
> be applied locally.

Again ... In a QIP implementation, the QIP database is the authority ... not
DNS.

>> QIP primary master behaves normally.
>>
>> Does it mean the server is RFC non-compliant ?
>
> yes.

For clarification ... This is an "option" extension that can be turned on or
off within the Lucent DNS server for full RFC compliancy.

-Mike