Subject: DNSEXT WGLC: AXFR Clarify

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 13 Mar 2001 11:35:43 -0500

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 WG last call ends March 29'th 2001.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt

This draft is on standards track, if you disagree with that please state why
in your response.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Mar 2001 07:10:47 -0000

> Any other RRs at the zone's apex are transmitted only once

Not necessarily. BIND often transmits the same record many times in a
zone transfer.

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

I object to this requirement, because (1) it is not necessary for
interoperability and (2) it prohibits the behavior of my AXFR server,
axfrdns, which simply closes the connection.

AXFR is a local matter between a master and its authorized slaves.
Clients without authorization have no business asking for AXFR.

> RD      Copy from request

I object to this requirement, because (1) it is not necessary for
interoperability and (2) it prohibits the behavior of axfrdns, which
always sets RD to 0.

I propose that we explicitly prohibit RD in AXFR requests. RD makes no
sense for AXFR.

> The slave MUST check the RCODE and abort the transfer if it is nonzero

I object to this requirement, because (1) it is not necessary for
interoperability and (2) it prohibits the behavior of my AXFR client,
axfr-get, which doesn't bother checking the RCODE.

> It SHOULD check the ID of the first message received and
> abort the transfer if it does not match the ID of the request

I object to this recommendation, because (1) it is not necessary for
interoperability and (2) it discourages the behavior of axfr-get, which
doesn't bother checking the IDs.

> The initial message of a zone transfer response SHOULD have a question
> section identical to that in the request

I object to this recommendation, because (1) it is not necessary for
interoperability and (2) it discourages the behavior of axfrdns, which
doesn't bother repeating the question.

> Slaves MUST ignore any authority section contents they may receive
  [ ... ]
> The slave MUST ignore any unexpected RRs in the additional section

I object to these two requirements, because (1) they are not necessary
for interoperability and (2) they prohibit the behavior of axfr-get,
which takes records from all sections.

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

Huh? Every record in the Domain Name System is part of the authoritative
data of some zone. See RFC 1034, section 4.2.

> The use of TSIG [RFC2845] for this purpose is RECOMMENDED

I object to this recommendation. People protecting their communications
with IPSEC, for example, shouldn't be encouraged to use TSIG.

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Wed, 14 Mar 2001 12:09:08 -0800 (PST)

> Not necessarily. BIND often transmits the same record many times in a

Not any modern version of BIND.  And any version that does is
noncompliant.

> I propose that we explicitly prohibit RD in AXFR requests. RD makes no

Yes, RD makes no sense on an AXFR query.  But RFC 1035 (section 4.1.1)
says:

RD              Recursion Desired - this bit may be set in a query and
                is copied into the response.

The server is obviously not going to do a recursive AXFR, but the client
really did request it, and the RD bit in the response should indicate what
the client requested.

> axfr-get, which doesn't bother checking the RCODE.

Then axfr-get is broken.  There's no excuse for not doing a simple sanity
check, especially since the contents of the message are meaningless unless
RCODE is NOERROR.

> doesn't bother checking the IDs.

Again, this is a simple sanity check.  Failing to check the ID opens a
server to spoofing.  This is also a SHOULD, so axfr-get is still
compliant.

> doesn't bother repeating the question.

I have no strong opinion on this.  It's an arbitrary decision based on
existing practice, and bind has been around much longer than axfrdns.
It's also only a SHOULD.

> which takes records from all sections.

Why does axfr-get take records from all sections?  That sounds broken.

> data of some zone. See RFC 1034, section 4.2.

Huh?  Of course every record is in some zone.  This says that zone
transfers must only contain records from the zone being transferred, not
from any zone.

> with IPSEC, for example, shouldn't be encouraged to use TSIG.

I agree.

Brian

---

From: [email-masked]
Date: Thu, 15 Mar 2001 00:34:18 GMT

> Clients without authorization have no business asking for AXFR.

What if an "used to be authorized" slave became unauthorized due to
the master's misconfiguration?

A little bit RCODE and NOERROR would be better than just simply 
connection closing.

--
Aaron Durchgaloch -- Haifa High Tech Commerce R&D, Matam, IL-31905.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Mar 2001 13:56:03 -0000

As I said, BIND often transmits the same record many times in its AXFR
responses. But I was wrong when I said this could happen at the top of
the zone. It happens for a glue A record used by many child zones.

Brian Wellington writes:
> zone transfers must only contain records from the zone being transferred,

That's less restrictive than the current text, but I still object to it.
Clients discard undesired records; servers don't have to.

> Failing to check the ID opens a server to spoofing.

False. TCP connections already have sequence numbers---and anyone who
wants serious security for AXFR can run AXFR over IPSEC or ssh. You've
already agreed that IPSEC-protected AXFR shouldn't bother with TSIG, so
why do you think it should bother checking IDs?

> check, especially since the contents of the message are meaningless unless

axfr-get is working just fine. A properly constructed message doesn't
_have_ any records unless RCODE is NOERROR; the zone transfer will end
up being aborted. What I'm objecting to is your overly narrow view of
how clients should check for errors.

> really did request it, and the RD bit in the response should indicate what

Clients _don't_ do that. You are violating RFC 2119, section 6, second
sentence, by demanding that my server go to extra effort for the sake of
nonexistent slaves.

In the meantime, of course, you _aren't_ demanding that servers stick to
the one-answer format, even though there's still a huge installed base
of clients that can't handle your multiple-answer format.

  [ repeating the question section at the start of the AXFR response ]
> It's an arbitrary decision based on existing practice,

It's a pointless recommendation that doesn't take full account of
existing practice.

> Why does axfr-get take records from all sections?

Because it's the simplest strategy that works. Please stop trying to
throw roadblocks in the way of competing implementations.

---Dan

---

From: Peter Koch <[email-masked]>
Date: Thu, 15 Mar 2001 19:25:34 +0100

> 4. Glue

The term "glue" unfortunately has been fuzzy for quite some time now and seems
to be used in slightly different meanings throughout DNS literature - RFCs and
other. This is at least a major source of confusion whenever you try to teach
someone DNS.

The following paragraph essentially (and en passant) opens the definition to
"any nonauthoritative data associated with the zone", so I'd like to suggest
the heading be renamed to "Out of zone data".

>    A master transmitting a zone transfer MUST include the full set of
>    zone data it loaded from the zone's master file, from an incoming
>    zone transfer, or other similar means of configuring zone data.  This
>    includes any nonauthoritative data ("glue") associated with the zone

Similar here (and further below), remove the term in parentheses.

>    by being present in the zone's master file or the incoming transfer
>    along with the authoritative data.  This glue data includes any
>    configured zone data obscured by zone cuts or otherwise outside the
>    zone in case; it is not limited to RRs pointed to by NS records.
> 
>    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 authority or additional section.

Strictly speaking, "ordinary", i.e. non-AXFR responses do not have any glue at
all, because that term is restricted to the zone file or the zone itself, isn't
it?

>    when such RRs are pointed to by NS records in the zone being

You want to say that a master MUST NOT mix different sources for the
outgoing AXFR?

>    A slave receiving a zone transfer MUST accept glue data and recognize
>    it as such; glue MUST NOT be treated as authoritative data nor
>    entered into the cache.  Note that classifying an RR as glue or non-

[Side note: Servers do not have caches, resolvers do.]

So, under which conditions may these out-of-zone RRs be handed out again?
The slave MUST NOT put the out-of-zone data in an answer section of
non-AXFR responses? The slave MAY use it in the additional section of
a response iff it corresponds to a query for authoritative data from this
particular zone?

>    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.  Glue data that is not below the zone origin ("cross-zone
>    glue") MAY be discarded by the slave.

Unless, however, the slave is also a master for the zone (which it is, if
*anyone* was allowed to AXFR the zone from the slave).

>From the above I read the following motivation:

  The information (RRs) associated with the zone at the primary master shall
  remain the same, complete and unaltered regardless of how many and which
  intermediate masters/slaves are involved and especially regardless of what
  other zones those intermediate masters/slaves do or do not serve.
  Justification of any such association is out of the scope of this document,
  RRs are associated with the zone by appearing in the zone file at and being
  accepted by the primary master.

Provided that this summary matches Andreas' intent, would you mind adding
a sentence like this?

-Peter

---

From: Brian Wellington <[email-masked]>
Date: Thu, 15 Mar 2001 16:46:47 -0800 (PST)

> the zone. It happens for a glue A record used by many child zones.

OK.  I know bind 9 does not do this.  If bind 8 or 4 does, they're not
compliant.

> That's less restrictive than the current text, but I still object to it.

They sound about the same to me.

> Clients discard undesired records; servers don't have to.

What exactly do you mean here?

> why do you think it should bother checking IDs?

Because it's there, and should be the same as the query.  I would ask why
you wouldn't check them?  It can't be for performance reasons, since it's
an integer compare.

> how clients should check for errors.

Yes, a properly constructed message with a non-NOERROR rcode will not
contain any records.  But that's still not a good reason to not check.
I'm not sure how "sanity check everything" is a narrow view.  It sounds
like robust programming to me.

> sentence, by demanding that my server go to extra effort for the sake of

I wouldn't call copying one bit "extra effort", but I also don't think
this is important enough to argue about, since the RD bit should be
ignored by the slave anyway.

> of clients that can't handle your multiple-answer format.

While ISC BIND was the first implementation to use many-answers (in wide
use), it's not "our format".  Nowhere in 1034/1035 is is stated that AXFRs
must only put one record in each message.  Any clients that cannot accept
many-answer format are not compliant with this spec.

> It's a pointless recommendation that doesn't take full account of

It's a recommendation.  Your server can ignore it and still be compliant.

> throw roadblocks in the way of competing implementations.

In my opinion, it's simpler to only read records from the answer section,
since it requires less code, and there shouldn't be anything useful in
other sections.

I have no problem with competing implementations, as long as the
specifications are written from a correctness point of view, not a "let's
make this server compliant" point of view.  Note that most versions of
BIND are _not_ compliant with this spec.

Brian

---

From: [email-masked]
Date: Fri, 16 Mar 2001 13:12:45 +1100

On top of this RFC 103[45] currently allow you to have
	multiple queries outstanding on a TCP connection, including
	AXFR and IXFR.  The server is currently free to return
	answers to these in any order it cares to.  Potentially
	you could even multiplex multiple AXFR/IXFR streams, sorting
	the answers by id.

	This is all currently allowed, even if there are no
	implementations that do this.

	Sending multiple AXFR requests (whether by queuing or
	multiplexing) on the one socket should provide similar
	gains to sending multiple HTTP requests on the one socket.

	We should not be braking the ability to do this.

	Not sending a negative answers breaks the ability to have
	multiple AXFR's on one socket.

	Not check response ID's breaks the ability to have multiple
	outstanding queries.

	Also on the contention that AXFR is only for slaves, there
	are currently people who have RRsets that are bigger than
	what will fit in a DNS/TCP message.  The only way to retrieve
	these RRsets it to perform a AXFR and extract the RRset
	from the response.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2001 11:26:08 -0000

> these RRsets it to perform a AXFR and extract the RRset

The standard query procedure, as specified in RFC 1123 section 6.1.3.2,
is to try DNS-over-UDP first, and then to try DNS-over-TCP if the UDP
response was truncated and TCP is supported.

This procedure does not include your absurd DNS-over-AXFR. The
configurations you refer to simply don't work.

> multiple AXFR's on one socket.

False. The client can try sending multiple AXFRs. In the extremely rare
case that the connection is abruptly closed, the client can try again,
one AXFR at a time.

> Not check response ID's breaks the ability to have multiple

If multiplexing is allowed, yes, these nonexistent multiplexing clients
will have to check IDs. Now, why do you think that _my_ client should
check IDs? It uses a new TCP connection for each zone transfer.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2001 10:35:42 -0000

1. Suppose I'm a slave transferring the princeton.edu zone. I will
discard aol.com information from the princeton.edu servers. This is
required for security: the princeton.edu servers aren't authorized to
provide aol.com information.

Once you accept that this is the slave's responsibility, you have no
reason to demand that the princeton.edu AXFR servers omit aol.com
information.

2. Suppose I'm transferring both princeton.edu and cs.princeton.edu. I
will discard all princeton.edu AXFR results below cs.princeton.edu, in
favor of the cs.princeton.edu AXFR results.

To the extent that there's a difference, the princeton.edu servers are
wrong. For example, the princeton.edu servers say cs.princeton.edu NS
{cs.princeton.edu,engram.cs.princeton.edu}, while the cs.princeton.edu
servers say cs.princeton.edu NS {dns1,dns2}.cs.princeton.edu. If someone
asks me for the cs.princeton.edu NS records, I'm going to report
{dns1,dns2}.cs.princeton.edu.

Once you accept that this is the slave's responsibility, you have no
reason to demand that the princeton.edu AXFR servers omit unnecessary
cs.princeton.edu information.

Note that my decision to discard the cs.princeton.edu NS records from
the princeton.edu servers won't happen when I transfer princeton.edu: I
don't know at that point whether I'm also transferring cs.princeton.edu.

3. As a convenience to the administrator, my servers automatically treat
all records from child zones (and grandchild zones and so on) as
non-authoritative records for the parent zone.

When axfrdns has both princeton.edu and cs.princeton.edu, for example,
its AXFR results for princeton.edu won't include anything in aol.com but
will include everything in cs.princeton.edu.

This works just fine. Once again: slaves discard undesired records;
servers don't have to.

> They sound about the same to me.

The text says ``MUST NOT contain RRs from the authoritative data of
zones other than the one being transferred.''

What you're missing, apparently, is that a record can be from the zone
being transferred _and_ from another zone. The text prohibits child NS
records that are copied to the parent zone, for example.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2001 10:59:53 -0000

[ this is verging on material more appropriate for [email-masked]
  or bind-users than namedroppers.  last message in this vein please -- rb ]

Brian Wellington writes:
> Note that most versions of BIND are _not_ compliant with this spec.

That's a rather shocking statement.

Your coworker has presented this document to us as a clarification, a
``more complete definition of the protocol.'' He claims to have
``codified existing practice.'' But now you seem to be saying that you
don't care whether the document accurately describes existing practice.

> like robust programming to me.

So why does this document recommend that slaves ignore IDs in messages
past the first? Seems rather inconsistent. Why aren't you asking for
``sanity checks'' of all those IDs, just like the first one?

The answer, of course, is that unnecessary checks aren't ``robust
programming.'' They're interoperability hazards.

What's narrow about your view is that you don't see anything beyond
BIND. You're trying to force everyone to do exactly what BIND 9 does,
in violation of RFC 2119, instead of focusing on interoperability.

> since it requires less code,

False. I simply read records to the end of the packet.

---Dan

---

From: [email-masked]
Date: Sat, 17 Mar 2001 01:09:03 +1100

> configurations you refer to simply don't work.

	They only "don't work" if you block AXFR.  Using AXFR to
	retrieve a RRset that doesn't fit in a TCP response is
	a logical action to take if you need to see the contents
	of the RRset.

> case that the connection is abruptly closed, the client can try again,

	As I said it breaks the ability to get multiple AXFR responses
	on one socket.

> check IDs? It uses a new TCP connection for each zone transfer.

	We are describing how to build robust clients.  Give the errors
	I've see servers produce I think that checking the query id is
	one of the cheaper checks that can be done.

	Mark

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 16 Mar 2001 11:12:41 -0800 (PST)

> don't care whether the document accurately describes existing practice.

The draft attempts to codify *reasonable* existing practice.  Some
existing implementations are simply broken.  For example, BIND 4 sends
AXFR responses where some of the messages have QR=0 and others have
QR=1, violating the fundamental property of the DNS protocol that all
response messages have QR=1.  I do not believe that this particular
existing brokenness should be codified.  Instead, the draft explicitly
forbids it, thereby making BIND 4 noncompliant.

On the other hand, the draft does account for existing practice in
that it recommends against checking the QR bit and most other header
fields since they are known to be incorrectly transmitted by existing
implementations.

> ``sanity checks'' of all those IDs, just like the first one?

Because existing implementations are known to send incorrect IDs in
messages other than the first.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 16 Mar 2001 13:27:51 -0800 (PST)

> don't know at that point whether I'm also transferring cs.princeton.edu.

Suppose the master is a primary master, loading its zone data from
master files.  What I'm trying to say is that in a zone transfer of
princeton.edu, the master must transmit exactly the information it
loaded from the princeton.edu master file.  If the princeton.edu
master file contained data below cs.princeton.edu, it MUST be
transmitted.  Records below cs.princeton.edu that were not present in
the princeton.edu master file MUST NOT be transmitted, even if the
server happens to have such records because it is also authoritative
for cs.princeton.edu.

As you say, it is the responsibility of the slave to NOT include any
cs.princeton.edu data received in a princeton.edu zone transfer in the
answer section when responding to an ordinary query.  However, it MUST
include such data in an outgoing transfer of princeton.edu to a
subordinate slave.

The reason for these rules is to ensure that for a particular zone
serial number, all the authoritative servers agree on the contents of
the zone (including glue data associated with the zone).  The IXFR
protocol relies on this being the case.  See also RFC2136 section 7.18.

The case of aol.com data in the princeton.edu zone file is more of a
grey area.  I do not think there is a clear consensus in the DNSEXT WG
as to whether cross-zone glue like the A record in the following
example (from a hypothetical princeton.edu zone file) should be
supported:

	cs.princeton.edu	NS	ns2.aol.com.
	ns2.aol.com		A	10.0.0.1

The issue of whether servers should support such cross-zone glue is
outside the scope of the draft under discussion.  However, supposing
that both servers do support it, it makes sense for the princeton.edu
master to include an ns2.aol.com A record loaded from the princeton.edu
zone file in an outgoing transfer of princeton.edu, and to NOT include
aol.com data from any other zone file.  Again, it is the
responsibility of the slave to not use the out-of-zone data in answers
to ordinary queries, but it may be used as glue in referrals out of
the princeton.edu zone and in outgoing transfers to subordinate
slaves.

> will include everything in cs.princeton.edu.

I consider that behavior to be incorrect.  The handling of out-of-zone
data in BIND 4 and BIND 8 is also incorrect, for different reasons.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Mar 2001 14:28:17 -0000

Andreas Gustafsson writes:
  [ aol.com records in a zone transferred from princeton.edu ]
> it may be used as glue in referrals

No. That is completely unacceptable from a security perspective.

Consider, as an easy example, a server handling both the .net zone and
the microsoft.net zone. Suppose the microsoft.net people say

   blah.microsoft.net NS ns.slashdot.net
   ns.slashdot.net A 207.46.232.37

in an AXFR response to this server. It is essential for the server to
discard the glue A record; otherwise it will poison caches, because
caches trust ns.slashdot.net information from .net servers.

If IXFR relies on the server keeping this record, then IXFR is broken.
Furthermore, the IXFR protocol has an official status of Elective, and
my users have a better protocol (rsync), so I am not going to support
IXFR, and I object to IXFR-induced complications in the AXFR protocol.

> Records below cs.princeton.edu that were not present in
> the princeton.edu master file MUST NOT be transmitted,

My servers use a redesigned unified configuration-file format, different
from your master-file format. As I said, they automatically treat all
*.cs.princeton.edu records as non-authoritative records for the
princeton.edu zone, as a convenience for the system administrator.
Everything works.

You claim without justification that it is ``incorrect'' for the
princeton.edu zone to contain (e.g.) www.cs.princeton.edu records, even
though you say that www.aol.com records are okay. I don't see any
support for your views in the DNS specifications.

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 18 Mar 1 7:53:47 JST

Dan;

> caches trust ns.slashdot.net information from .net servers.

In an AXFR, exactly what is contained in the master zone file
is transferred.

The primary server transmit exactly what is contained in a master
zone file of a zone.

Secondary servers transmit exactly what is received from upstream
server.

AXFR and IXFR has nothing to do with caching.

> My servers use a redesigned unified configuration-file format,

Your server is wrongly implemented, then.

(FYI, last time I checked BIND code in detail several years ago, it was
wrong too.)

Glue information is local to a zone (actually, local to a referral point
that same name server may have different A records referral by referral,
though such information can not be represented by standard zone file or
zone transfer format), that same name server may have different A
records zone by zone.

That is the reality of the database and the behaviour is not forbidden
by the specification.

Thus, glue information may be chached not in global cache but in
cache local to a zone (or, better, local to a referral point).

Then, different A records from different referral points can be cached
independently and replies can choose appropriate chache.

Note that your server is wrongly implemented in a way not directly
related to AXFR nor IXFR that, if you want to continue this thread
on correct chaching, you should better use a subject like "multiple
chache".

							Masataka Ohta

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Mar 2001 06:07:29 -0000

Masataka Ohta writes:
> same name server may have different A records zone by zone.

That's the BIND 9 model, but it is _not_ consistent with RFC 1034.
Here's what the DNS specifications actually say:

   * DNS is divided into zones. Names are partitioned among zones. Each
     zone is authoritative for all records under its names. See RFC
     1034, section 4.1.

   * Zones may---and sometimes must---contain records for which they
     aren't authoritative, i.e., records from other zones. These records
     are supposed to be EXACT COPIES of the authoritative records. See
     RFC 1034, section 4.2.1, last paragraph on page 20.

I realize that people often make mistakes in copying records: look at
cs.princeton.edu, for example. Those people are violating the protocol.
They have no right to expect clients to preserve both sets of records.
Clients can and do assume the accuracy of any record set received from
any server authorized to provide that set.

> Your server is wrongly implemented, then.

Don't be ridiculous. I'm not going to force my users to deal with that
horrendous format. If they want painful configuration, they can use the
BIND master-file format. That format is, by the way, neither stable nor
identical to the standard RFC 1034 master-file format, so you can't
justify it on interoperability grounds.

---Dan

P.S. One of my recent messages hasn't shown up on the list. Is Bush
censoring messages again, or is he simply incompetent? For previous
incidents see http://cr.yp.to/djbdns/namedroppers.html.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2001 03:05:35 -0000

Masataka Ohta writes:
> "supposed to be" is not a protocol standard but a best current practice.

False. Please read RFC 1034. The paragraph that I cited says, among
other things, that the non-authoritative NS records in the parent zone
should be ``exactly the same as the corresponding RRs in the top node of
the subzone.'' The current cs.princeton.edu NS records flunk this test.

> What is the problem, then?

The problem is that this document, in violation of RFC 2119 section 6,
imposes requirements that aren't needed for interoperability. If I'm
transferring both princeton.edu and cs.princeton.edu, I'm going to throw
away the bogus set of NS records in favor of the authoritative set, and
everything will work.

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 19 Mar 2001 11:17:24 +0859 ()

Dan;

>      RFC 1034, section 4.2.1, last paragraph on page 20.

Glue records are provided by (sometimes malicious) human intervention.

Protocols must assume they are supposed to be but may not be the exact
copies.

> any server authorized to provide that set.

It's OK as long as the clients can reach the desired data.

> BIND master-file format.

So, your server works just fine with the real world BIND master-file
content.

> That format is, by the way, neither stable nor

I know. Several years ago, I found a bug on escape characters.

But, a problem here is that binary zone transfer format is not good
enough to distinguish glues of each referral.

						Masataka Ohta

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 19 Mar 2001 09:52:52 -0800 (PST)

> caches trust ns.slashdot.net information from .net servers.

Yes, this is a potential security problem, and dropping cross-zone
glue is one possible way of dealing with it.  Another would be to not
host a parent and mutually untrusting children on the same server.

This and related security issues could be fruitful topics for a
separate I-D.  If we do choose the solution of outlawing cross-zone
glue, I think the zone transfer protocol is the wrong place to enforce
it, because the restriction should apply to primary masters as well as
slaves.

> though you say that www.aol.com records are okay.

I did not say that.  Records for www.cs.princeton.edu (or www.aol.com)
can be part of a princeton.edu zone transfer, if and only if they are
part of data configured specifically for the princeton.edu zone
(whether by means of a princeton.edu zone file, an incoming
princeton.edu zone transfer, or some other configuration mechanism).
Neither www.cs.princeton.edu nor www.aol.com may be included in a
princeton.edu zone transfer merely as a result of the master also
being authoritative for the cs.princeton.edu or aol.com zone.
-- 
Andreas Gustafsson, [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Mar 2001 02:55:34 +0859 ()

Dan;

> the subzone.'' The current cs.princeton.edu NS records flunk this test.

"should be" is not a protocol standard but a best current practice.

RFC 1034 says:

: 4.3.5. Zone maintenance and transfers
: 
: Part of the job of a zone administrator is to maintain the zones at all
: of the name servers which are authoritative for the zone.

The fundamental property of distributed database is that there will
be some inconsistencies.

Accept it.

> away the bogus set of NS records in favor of the authoritative set, and

Your intelligent intermediate entities are not allowed to try to
administrate the zones, even if the administrators are dumb.

Zone administrators are responsible for the content of zones.

If you want to reduce the inconsistency prolem, you should develop
tools for zone administrators to maintain the zones at all of the
                                                       ^^^^^^^^^^
name servers.

							Masataka Ohta

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 23 Mar 2001 16:37:26 -0500

>    appropriate RCODE other than NOERROR.

Later (Section 3.2), it says that the AA flag in the response is "1 (but MAY
be 0 when RCODE is nonzero)".

(By the way, is it good form to equate "other than NOERROR" with "nonzero"?)

I would prefer things to be more explicit, in the case where the server is
not authoritative for the requested zone. Either a) return RCODE=NOTAUTH, or
b) at the very least, *require* AA=0 in this situation, and AA=1 in all
other RCODE!=NOERROR situations.

The ultimate goal should be the ability for the client to know unambiguously
that the server is not authoritative for the zone.

- Kevin