Subject: Re: RFC2136 question

From: [email-masked]
Date: Tue, 16 Nov 1999 17:33:53 -0500

Understood.

Here is one side issue. Reading through the comments, I recalled other
self-consistent, but AXFR/IXFR RFC non-compliant DNS systems such as Cisco
Distributed Director, or some TN3270 gateways, that generate responses to DNS
queries on the fly based on some external information. These are essentially
dynamic, zone-transfer free environments, and in most cases don't care about
serial numbers at all. And they are indeed not intended to be mixed with other
DNS servers for serving the same domain. Now  would you call these breaking RFC
compliancy ?

Clearly, there are two levels of DNS server compatibility, one is the
query-level, where all these products comply, and the other is the zone transfer
(SOA serial handling, AXFR/IXFR, NOTIFY) level. I'm not sure this distinction
can be expressed in RFC compliancy terms, though.

Honza

> You've got a very good point about a need for SOA check before executing the
> change on the slave.

As I said (separately from what Robert said about checking the SOA), the
slaves can't really know if the master plans to honour the update.  To make
multiple masters work in the current DNS, each "authority" ("zone") server
has to have equal access to an out of band storage and transfer mechanism.
That's how Microsoft describes their LDAP-based ADS, and while I have no
idea whether I'd trust my data to it, it's a consistent model from DNS's
point of view.

> There remains one thing I'm not clear on. Is it a no-no for a DNS server to
> present different data at different times with the same SOA serial number ?

Yes.

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 16 Nov 1999 16:02:34 -0800

> Distributed Director, or some TN3270 gateways, that generate responses to
> DNS queries on the fly based on some external information. These are
> essentially dynamic, zone-transfer free environments, and in most cases
> don't care about serial numbers at all. And they are indeed not intended to
> be mixed with other DNS servers for serving the same domain. Now would you
> call these breaking RFC compliancy ?

not necessarily, and not because of things you mentioned above.  but consider:

> query-level, where all these products comply, and the other is the zone
> transfer (SOA serial handling, AXFR/IXFR, NOTIFY) level. I'm not sure this
> distinction can be expressed in RFC compliancy terms, though.

there is no such distinction.  if you implement dns then you have to generate
answers which map the identity of <time,question,answer> and if you expose a
different mapping between <t1,q1,a1> and <t2,q2,a2> then the sign of the
difference between <t1> and <t2> has to be the same as the sign of the
difference between serial numbers <t1,qSOA,aSERIAL> and <t2,qSOA,qSERIAL>.  i
climbed all over cisco for violating this invariant, and they fixed it (or
said they would fix it) by answering with monotonically increasing serials
no matter whether the zone had changed or not.

in the case of an implementation like Microsoft's LDAP-based ADS, they have
to do at least that much, and if they can't generate a consistent AXFR using
similar techniques, then they should refuse all AXFR's (which is allowed by
rfc1034 for policy reasons, of which this is one).