Subject: DNSEXT WGLC AXFR-02 SHORT last call

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 22 Jun 2001 10:27:29 -0400 (EDT)

This document formalizes the definition of Zone transfer protocol that was
unspecified in RFC1035. This document formalizes the zone transfer protocol
in accordance with the fielded DNS server software.

This version is based on the feedback from the last round of WGLC and
subsequent comments. The major changes reported by Andreas are:

  Note that some masters simply close the TCP connection
  to indicate that they refuse zone transfers, and recommend
  that this MAY be treated like a REFUSED response, based on
  suggestions by Sam Trenholme and Robert Elz.
 
  Allow responses with RD set unconditionally to 0, as suggested
  by Dan Bernstein.  In a similar vein, allow RA to be unconditionally
  set to 0.
 
  Rewrote section 4 "Glue", changing its title to "Zone data"
  and incorporating text from Peter Koch.
 
  Added the requirement that RRs other than the SOA be transmitted
  exactly once (Peter Koch suggested a SHOULD, but I think a
  MUST is warranted) and the recommendation that duplicate RRs be
  silently ignored when received.
 
  Added an Acknowledgments section.
 
  Miscellaneous minor editorial changes.

As the working group has discussed this document in great detail this 
is a short WG last call that ends June 30'th 2001.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-02.txt

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

---

From: Josh Littlefield <[email-masked]>
Date: Fri, 22 Jun 2001 15:26:59 -0400

> subsequent comments. The major changes reported by Andreas are:
[...]
>   silently ignored when received.

I would prefer this be a SHOULD rather than a MUST, as Peter Koch
suggested.  That is, I don't feel its significant to *require* that the
server transmit each RR exactly once, though I think it should be
recommended.  Perhaps this also means that the slave MUST ignore duplicate
RRs, by permitting their transmission.

Additional comments:

In section 3.2, saying that the slave SHOULD ignore the ID in subsequent
messages seems incongruous with saying that the master MUST copy the ID from
the request into each response packet.  I would think the slave MAY ignore
the ID in subsequent messages unless the slave has sent multiple requests to
the master, in which case the slave MUST NOT ignore the ID in subsequent
messages, since they are needed to differentiate the response packets.

At the end of section 3.6, I think we should explicitly say that the slave
MUST NOT treat additional section RRs as zone data.  I think this would help
clarify what an "unexpected" RR is, or is not.

In section 5, while I appreciate the clarification of the first/last record
being an SOA, I think it would be helpful to explicitly state that the
transfer is completed by the packet containing the final SOA record.  And
while we've defined the server behavior as sending the SOA as the last
record of the transfer, we haven't specified the client's behavior regarding
any answer records which follow this final SOA.  I think we are implicitly
saying that a client MAY ignore any answer records which follow the final
SOA.  I'd prefer we say this explicitly.

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

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 22 Jun 2001 20:12:42 -0400

The draft is still ambiguous as to how a nameserver should respond -- assuming
that it *does* respond, as opposed to just closing the connection -- when it's
not authoritative for the requested zone. In the last Last Call, I proposed
that RCODE=NOTAUTH and/or AA=0 be explicitly mandated in that situation, but
that proposal apparently got buried alive under the whole "is it or is it not
OK to just close the connection?" discussion/argument.

An unambiguous indication of non-authoritativeness would I think facilitate
troubleshooting of AXFR problems/failures.

- Kevin

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 25 Jun 2001 12:57:49 -0700 (PDT)

Josh Littlefield writes:
> recommended.

I did seriously consider making it a SHOULD, but I couldn't think of
any legitimate reason for a server to ever send a RR multiple times.
Old BIND servers do send RRs multiple times as a result of the way
they handle glue, but that behavior already conflicts with section 4.
I don't see how a server could conform to section 4 but still have a
reason to transmit a RR multiple times.  Allowing the multiplicity
would just complicate the protocol without bringing any advantages.

> Perhaps this also means that the slave MUST ignore duplicate

Yes, if we were to just say that the master SHOULD transmit each RR
only once, then we would have to make ignoring duplicates a MUST.

> the request into each response packet.

I don't think this is incongruous - it just mandates being
conservative in what you send and recommends being liberal in what you
accept.

> I would think the slave MAY ignore the ID in subsequent messages

I still think a SHOULD is warranted given the large number of deployed
masters that fail to copy the ID.

> unless the slave has sent multiple requests to

I think this is fairly obvious implementation constraint rather than a
protocol issue.  As such, I don't think it needs to be stated
explicitly in the protocol specification, but if it were, I would
prefer to express it a bit differently:

   "A slave that ignores ID fields cannot have multiple simultaneous
   outstanding requests on the same TCP connection, since the ID would
   be needed to differentiate the response messages."

> clarify what an "unexpected" RR is, or is not.

OK, I'll add the sentence "It MUST NOT treat additional section RRs as
zone data." at the end of 3.6.

> transfer is completed by the packet containing the final SOA record.

OK, I'll add the text "The slave MUST consider the transfer to be
complete when, and only when, it has received the message containing
the second SOA record." at the end of the third paragraph of section 5.

> And

Are you concerned with the case where other messages follow the
one with the final SOA, or the case where other RRs follow the SOA
in the answer section of the final message?

The first case is outside the scope of the draft since the transfer
has already ended (per the definition above).

The second case is of course an error on the part of the master, but I
don't see why saying the slave "MAY ignore" the extra data would be
preferable to simply leaving the slave behavior undefined.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 25 Jun 2001 14:06:01 -0700 (PDT)

> troubleshooting of AXFR problems/failures.

I agree that an unambiguous indication of non-authoritativeness would
be a good thing, but I think mandating RCODE=NOTAUTH and/or AA=0 (as
in making them REQUIRED) would be contrary to the draft's stated
purpose of clarifying rather than changing the protocol defined in
RFC103[45].  In particular, the NOTAUTH result code had not yet been
defined RFC1034/1035 were written, making it hard to argue that
mandating its use is a mere clarification of the original intent of
the protocol designers.  I don't want to declare an otherwise fully
conforming implementation non-conforming just because its implementers
did not foresee the future introduction of RCODE 9.

I don't have a problem with a SHOULD, as in:

  "If the master is not authoritative for the requested zone, the RCODE
  SHOULD be 9 (NOTAUTH)."

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 25 Jun 2001 18:07:09 -0400

>   "If the master is not authoritative for the requested zone, the RCODE

I see your point about NOTAUTH, being that this is a clarification rather than an
update of RFCs 1034/1035.

But what about the other alternative, i.e. mandatory AA=0? RCODE=NOTAUTH was a nice
thought, but upon further consideration, I guess my core concern is that this
draft's "1, but MAY be 0 when RCODE is not NOERROR" language appears to loosen the
RFC 1034/1035 requirements with respect to the setting of AA, i.e. it can be read
as "if RCODE is not NOERROR, you're free to set AA any way you want". That's the
dangerous thing about a "MAY" keyword -- it can give the appearance of allowing
something that was previously forbidden, even if that is not the case. Perhaps
something more along the lines of:

     1 if authoritative for QNAME, 0 otherwise. Note that on responses with
     RCODE set to NOERROR, it logically follows that AA MUST be set to 1.

would emphasize that the original RFC 1034/1035 rules vis-a-vis AA still need to be
observed.

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Tue, 26 Jun 2001 13:56:50 +0700

Date:        Mon, 25 Jun 2001 12:57:49 -0700 (PDT)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | > unless the slave has sent multiple requests to
  | > the master, in which case the slave MUST NOT ignore the ID in subsequent
  | > messages, since they are needed to differentiate the response packets.
  | 
  | I think this is fairly obvious implementation constraint rather than a
  | protocol issue.  As such, I don't think it needs to be stated
  | explicitly in the protocol specification, but if it were, I would
  | prefer to express it a bit differently:
  | 
  |    "A slave that ignores ID fields cannot have multiple simultaneous
  |    outstanding requests on the same TCP connection, since the ID would
  |    be needed to differentiate the response messages."

This is not actually required.   A client shouldn't ever really need
to know (if it doesn't want to) which queries generated which responses.
Of course, it might like to know that, to optimise its handling of the
replies - but there's nothing in the DNS that mandates it.

That is, the purpose of a query in the DNS is to cause a server to send
you some information.   You do that only if you don't have the information
already.  What causes the information to be sent to you is really pretty
much irrelevant - as long as you have it, you can answer (or continue with)
any query that depends upon that information.

Eg: consider that I am attempting to discover the A records for two different
names - www.example.com and smtp-server.example.com.   Currently all I know
are the NS records for COM.   The traditional way to handle this is to send
a A query for www.example.com to the COM nameservers, and get back a
referral for the example.com nameservers.   The same thing is done for
smtp-server.example.com.  But when I get back the NS list for example.com
that satisfies both current requirements - and I can proceed with the A
queries for the two names at the example.com nameservers, whichever query
it was that was actually answered.

The point of this is that regardless of whether or not clients should
ever ignore the ID in a response because of old broken servers, there's
never an operational requirement for them to verify the ID just because
they happen to be sending multiple simultaneous queries out over the same
connection.   Maybe that's what a client would do - but the final quoted
paragraph above is certainly wrong, the ID isn't needed, the client doesn't
(necessarily) need to know.

kre

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 26 Jun 2001 11:15:03 -0700 (PDT)

> it was that was actually answered.

What you describe may work for ordinary queries sent for resolution
purposes, though for security reasons I certainly wouldn't recommend
doing it.

It most certainly will not work for AXFR, which is the case being
discussed.  For example, if you are simultaneously transferring the
zones example.com. and sub.example.com. over the same TCP connection,
and receive a message containing some NS records for sub.example.com,
there is no way of knowing which of the zones they are associated with
without examining the ID.

My main point, however, is that no existing slave implementations
attempt to do multiple simultaneous AXFRs over the same TCP
connection, and that there is no real reason why an implementation
would ever want to do that in preference to doing the transfers
serially or over separate TCP connections, and I would like to avoid
discussing this case in the draft in a way that could mislead slave
implementers into thinking that multiplexing of multiple simultaneous
AXFRs over the same TCP connection is a desireable feature.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 26 Jun 2001 10:47:39 -0700 (PDT)

Kevin Darcy writes:
> But what about the other alternative, i.e. mandatory AA=0? RCODE=NOTAUTH
> was a nice thought, but upon further consideration, I guess my core
> concern is that this draft's "1, but MAY be 0 when RCODE is not NOERROR"
> language appears to loosen the RFC 1034/1035 requirements with respect to
> the setting of AA, i.e. it can be read as "if RCODE is not NOERROR, you're
> free to set AA any way you want". That's the dangerous thing about a "MAY"
> keyword -- it can give the appearance of allowing something that was
> previously forbidden, even if that is not the case. Perhaps something more
> along the lines of:
> would emphasize that the original RFC 1034/1035 rules vis-a-vis AA still
> need to be observed.

One problem with this is that there are error cases where the server
cannot determine a meaningful value for AA (e.g., FORMERR), or may not
want to disclose whether or not it is authoritative (REFUSED).  Rather
than try to enumerate all possible error cases, I decided to leave the
setting of AA in error responses to the discretion of the implementer.

The language in the draft regarding header flags may be looser than
RFC1035, but it is still considerably stricter than historical AXFR
implementation practice.

I don't think any of this really matters much, because in practice
slaves will discover that the master is non-authoritative when they do
an SOA query and get a referral response, and will not even attempt the
AXFR.
-- 
Andreas Gustafsson, [email-masked]

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 27 Jun 2001 11:46:34 -0400

Andreas Gustafsson wrote:
> > suggested.  That is, I don't feel its significant to *require* that
> > the server transmit each RR exactly once, though I think it should
> > be recommended.
> 

Well, I can imagine a server implementation which occassionally transmits a
duplicate.  I cannot imagine implementing a client which blindly assumed
that duplicates would not be transmitted, or which refused a transfer
containing them.  If you assume they won't be transmitted, then you risk
screwing up your own data.  Once you add checking for duplicates, its easier
to ignore them and serve the zone than to refuse the entire transfer (being
liberal in what you accept).

I'm not adamant on this point, but I hadn't seen discussion on this server
restriction.

> > And
> > while we've defined the server behavior as sending the SOA as the
> > last record of the transfer, we haven't specified the client's
> > behavior regarding any answer records which follow this final SOA.  I
> > think we are implicitly saying that a client MAY ignore any answer
> > records which follow the final SOA.  I'd prefer we say this explicitly.
> 

I'm concerned with the second case.  Perhaps it can be undefined.  Looking
at what we (Cisco) implemented a few years ago, with the poor AXFR
specification in 1035, I see that we use the presence of the second SOA in a
packet to mark it as the last packet, but we read ALL answer RRs in that
packet, regardless of whether they follow the SOA.  I suppose as long as
we're specific about the SOA being the last answer record in the final
packet sent, it doesn't matter what the client is prepared to do with a
non-conforming packet.

-josh

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Jun 2001 11:11:55 -0700

> I'm not adamant on this point, but I hadn't seen discussion on this server

The entity being transferred is a DNS Zone, which has a specific identity.
A DNS Zone cannot include duplicate RR's in some cases (WKS, SOA) yet it can
in others (TXT).  If there is any confusion or disagreement about whether a
given RR can be duplicated, then this has to be resolved at the zone identity
level, that is, it applies to loads of master zones, not just transfers and
loads of transferred zones.

Once a zone has an identity, that identity has to be transferred.  It cannot
be left up to a transferrer to decide which parts of a transferred zone are
unnecessary duplicates.  In order that identity be transferred, nothing can
be left out, nothing can be added.

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Jun 2001 02:08:20 +0700

Date:        Wed, 27 Jun 2001 11:11:55 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | The entity being transferred is a DNS Zone, which has a specific identity.

yes, for data that is in the zone, that's true.

But zone transfers also have to transfer glue, and glue, not actually being
a part of the zone, doesn't have all the same rules, or problems
(it has a whole different set).

If you take the (incorrect) view that glue is only ever included in a zone
transfer when it is an A record for an NS that delegates into its own domain
(forget the terminology, you know what I mean) then you'll never get duplicate
glue, as the A record will only ever appear near the domain it lives inside,
hence only ever once.

However, as soon as you admit that glue is sometimes required more often
than that (it certainly is), then you can have the same glue A records
associated with more than one domain's delegation, and a naïve implementation
might just send them multiple times.

The question here is whether that is acceptable or not - it certainly isn't
necessary, and by doing the extra bookkeeping it is avoidable.   However,
it tends to be much easier to do that at the receiver - you just need to check
if you already have the data, if so, then you don't need it again.  Checking
if you have it is easier than checking if you sent it - for that you need
to retain history.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Jun 2001 12:34:15 -0700

> might just send them multiple times.

BIND4 does that.

> The question here is whether that is acceptable or not - it certainly
> isn't necessary, and by doing the extra bookkeeping it is avoidable.
> However, it tends to be much easier to do that at the receiver - you just
> need to check if you already have the data, if so, then you don't need it
> again.  Checking if you have it is easier than checking if you sent it -
> for that you need to retain history.

I sure wish that glue were sent in additional data sections.  Right now you
have to fully receive a transfer before you know where the zone's bottom is,
and thus before you know which RR's are part of the zone and which are not.

But if it's out-of-zone data then I expect that liberal receiving rules ought
to apply.  Interestingly, this opens the possibility of multiple A RR's of
different addresses for the same name being aggregated into a single RRset
by a receiver even though they might have been held/used separately by the
sender (when the sender is answering queries).  Glue is just sticky.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Jun 2001 14:00:43 -0700 (PDT)

> a part of the zone, doesn't have all the same rules, or problems

The whole point of section 4 in the draft is to explain that for the
purpose of zone transfers, glue *does* have all the same rules and
problems as the authoritative zone data.  To summarize, the data
transferred is exactly the data that the master loaded from the master
file of the zone being transferred.  Nothing more and nothing less,
and "nothing more" should be taken to include additional copies of
data that is already there (except the SOA end marker, of course).

> might just send them multiple times.

Section 4 specifically points out that such A records are *not* sent
because they are associated with a delegation, they are sent because
(and only if) they occurred in the master file.  Naive implementations
that send random glue that is not in the master file are deliberately
outlawed by the draft.

The reason for this strict specification is to ensure that AXFR can
coexist with IXFR.  The IXFR protocol assumes that the zone data are
consistent among all the authoritative servers. Inserting random glue
breaks this assumption and will cause IXFRs to fail.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 27 Jun 2001 19:43:06 -0400

Paul A Vixie wrote:

> in others (TXT).

Is that really the case? RFC 2181 would appear to forbid even duplicate
TXT records: "It is meaningless for two records to ever have label, class, type
and data all equal - servers should suppress such duplicates if encountered"
(Section 5, "Resource Record Sets"). Why would TXT records be an exception?

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Jun 2001 12:43:53 +0700

Date:        Wed, 27 Jun 2001 14:00:43 -0700 (PDT)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | To summarize, the data
  | transferred is exactly the data that the master loaded from the maste=
r
  | file of the zone being transferred.  Nothing more and nothing less,
  | and "nothing more" should be taken to include additional copies of
  | data that is already there (except the SOA end marker, of course).

Ok, then in that case section 5 is inconsistent, as it says ...

   The transmission order of all other RRs in the zone is undefined.
   Each of them MUST be transmitted exactly once.  As some older masters
   do not comply with this requirement, slaves SHOULD silently ignore
   duplicate RRs for interoperability.

None of that can be correct given the above interpretation.

That is, if I write in a master file

	foo 		IN	NS	ns13.example.com.
	ns13.example.com. IN	A	10.11.12.13

	bar		IN	NS	ns13.example.com.

	foobar		IN	NS	ns13.example.com.
	ns13.example.com. IN	A	10.11.12.13

then to transfer that zone to the secondary, the primary would have to
retain the RR order (so the order of all other RR's (other than the SOA
which is discussed just above) can not be undefined).

Also, the primary would have to transfer the RR for ns13.example.com.
twice, not once, so the "MUST be transmitted exactly once" is not correct=

either.   And lastly, to receive the same zone information, secondary
servers "MUST NOT" ignore duplicates, but would have to retain them.

Of course, none of this is really required for IXFR compatability, nor
should anything really be caring anything at all about the format of mast=
er
files (other than for the cases when they need to be transported around
by means other than [AI]XFR and then loaded into different servers).

  | Section 4 specifically points out that such A records are *not* sent
  | because they are associated with a delegation, they are sent because
  | (and only if) they occurred in the master file.

Yes, of course.  That's fine.   It still doesn't handle all the possibili=
ties.

  | Naive implementations
  | that send random glue that is not in the master file are deliberately=

  | outlawed by the draft.

Yes, I know, and that's fine.   But in the example above are you really
trying to tell me that it is important that there is a glue A record
associated with exactly 2 of the delegations, but not with the third?

In that situation, my na=EFve implementation might send 6RRs (3 NS record=
s, and
3  records), or it might send 4 (3 NS records, and one A record), or it
could even send 5 (3 NS records and 2 A records).   Does it matter?
I kind of doubt it.

Further, if you're really intending to be able to duplicate the master fi=
le,
rather than just the zone data that was built from the master file, then
I'm not sure how some of my master files would work - some of my zone fil=
es
are built like

	A	IN	NS	ns1
	B	IN	NS	ns2
	C	IN	NS	ns1
	D	IN	NS	ns1
	E	IN	NS	ns2
	; glue follows
	ns1	IN	A	10.11.12.13
	ns2	IN	A	10.22.33.44

where the glue A records aren't "attached" to any particular delegation
at all, but simply exist in the zone.

Internally however, it makes sense for the zone data structures to have
links directly from delegation (NS) to glue A record if glue exists,
so when a query for the NS arrives, the glue can easily be attached.
Then when transferring that zone, the easy way is to send NS, if glue poi=
nter
is set, send A record.  Doing that with this recent example and you'd
send the A record for ns1 3 times, and the A record for ns2 twice.
To avoid that, extra bookkeeping is required in the primary.  On the othe=
r
hand, it is almost trivial to ignore the duplicate at the secondary.

  | The reason for this strict specification is to ensure that AXFR can
  | coexist with IXFR.  The IXFR protocol assumes that the zone data are
  | consistent among all the authoritative servers. Inserting random glue=

  | breaks this assumption and will cause IXFRs to fail.

Absolutely, none of this has been about adding glue that isn't in the zon=
e
file, only about how many times the RRs that are in the zone file are
allowed to be sent.

Or, take another example, unrelated to glue at all...

	domain	IN	SOA	x y 0 0 0 0 0	; soa contents uninportant
		IN	NS	ns1
		IN	NS	ns2
	host	IN	A	10.11.12.13
		IN	A	10.11.12.13

There, in the master file is a duplicate A record.   That is supposed to
be compressed into a single RR when the zone is loaded (ie: there's only
one RR there).

Now an implementation that loads the zone, and later transfers it, will
transfer only the one RR that it has loaded (duplicate supressed).
On the other hand, an implementation that implements AXFR by "there is
the master file, encode and send it" is quite possibly going to send the
RR twice (most likely the two instances won't be adjacent as they appear
above, there will be lots of other RRs between).

Is the simple "load, encode, transmit" of the master file implementation
to be outlawed, so that AXFR requires the whole zone to be loaded so
duplicates can be supressed, before anything can be sent?   On large zone=

files on my main server, loading and parsing the zone file data can take
10 minutes or so - that would be a 10 minute penalty between the
arrival of the AXFR request and when the first RR could be sent.  I see
no reason for that at all.   I think the right thing to do is simply
to delete the "MUST be transmitted exactly once" and make it a "MUST"
ignore duplicates for the secondary.

kre

ps: everything Paul said in his most recent message
(Message-Id: <[email-masked]>) I agree with...

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 28 Jun 2001 11:15:39 -0700 (PDT)

> (Section 5, "Resource Record Sets"). Why would TXT records be an exception?

I agree with Kevin.

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 28 Jun 2001 13:56:03 -0700 (PDT)

Robert Elz writes:
>   | To summarize, the data
>   | transferred is exactly the data that the master loaded from the master

The order of the records in a master file is meaningless.  The above
does not express three delegations of which only two have glue - it
simply expresses three NS records and two copies of an A record,
one of which will be suppressed by the master per RFC2181 section 5.

When the draft refers to RRs "loaded from the master file", that means
exactly those four records (3 NS + 1 A), in no particular order.

> twice, not once, so the "MUST be transmitted exactly once" is not correct

No.  Only one A record is loaded, therefore only one A record is
transferred. 

> should anything really be caring anything at all about the format of master

The AXFR protocol does not care about the format of master files.
It only cares about an unordered collection of unique RRs which is
customarily defined using a master file.

>   | Naive implementations
>   | that send random glue that is not in the master file are deliberately
>   | outlawed by the draft.
> 

No - quite the contrary.  I'm saying "there is one A record".
Whether it is glue is irrelevant to the zone transfer protocol.

> In that situation, my naive implementation might send 6RRs
> (3 NS records, and 3  records), or it might send 4 (3 NS records,
> and one A record), or it could even send 5 (3 NS records and 2 A records).
> Does it matter? I kind of doubt it.

The draft currently says the master MUST send 4, and that the slave
SHOULD also accept 5 or 6 (which it should then internally reduce to 4
per RFC2181 section 5).

> Further, if you're really intending to be able to duplicate the master file,
> rather than just the zone data that was built from the master file,

I *am* intending to duplicate the zone data that was built from the
master file.

> Then when transferring that zone, the easy way is to send NS, if glue
> pointer is set, send A record.  Doing that with this recent example and you'd
> To avoid that, extra bookkeeping is required in the primary.  On the other

Yes, this would work, although it would of course waste a bit of
bandwidth.

> duplicates can be supressed, before anything can be sent?   On large zone

This makes sense.  I don't have any major problems with allowing
duplicates in order to support implementations like this one and the
"glue pointer" based implementation above (and I third one I was told
about in private email), though I still think they should be
discouraged.  That is, I can change the text to say that the master
SHOULD NOT send duplicates, and the slave MUST ignore duplicates.
-- 
Andreas Gustafsson, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 29 Jun 2001 12:12:35 +0700

Date:        Thu, 28 Jun 2001 13:56:03 -0700 (PDT)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | That is, I can change the text to say that the master
  | SHOULD NOT send duplicates, and the slave MUST ignore duplicates.

Fine.   As was pointed out by Josh Littlefield, secondaries have
to ignore duplicates to end up with a valid zone anyway, they
simply have no choice, so whether it says MUST ignore or not, that
is what the secondaries are going to do.

kre

ps: one more time on an almost irrelevant aside ... there is no such
thing as a slave server - there are primary servers, secondary servers,
and master zone files.   Grep for "slave" in 1034/1035 (etc) and you
won't find it at all - it would really be nice if the term didn't start
appearing in the DNS lexicon, it isn't needed, and just creates confusion.
Perhaps worse, using "primary master" is just redundant, while 103[45]
do occasionally use the term "master server" where "primary server" would
have been better (except a couple of cases where it really means server of
the master zone file), but "master server" or better "primary server" is
all that is ever needed.

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 28 Jun 2001 23:07:51 -0700

> the master zone file), but "master server" or better "primary server" is

i disagree.  103[45] was ambiguous to a fault on this matter.  master and
slave are roles taken during an AXFR (and now during IXFR as well).  while
the term "transfer initiator" and "transfer responder" would perhaps be as
accurate, they don't roll off the keyboard as well as "slave" and "master".

an authoritative zone server can be a master, or a slave, or neither (if
there are no AXFR's or IXFR's involved, and the zone maintainance is being
done out of band), or both (if the transfer graph is deep).

see RFC 1996 2.1.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 29 Jun 2001 09:41:55 -0500

> and master zone files.

> do occasionally use the term "master server" where "primary server"
> would have been better (except a couple of cases where it really means
> server of the master zone file), but "master server" or better "primary
> server" is all that is ever needed.

master/slave is unfortunate but it is better than primary/secondary. The
latter implies that the secondary servers will pick up where the primary
fails, which is not the case at all. There are also multiple occurrances
of each phrase pair in various documents, making it worse. DNS is unique
in many regards, and the frequent colliding metaphors is one of the less
fortunate unique elements.

Personally I prefer "replication master" and "replication slave" but could
easily live with "zone master" and "zone backup server" or any other
terminology which clearly described the functional roles of the
authoritative servers for a zone.

Maybe a draft on terminology is in order.

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 30 Jun 2001 10:07:14 -0700

> Yes, I know - you've had this master/slave fixation for some time (which is
> why bind got changed from calling itself a primary or secondary for a zone
> into a master or a slave as well).   That doesn't make it correct.

Robert, you were involved in the RFC 1996 discussions, both in the meetings
and here on the mailing list.  You ought to remember that what was determined
(proposed by me and consensed by others) is that there is no such thing as a
"primary" vs "secondary" server.  Servers are authoritative for zero or more
zones.  Servers either behave recursively or they won't.  A server which is
authoritative for some zone either uses AXFR (and now maybe IXFR) or it
doesn't.  If it doesn't use AXFR/IXFR then it still has to obey the SOA rules.

The shorthand of "primary" used to mean "loads the zone content from outside
the DNS" but that's a meaningless distinction if DNS isn't used to copy zones
between the various authoritative servers for the zone.  All of them would be
primary in that case.  (I think Microsoft says they do this, though I'm unsure
whether they've got it right.)

That and only that is why late model BIND calls zones "master" and "slave".
"Master" means load from disk.  "Slave" means load via AXFR/IXFR (and disk).
I now wish I'd just called them "authority" zones and let the presence or
absence of a "masters { };" clause determine the masterness/slaveness type.

"Master" and "slave" survived the terminology evaluation because they refer
to a useful distinction -- "which role do you take in AXFR/IXFR?"  Whereas
"Primary" and "secondary" did not survive because they refer to no useful
distinction.

(You are, by the way, the last person in the IETF whom I would have expected
an argument ad hominem from.  Please realize that for 20 years or more you
have set an example of high grade personal behaviour that the rest of us have
treated as the "gold standard."  Please do not abandon that course now.)

---

From: Robert Elz <[email-masked]>
Date: Sat, 30 Jun 2001 08:08:06 -0700

Date:        Thu, 28 Jun 2001 23:07:51 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i disagree.

I thought that you might.

  | 103[45] was ambiguous to a fault on this matter.

It is true that it confuses primary server with master server a few
times, but in general, it is fairly clear, and it certainly is clear
that "slave" occurs never.   1034/5 doesn't provide a lot of good
information on AXFR it is true (which is why this new doc should help)
but it is mostly clear in its use of terminology.

  | master and slave are roles taken during an AXFR

If we need names for that, which is probably not a bad idea, client and
server is the more traditional terminology - further it avoids adding to
the already slightly confused use of "master" in 103[45].

  | the term "transfer initiator" and "transfer responder" would perhaps be as
  | accurate, they don't roll off the keyboard as well as "slave" and "master".

Which is why we mostly (in other protocols) just use "client" and
"server" for those roles...

  | an authoritative zone server can be a master, or a slave, or neither (if
  | there are no AXFR's or IXFR's involved, and the zone maintainance is being
  | done out of band), or both (if the transfer graph is deep).

It can be all of those things whatever the labels applied are.

  | see RFC 1996 2.1.

kre

---

From: Peter Koch <[email-masked]>
Date: Sat, 30 Jun 2001 08:11:05 -0700

> SHOULD NOT send duplicates, and the slave MUST ignore duplicates.

One reason for suggesting to discourage duplicates was AXFR efficiency. With
very large (TLD) zones currently a non-negligible part of the transfer
is redundant ``glue''. While the result after an AXFR will be the same iff
the slave is to ignore the duplicates, transmitting them will cost resources.
So will suppressing them, and one may argue that with SIG RRs everything
will increase in volume anyway, but I do not see why that should prevent us
from saving as much as can be achieved reasonably. I agree with Andreas'
proposed text above.

-Peter

---

From: "D. J. Bernstein" <[email-masked]>
Date: Sat, 30 Jun 2001 19:17:55 -0700

Where did the WG chairs get this ``SHORT last call'' idea from?

This draft was announced on 22 June. The WG chairs, without giving us
any extra time to review the draft, announced a ``SHORT last call''
ending on 30 June.

I've just returned from vacation. I haven't seen the draft yet. I object
to this absurd last-call schedule.

I have glanced at the summary of changes provided in the last call. It
seems that several of my objections have been ignored. I object to the
new draft for all the same reasons.

I also question the judgment of the WG chairs in putting a biased vendor
draft, admitted by the author to be out of line with existing practice,
up for last call.

---Dan