Subject: [dnsext] Zones suitable for AXFR

From: [email-masked]
Date: Wed, 5 Nov 2008 14:16:03 +0000

A comment on draft-ietf-dnsext-axfr-clarify-09:

Section 3.1 includes the paragraph:

> Zones for which it is impractical to list the entire zones for a serial
> number (because changes happen too quickly) are not suitable for AXFR
> retrieval.

I can see the difficulty in handling this case, but doesn't this statement 
almost make it a requirement that AXFR must not handle such zones?  RFC 
1035 (section 6.3) suggests that the decision is down to the 
implementation:

> If a master is sending a zone out via AXFR, and a new version is created
> during the transfer, the master should continue to send the old version
> if possible.  In any case, it should never send part of one version and
> part of another.  If completion is not possible, the master should reset
> the connection on which the zone transfer is taking place.

Stephen

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Wed, 05 Nov 2008 18:04:03 +0100

>> the connection on which the zone transfer is taking place.

I think it's fine to send a mix of multiple versions, with two
caveats: For each name, one version is chose that applies to all
RRsets for that name, and the served data is not less consistent than
any of the zone versions involved (for example, regarding restrictions
on names imposed by NS/CNAME/DNAME records in the zone).

The rationale is that for a client, it's not observable if a
flip-flopping view of the zone is due to this transfer behavior or
other factors (anycast, AXFR delays etc.).

I understand that for audit purposes, having two distinct copies with
the same serial could be a significant headache.  But I suppose
preventing this should be a SHOULD, not a MUST.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Nov 2008 11:17:23 -0500

Dear colleagues,

[no hat]

On Wed, Nov 05, 2008 at 06:04:03PM +0100, Florian Weimer wrote:

> I think it's fine to send a mix of multiple versions

I don't think that's fine, and I think it would be a very bad idea to
weaken at all the language in RFC 1035 sec 6.3.  I read the existing
text as being somewhat more prescriptive than a 2119 SHOULD (although
still obviously not a MUST).  My interpretation is based on the word
"never", which is a universal even though should is not imperative.
If there were to be room for deviation, the text should properly read
"should almost never" or "should avoid".  Of course, RFC 1035 is not
holy writ, and we could change it if that were desirable.  But I think
it is not.  See below.

> For each name, one version is chose that applies to all

The problem I have with this is that there is currently one actor that
can introduce inconsistency, and that's the zone administrator (maybe
due to automated tools that update the zone data without updating the
SOA serial number).  The proposal to allow continued flow of AXFR when
the underlying data changes introduces a completely new actor into the
mix: the transferring server itself.  In such a case, it is
indeterminite even from the point of view of the administrator when an
inconsistent version of the zone could show up.

If we approach the DNS as a distributed database, then introducing new
vectors for consistency failure seems to me like a bad idea --
especially ones where nobody can say with certainty when the
consistency failure could happen.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Nov 2008 15:35:18 -0500

It's good to have a few days at home and to catch 
up on some reading.  I had missed this thread 
until now.

At 11:17 -0500 11/11/08, Andrew Sullivan wrote:
>weaken at all the language in RFC 1035 sec 6.3.

I agree with Andrew.

What prompted me to mention zones "not suitable 
for transfer" was a situation in which the data 
being used in a response was cobbled from a few 
non-DNS sources on demand in response to the 
query.  (The data was then subsequently "cached" 
for some number of minutes related to the nature 
of the data.)  This is an example of a lookup 
system that uses the data formats sent on the 
wire into and out of port 53 (and the protocol 
semantics) but does not conform to our 
conventional wisdom of what constitutes an 
authoritative name server.

It isn't the situation that there are multiple 
versions of a zone live at anytime.  Just as each 
dynamic update unit (for what ever a unit means) 
increments the serial number, each modification 
of the cache of authoritative data changes the 
serial number of the "zone."  In such a 
situation, an AXFR reply is pretty much 
meaningless - I mean - you could create one but 
due to the dynamic nature of the zone, it has no 
value.

(Imagine NSEC or NSEC3'ing this zone!)

So, what was written in -09 wasn't meant to issue 
a challenge to what was in RFC1035/6.3 but a 
reflection of a use of the DNS not anticipated at 
the time of that document.

>can introduce inconsistency, and that's the zone administrator (maybe

There really can't be any inconsistency because 
there's no notion of consistency.  It's just that 
you can't put your arms around the collection. 
It's like trying to identify every person in a 
country at any one point - births, deaths, 
immigration, emigration, etc.  Or like that thing 
in physics class where the instant you try to 
measure a system you change it.

(Trying to seem educated, I'll thrown in this reference:
http://en.wikipedia.org/wiki/Schrödinger's_cat

I think it relates to what I'm trying to say. 
Exercise to the bored and otherwise unoccupied 
reader. If anyone tells me I'm wrong, I'll not be 
insulted and actually heartened to know someone 
read this far.)

>inconsistent version of the zone could show up.

By "not suitable for transfer" I mean there is no 
flow of AXFR, none at all, therefore no chance 
for any inconsistency.

E.g., what's wrong with this?:

Time 0: Q: www.example.tld/IN/A ==> R: www.example.tld/IN/A/127.0.0.1
Time 1: Q: example.tld/IN/AXFR ==> R: example.tld/IN/SOA, NS set, and SOA again
Time 2: Q: www.example.tld/IN/A ==> R: www.example.tld/IN/A/127.0.0.1

It could be the result of this:

1) Query/Response for the address
2) Dynamic delete of the address
3) Query/Response for the AXFR (showing an empty/minimal zone)
4) Dynamic addition of the address (back as it was before)
5) Query/Response for the address

>consistency failure could happen.

"...introducing new vectors for ... failure" is "a bad idea". ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.