Subject: draft-ietf-dnsext-axfr-clarify-01.txt

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 18 Jul 2000 12:01:20 -0700 (PDT)

I was planning to update the axfr-clarify draft before Pittsburgh, but
due to a misunderstanding on my part, I missed the publication
deadline.  At Olafur's request, I'm sending the attached copy of the
updated draft (not yet officially published as an I-D) to
namedroppers.

The changes from the -00 draft are minor:

 - Two bits in the flags field are now referred to using their
   new DNSSEC names "AD" and "CD" rather than being part of the
   "Z" field.

 - A "Security Considerations" section has been added.

-- 
Andreas Gustafsson, [email-masked]

INTERNET-DRAFT                                      Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txt                     Nominum Inc.
                                                             July 2000

               DNS Zone Transfer Protocol Clarifications

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   In the Domain Name System, zone data is replicated among
   authoritative DNS servers by means of the "zone transfer" protocol,
   also known as the "AXFR" protocol.  This memo clarifies, updates, and
   adds missing detail to the original AXFR protocol specification in
   RFC1034.

1. Introduction

   The original definition of the DNS zone transfer protocol consists of
   a single paragraph in [RFC1034] section 4.3.5 and some additional
   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
   serve as the sole basis for constructing interoperable
   implementations.  This document is an attempt to provide a more
   complete definition of the protocol.  Where the text in RFC1034
   conflicts with existing practice, the existing practice has been
   codified in the interest of interoperability.

Expires January 2000                                            [Page 1]

draft-ietf-dnsext-axfr-clarify-01.txt                          July 2000

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2. The zone transfer request

   To initiate a zone transfer, the slave server sends a zone transfer
   request to the master server over a reliable transport such as TCP.
   The form of this request is specified in sufficient detail in RFC1034
   and needs no further clarification.

3. The zone transfer response

   If the master server is unable or unwilling to provide a zone
   transfer, it MUST respond with a single DNS message containing an
   appropriate RCODE other than NOERROR.

   If a zone transfer can be provided, the master server sends one or
   more DNS messages containing the zone data as described below.

3.1. Multiple answers per message

   The zone data in a zone transfer response is a sequence of answer
   RRs.  These RRs are transmitted in the answer section(s) of one or
   more DNS response messages.

   The AXFR protocol definition in RFC1034 does not make a clear
   distinction between response messages and answer RRs.  Historically,
   DNS servers always transmitted a single answer RR per message.  This
   encoding is wasteful due to the overhead of repeatedly sending DNS
   message headers and the loss of domain name compression
   opportunities.  To improve efficiency, some newer servers support a
   mode where multiple RRs are transmitted in a single DNS response
   message.

   A master MAY transmit multiple answer RRs per response message up to
   the largest number that will fit within the 65535 byte limit on TCP
   DNS message size.  In the case of a small zone, this can cause the
   entire transfer to be transmitted in a single response message.

   Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message SHOULD be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis.

3.2. DNS message header contents

Expires January 2000                                            [Page 2]

draft-ietf-dnsext-axfr-clarify-01.txt                          July 2000

   RFC1034 does not specify the contents of the DNS message header of
   the zone transfer response messages.  The header of each message MUST
   be as follows:

       ID      Copy from request
       QR      1
       OPCODE  QUERY
       AA      1 (but MAY be 0 when RCODE is nonzero)
       TC      0
       RD      Copy from request
       RA      Set according to availability of recursion
       Z       0
       AD      0
       CD      0
       RCODE   0 or error code

   The slave MUST check the RCODE and abort the transfer if it is
   nonzero.  It SHOULD check the ID of the first message received and
   abort the transfer if it does not match the ID of the request.  The
   ID SHOULD be ignored in subsequent messages, and fields other than
   RCODE and ID SHOULD be ignored in all messages, to ensure
   interoperability with certain older implementations which transmit
   incorrect or arbitrary values in these fields.

3.3. Additional section and SIG processing

   Zone transfer responses are not subject to any kind of additional
   section processing or automatic inclusion of SIG records.  SIG RRs in
   the zone data are treated exactly the same as any other RR type.

3.4. The question section

   RFC1034 does not specify whether zone transfer response messages have
   a question section or not.  The initial message of a zone transfer
   response SHOULD have a question section identical to that in the
   request.  Subsequent messages SHOULD NOT have a question section,
   though the final message MAY.  The receiving slave server MUST accept
   any combination of messages with and without a question section.

3.5. The authority section

   The master server MUST transmit messages with an empty authority
   section.  Slaves MUST ignore any authority section contents they may
   receive from masters that do not comply with this requirement.

3.6. The additional section

   The additional section MAY contain additional RRs such as transaction

Expires January 2000                                            [Page 3]

draft-ietf-dnsext-axfr-clarify-01.txt                          July 2000

   signatures.  The slave MUST ignore any unexpected RRs in the
   additional section.

4. Glue

   Zone transfers MAY contain glue RRs pertaining to NS records in the
   zone.  An RR is considered a glue RR when it is not within the zone
   being transferred.  A slave MUST recognize glue RRs as such; it MUST
   NOT treat them as authoritative data.

   Note that classifying an RR as glue or non-glue may not be possible
   until the entire zone has been received so that the zone cuts defined
   by the zone's NS records can be determined.

5. Transmission order

   RFC1034 states that "The first and last messages must contain the
   data for the top authoritative node of the zone".  This is not
   consistent with existing practice.  All known master implementations
   send, and slave implementations expect to receive, the zone's SOA RR
   as the first and last record of the transfer.  Any other RRs at the
   zone's apex are transmitted only once.

   Therefore, the quoted sentence is hereby changed to read "The first
   and last RR transmitted must be the SOA record of the zone".

   The initial and final SOA record MUST be identical, with the possible
   exception of case and compression.  In particular, they MUST have the
   same serial number.

   The transmission order of all other RRs in the zone, including glue
   records, is undefined.

6. Security Considerations

   The zone transfer protocol as defined in [RFC1034] and clarified by
   this memo does not have a built-in authentication mechanism.  The use
   of TSIG [RFC2845] for authentication of zone transfers is
   recommended.

   These clarifications are not believed to themselves cause any new
   security problems, nor to solve any existing ones.

References

   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
   November 1987.

Expires January 2000                                            [Page 4]

draft-ietf-dnsext-axfr-clarify-01.txt                          July 2000

   [RFC1035] - Domain Names - Implementation and Specifications, P.
   Mockapetris, November 1987.

   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
   S. Bradner, BCP 14, March 1997.

   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.

Author's Address

   Andreas Gustafsson
   Nominum Inc.
   950 Charter Street
   Redwood City, CA 94063
   USA

   Phone: +1 650 779 6004

   Email: [email-masked]

Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

Expires January 2000                                            [Page 5]

draft-ietf-dnsext-axfr-clarify-01.txt                          July 2000

   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expires January 2000                                            [Page 6]


to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Jul 2000 21:11:05 +0200

>    Zone transfers MAY contain glue RRs pertaining to NS records in the

For the ``real'' glue, this should be a MUST.

>    NOT treat them as authoritative data.

The latter would be very easy were glue RRs sent in the additional section,
but that's not backwards compatible. Should the document explicitly say that
the glue RRs belong into the answer section?

A problem with very large zones, such as certain TLDs, is the frequent
repetition of (sometimes even unnecessary) glue RRs, which increases the
amount of data to transfer. Even in the light of SIG RRs - do you see
a chance for recommending an optimization here?

>    of TSIG [RFC2845] for authentication of zone transfers is

It's clear that the source of data should be authenticated, but this
recommendation could easily be (mis?)read to suggest to allow AXFR only
to authenticated requestors. Whether or not one likes that advice, and I don't,
this is probably the wrong place for it.
In addition I'd suggest to insert "and integrity" after "authentication".

-Peter

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Jul 2000 18:05:49 -0700

>  entire transfer to be transmitted in a single response message.

In general I agree with this. It's smart, although it's also potentially
problematic in multiple scenarios.

>  SHOULD be settable on a per-slave basis.

Isn't there something that can be done with the flags to signify that
this should occur in-protocol? Like, since AXFR is a targeted send over
a TCP circuit, we *KNOW* that the flag isn't going to be useful. We also
know that several RESPONSE flags aren't going to be set in the query.
Couldn't we say something like: "if RD, RA and AA are set in the query,
the slave desires the compressed form".

Wouldn't that be the best approach instead of relying on manual configs
that may be outside the scope of control of a single administrator? It
would also allow heterogenous multi-tiered distributions to be
implemented without having to worry about what product supports what
feature. NetWare 6 do it? Who cares, the proto takes care of all that.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Jul 2000 22:12:13 -0700

>  NOT treat them as authoritative data.

This seems problematic. Since glue data is by definition data which is
outside the zone, including it in zone transfers not only wasteful but
is also extremely dangerous.

For example, let's say that somehow I've got my zone being served by
www.yahoo.com. and just for safety's sake I have glue data in the
ntrg.net. zone for that domain name. If I transfer the domain and the
glue data goes with it, the recipient may cache it, use it for answers,
or worse yet it may respond to requests for www.yahoo.com. with AA in
the response messages (it comes from an authoritative source, so AA is
possible and even likely).

A subsequent danger is that my slaves are masters for other slaves who
repeat this process. And because I have REFRESH of 1 week, this data is
out and running around in all of those downstream servers for a few
weeks until I wise up and remove the glue.

I'd say that glue data MUST NOT be sent during a zone transfer UNLESS
the glue points to a domain name that is within the scope of the domain
for the zone being transferred. The server will know this during the
transfer (it knows the scope of the zone and can filter on send easier
than slaves can filter on receipt) so it shouldn't be a burden. Well
worth the costs anyway if it stops bad data from floating around.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 20 Jul 2000 09:56:33 -0700

> > ntrg.net. zone for that domain name. If I transfer the domain and 

> This is not glue data but what usually becomes part of the additional
> section. You cannot have a RR for www.yahoo.com *inside* ntrg.net.

That's what I would like to see explicitly prohibited.

> > I'd say that glue data MUST NOT be sent during a zone transfer
> > UNLESS the glue points to a domain name that is within the scope
> > of the domain
> 
> What's the scope of the domain? Do you mean the subtree rooted at a
> zone apex, i.e. that zone and all its subzones, if any? Then I'd
> second your statement.

Yes. Any data for www.yahoo.com. would be outside the subtree under
ntrg.net. and would fall under the "MUST be filtered" rule by the server
before axfr occurs.

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 20 Jul 2000 07:05:31 -0700 (PDT)

> For the ``real'' glue, this should be a MUST.

I agree that a MUST is reasonable here, but could you explain what you
mean by "real" glue?

> but that's not backwards compatible.

Right.  If or when a new protocol is devised to replace AXFR, it
should separate the glue from the authoritative data.

> Should the document explicitly say that

Perhaps; I'll see if I can fit that in somewhere.

> a chance for recommending an optimization here?

We could certainly add something like this:

   Each glue record SHOULD be transmitted only once, even if it its
   name occurs in multiple NS records.

> to authenticated requestors.

Good point.  I will try to make it clearer that the issue is
authenticating the source and integrity of the data, not restricting
access to it.

> In addition I'd suggest to insert "and integrity" after "authentication".

Will do.

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 Jul 2000 14:10:10 +0200

> is also extremely dangerous.

Well, part of the problem is that this document provides for yet another
not backwards compatible definition of "glue" RRs. At least from a teaching
viewpoint this is suboptimal and that's why I mentioned the ``real'' glue
in my previous message.

> possible and even likely).

Andreas' document clearly states that this MUST NOT happen. But then, it's
still not prohibited (and was practiced) to use this data (e.g. A RR for
www.yahoo.com) in answers with never decreasing TTL.

> repeat this process. And because I have REFRESH of 1 week, this data is

You're free to shoot yourself. That high a refresh timer and no NOTIFY is
beyond current practice.

> the glue points to a domain name that is within the scope of the domain

What's the scope of the domain? Do you mean the subtree rooted at a zone apex,
i.e. that zone and all its subzones, if any? Then I'd second your statement.

> worth the costs anyway if it stops bad data from floating around.

Still you can't just forbid this at the master side without suggesting
precautions at the slave side. Zone master servers are often operated by
end customers, running old and sometimes strange software. You can't trust
them doing it right.

-Peter

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 20 Jul 2000 11:41:18 -0700 (PDT)

> the slave desires the compressed form".

Something like this could (and probably should) have been done years
ago when multi-answer messages were first introduced, but I don't
think there's much point in doing it now.

Also, the purpose of this draft is not to change the protocol but to
document it in its existing form.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Jul 2000 10:56:25 -0700 (PDT)

> viewpoint this is suboptimal and that's why I mentioned the ``real'' glue

I would still like to know what your definition of "real" glue is.

After thinking a bit more about the issue, I would say that what
distinguishes glue appropriate for inclusion in zone transfers from
other glue is not the owner name of the glue RRs but whether the glue
is considered "glue of the zone" by the master.

Here's an updated section 4 reflecting this definition:

  Zone transfers MUST include any glue RR configured specifically
  for the zone being transfered, such as any non-authoritative zone data
  loaded from the zone's master file or received as part of an incoming
  zone transfer of the zone in case, except such glue RRs that the
  master has deemed inappropriate and discarded on loading.

  Zone transfers SHOULD NOT contain RRs from the authoritative data
  of zones other than the one being transferred, and MUST NOT contain 
  RRs from the cache, even when such RRs are pointed to by NS records
  in the zone being transferred.

  The glue RRs are transmitted in the answer section along with the
  authoritative data.  This is unlike ordinary DNS responses where 
  glue is transmitted in the additional section.

  A slave MUST recognize any data outside the zone being transferred
  as glue; it MUST NOT be treated as authoritative data nor entered
  into the cache.  Note that classifying an RR as glue or non-glue may
  not be possible until the entire zone has been received so that the
  zone cuts defined by the zone's NS records can be determined.

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jul 2000 11:46:07 -0700

one way i think of glue is, presuming there is no $origin above it, could
an ns rr's label be written without a terminating dot?  if so, then a glue
a rr is needed for it.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jul 2000 11:46:07 -0700

s/label/rhs/  sorry.

randy

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 25 Jul 2000 20:26:17 -0400

I think attention to section 7.18 of RFC2136 may induce caution with the
discussion of necessary and/or real glue.

While its important that a slave recognize the boundaries of the zone, and
that the master not send a bunch of random stuff, its also essential that
the master sends, and that the slave retains, all records considered part of
the zone, whether necessary glue or not.

Based on the "occluding zone cut" case in this section of 7.18, its
important that a full zone transfer, followed by an incremental which
removes the zone cut, leaves the slave with the correct state of the zone,
which will include the newly exposed records.

I think Andreas new text is consistent with this, but it could be read as
the server choosing to include a subset of the configured zone data in the
transfer.  The server should take care in what is allowed to be configured
in the zone, but once configured it should all be transferred.  The slave
should be careful to recognize the portions which are currently exposed
either directly or as needed glue.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Jul 2000 22:37:04 -0700 (PDT)

> the zone, whether necessary glue or not.

Well said.

> which will include the newly exposed records.

I agree that this is the correct behavior, but since this is an issue
specific to IXFR, it would be more appropriate to bring it up in the
IXFR specification than in the AXFR one.

> [...] but it could be read as
> the server choosing to include a subset of the configured zone data 
> in the transfer.

That was not the intent.

> The server should take care in what is allowed to be configured
> in the zone, but once configured it should all be transferred.

Yes.  In particular, in slave servers, such "configuring data in the
zone" is done by means of incoming zone transfers, and "taking care in
what is allowed to be configured" may involve discarding some of the
RRs in the incoming transfer, but all zone data retained by the server
MUST be transmitted in outgoing transfers.
-- 
Andreas Gustafsson, [email-masked]

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 26 Jul 2000 11:27:07 -0400

> IXFR specification than in the AXFR one.

I generall agree, but IXFR and AXFR are not independent.  A slave with no
data must always start with an AXFR, since there is no way to request a full
IXFR (perhaps there should be, but the feeling has been that AXFR serves
that purpose).  So, AXFR must support communicating data which remains
meaningful after a subsequent IXFR.

> MUST be transmitted in outgoing transfers.

Well, its this discarding of data by slaves which I think is problematic,
and where this clarification is essential.  I do not think a slave should
discard records considered non-essential, such as random, non-glue records
beneath a zone cut.  It should not expose them, but it should not discard
them if it expects to recieve an IXFR in the future.  A slave can freely
discard records of the wrong class, or not beneath the zone in any way,
since these can never be exposed by changes to the zone in the future.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 26 Jul 2000 13:07:09 -0400

Andreas Gustafsson wrote:
> Regarding records of the wrong class, I think those should be
> considered protocol errors and cause the transfer as a whole to be
> rejected with FORMERR.

I believe I tried that in my implementation about 5 years ago.  Didn't get
very far when talking to some old BIND servers.  Perhaps its a safer thing
to do now, but I found it more practical to ignore the records of the wrong
class.

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 26 Jul 2000 11:12:39 -0700

> to do now, but I found it more practical to ignore the records of the wrong

BIND8 has had in it, for some time, the following logic:

			/* Parse class (IN, etc) */
			someclass = sym_ston(__p_class_syms, buf, &success);
			if (success && someclass != zp->z_class) {
				ns_info(ns_log_load,
					"%s: Line %d: wrong class: %s.",
					filename, lineno,
					p_class(someclass));
				errs++;
				break;
			}

I think if there are old servers passing bad class info around in zone
transfers, then they are failing to transfer them to BIND8 slaves, and
already feeling whatever pain that can bring.

Ignoring a subset of the zone's data and then treating what's left as
authoritative is an error.  Zones have identity.  You're either serving
the zone, the same zone the primary master is serving, or you're not.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 26 Jul 2000 19:11:51 -0400

> the zone, the same zone the primary master is serving, or you're not.

I agree, and that was my earlier point.  On the question of invalid class, I
think its a question of ignoring data which isn't part of the zone, because
the zone is class-specific.  But I'm glad BIND 8 tightened this up.  I ran
into the problem in the days of BIND 4.9.3, when UNIX vendors were shipping
variants of 4.8