Subject: [dnsext] matching begin/end SOA in AXFR

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 13 Apr 2010 12:34:23 -0700

Hello,

I've recently found something not very clear in
draft-ietf-dnsext-axfr-clarify-14.  I think it's quite minor and
doesn't affect the current state of the document (in RFC editor
queue), but I'd like to see clarification here.

In Section 2.2 the I-D states:

   An AXFR response that is transferring the zone's contents will
   consist of a series (which could be a series of length 1) of DNS
   messages.  In such a series, the first message MUST begin with the
   SOA resource record of the zone, the last message MUST conclude with
   the same SOA resource record.

In general this seems to be a reasonable requirement, but some details
are not clear to me:

1. why the first and last SOAs "MUST" be the same in the first place?
2. what's the definition of same?  Does this mean SOA RRs that have
   the same owner name and class (and perhaps TTL?).  Or does this
   require the RDATA be the same, too?  If the comparison covers any
   domain name (some or all of owner name, mname and rname), is it
   case sensitive or not?
3. what should the recipient do if these two SOA RRs are not "same"?
   Should it abort the AXFR or just ignore the mismatch and keep
   going?
   
As for 1, someone told me that this would probably be to "cover the
case of an authoritative nameserver that didn't lock down zones while
serving AXFR, so there was some possibility that the SOA serial number
of the second SOA in an AXFR would not match the first SOA".  If
that's the intent, it makes sense to me (although I suspect it's
unlikely we have had or will this type of buggy authoritative server
implementation).

Regarding question #2: If point 1 is the rationale of the requirement,
it would probably be sufficient to match the SOA serial field in
practice, ignoring all other fields even including the owner name.
But, assuming we should at least match one field of the RDATA
(i.e. serial), a more natural interpretation would be that all fields
of the two SOA RRs including the class and TTL should match, and names
are to be compared (after de-compression) in case insensitive manner.

I'm still not sure about question #3.  If we introduced this
requirement to catch a bug of the primary server implementation of the
AXFR as described above, I believe the AXFR session should be aborted;
otherwise the primary and secondary servers would have inconsistent
contents for the same serial version of the zone.  On the other hand,
if we actually didn't care about such an unlikely bug and this
requirement was for some minor purpose like predictability, maybe
"MUST" might have been too strong (although I'm not opposing to the
keyword, especially at this stage).

BTW, from my quick read of source code, neither of two commonly used
authoritative server implementations, namely BIND 9 and NSD, even
compares the two SOAs.  So, even if a serial mismatch happened these
implementation simply accept the AXFR'ed data.

---
JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Apr 2010 16:23:55 -0400

The MUST comes from antiquity.  Equivalence means bit-for-bit the same.

Everything else I'll say is conjecture.

On send, it's easy to "just require it" as a end of transfer sentinel.

What if it isn't there?  What if the SOA isn't the same?  What if the 
SOA has the same serial number but other elements change?

All fair questions.  But I don't know if they are "major" questions. 
(Are they?)

It's not exactly a case where you might confuse it with an IXFR 
(because the IXFR starts with the ending serial number, then lists 
deletes-SOA-adds by zone increment.

What if the SOA at the end (of the transmission, that is before the 
TCP is torn down) isn't right?  I think if the client sees the 
transport fall, then they should consider there's a problem.  If the 
transport just goes quiet, the client has to decide how much time to 
allot an inactive connection.  In either case, is the transfer 
accepted.

I'd vote no.  Because this would make the slave fall behind and then 
expire the zone.  In that case, the admins would have something 
obvious to fix.

The fact that BIND and NSD don't check this, probably isn't a earth 
shattering problem.  But if you had to include a failure handler 
there, I'd say if the SOA isnt' exactly the same, fail the transfer.

Or is there some advantage to be loose here and say that any SOA ends 
the transfer and leave for the future some semantics if the SOAs do 
differ?

At 12:34 -0700 4/13/10, JINMEI Tatuya / 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Apr 2010 22:03:27 +0000

> Date: Tue, 13 Apr 2010 12:34:23 -0700
> From:	 JINMEI Tatuya / 神明達哉 <[email-masked]>
> ...
> As for 1, someone told me that this would probably be to "cover the case
> of an authoritative nameserver that didn't lock down zones while serving
> AXFR, so there was some possibility that the SOA serial number of the
> second SOA in an AXFR would not match the first SOA".  If that's the
> intent, it makes sense to me (although I suspect it's unlikely we have
> had or will this type of buggy authoritative server implementation).

very early BIND (before 4.8) could show this behaviour.

> Regarding question #2: If point 1 is the rationale of the requirement, it
> would probably be sufficient to match the SOA serial field in practice,
> ignoring all other fields even including the owner name.  But, assuming
> we should at least match one field of the RDATA (i.e. serial), a more
> natural interpretation would be that all fields of the two SOA RRs
> including the class and TTL should match, and names are to be compared
> (after de-compression) in case insensitive manner.

i agree.  there's supposed to be an identity mapping between the SOA.SERIAL
and the content of the zone.  the other fields of the SOA, and its TTL, are
part of the zone.

> I'm still not sure about question #3.  If we introduced this requirement
> to catch a bug of the primary server implementation of the AXFR as
> described above, I believe the AXFR session should be aborted; otherwise
> the primary and secondary servers would have inconsistent contents for
> the same serial version of the zone.  On the other hand, if we actually
> didn't care about such an unlikely bug and this requirement was for some
> minor purpose like predictability, maybe "MUST" might have been too
> strong (although I'm not opposing to the keyword, especially at this
> stage).

i think MUST and "abort" are right.  otherwise we can theoretically have
incoherent authorities.

> implementation simply accept the AXFR'ed data.

BIND>=4.9 through BIND<9 only compared the serials.  BIND<4.9 didn't look
at the second serial number at all but did require a final SOA.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 Apr 2010 08:10:11 +0900

> So, even if a serial mismatch happened these

It's no DNS specific.

"Be liberal in what you accept. Be conservative in what you send."

That's all.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Apr 2010 08:28:18 -0400

At 20:59 -0700 4/13/10, JINMEI Tatuya wrote:

>Hmm, so no one knows or remembers the real rationale?

You may have to contact PVM, maybe Rob A.  Don't know who else would 
have a memory that far back.

And remember, that the "clarify" document is not out to redefine (any 
more than it does so already) the mechanism.  So that's why I don't 
think the WG should spend much energy on this.

>Okay, but "bit-for-bit" is still not very clear: is this "bit-for-bit
>but case-insensitive for names" or "strict" bit-for-bit as opaque data
>(so names are compared case-sensitively)?  "bit-for-bit" could also be
>unclear because some fields of the SOAs may be compressed.

How about "bit-for-bit after undoing the compression" then?  I.e., same RDATA.

It's not like the SOA's are coming from different sources (servers).

>I don't think these are major issues.  I basically just wanted to be
>sure about some unclear points of the specification.

Are you unclear on the original specification or is it that major 
implementations differ from the specification?

Looking at RFC 1034, s4.3.5:

"The first and last messages must contain the data for the top 
authoritative node of the zone."

and in 6.3:

"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."

 From these two passages, I take it that the SOA is needed and is to 
be the same.  Now, the "top authoritative node of the zone" could 
mean all apex records (those owned by the name with the SOA - the NS, 
DNSSEC stuff, ...).  Is the question that the "clarify" is changing 
this by stating specifically just the SOA RR?

Note that it is legal today (or it would work today to send this):

zone.tld.     SOA    ser_no_4
www.zone.tld. A
zone.tld.     RRSIG  NSEC
www.zone.tld. RRSIG  NSEC
zone.tld.     DNSKEY
www.zone.tld  RRSIG  A
zone.tld.     NS
zone.tld.     RRSIG  SOA
zone.tld.     RRSIG  NS
zone.tld.     NS
zone.tld      RRSIG  DNSKEY
zone.tld.     NS
zone.tld.     NSEC   www.zone.tld.
www.zone.tld. NSEC   zone.tld.
zone.tld.     SOA   ser_no_4

(Imagine each of these in a separate AXFR message unit too.)

Given this from 5.2 in RFC 1035:

    2. Exactly one SOA RR should be present at the top of the zone.

That really only the SOA's mere presence can signal the end of the 
zone (as opposed to another NS to the NS set).

So, I think there's little question that the start and end have to be 
the same SOA.  If implementations don't check this, well, that's 
implementations being implementations.  If they check and drop the 
transfer or check and keep it anyway, or don't check at all, well, 
that's implementations being implementations.

Implementers have done worse things to the protocol in the past. ;)

The answers to all this would lie in the "who does know why" this was 
set way back when, as the documents leave something to the 
imagination.

>This is basically what I was thinking: It's probably not a big deal
>anyway and can be considered an "implementation dependent behavior";
>but if we want to handle this case explicitly the right choice would
>be to fail it (rather than ignore the mismatch).

I thought about this after my last reply.  Maybe the very next SOA 
seen (different owner, different serial number, same...) should "end" 
the transfer and if the SOA isn't the "same" then the transfer is 
considered a failure.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 14 Apr 2010 12:41:57 -0700

At Wed, 14 Apr 2010 08:28:18 -0400,

> implementations differ from the specification?

It was primarily about unclear on the specification, but at that point
I wasn't aware of the "original specification" in RFC1034 (I only

> authoritative node of the zone."

[...]

> this by stating specifically just the SOA RR?

No, I just didn't know the statement of axfr-clarify draft in question
came from this part of RFC1034.  With this reference the meaning of
"same" is clearer.

> the transfer and if the SOA isn't the "same" then the transfer is 

That's what I would do for a newer implementation if I chose to "do
something" about the SOA mismatch case.

Thanks,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Apr 2010 15:56:51 -0400

> came from this part of RFC1034.  With this reference the meaning of

Does this suggest a clarifying reference maybe ought to be added to
the draft?  That's certainly easy enough to add even at this late stage.

A

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