Subject: DNSEXT WGLC Summary: AXFR Clarify

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 04 Apr 2001 18:23:21 -0400

This working group last call has completed.
Some issues where raised during the Last Call that document editor needs to
address,
	Better definition of "glue" as suggested by Peter Koch.
	few minor edits proposed by others.

The working group consensus is to advance the document once these issues
have been addressed.

	Olafur

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

---

From: Sam Trenholme <[email-masked]>
Date: Fri, 6 Apr 2001 13:46:01 -0700 (PDT)

> The working group consensus is to advance the document once these issues

I feel that section three should be rewritten.  It currently says:

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.

I would change this to say:

3. The zone transfer response

   If the master server is unable or unwilling to provide a zone
   transfer, it SHOULD respond with a single DNS message containing an
   appropriate RCODE other than NOERROR.  Some master servers will
   prematurably disconnect an unauthoirized tcp connection to the master
   server.  Slaves SHOULD interpret such a premature disconnect as a
   "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1).

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

This will better reflect the reality of AXFR servers which restrict access
by promptly disconnecting any unauthorized third parties.

- Sam

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 06 Apr 2001 18:35:17 -0400

> by promptly disconnecting any unauthorized third parties.

I'd rather not reflect a *broken* reality. A premature disconnect is ambiguous:
it could have been a refusal, but on the other hand, it might have been some
sort of mundane networking problem.

If the master refuses the zone transfer, the client has a right to unambiguously
know that fact. Similarly (reiterating my previous message on the subject), if
the master declines the zone transfer because it is not authoritative for the
zone, the client has the right to unambiguously know it.

Unambiguous behavior facilitates troubleshooting for us DNS admins in the
trenches.

- Kevin

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 06 Apr 2001 17:44:56 -0400

> by promptly disconnecting any unauthorized third parties.

A dropped connection can also occur as a result of a transient glitch
(e.g., temporary server shutdown, resource shortages, etc., ), for
which an appropriate action is for the client to retry in the near
future (with clamped exponential backoff).

						- Bill

---

From: Robert Elz <[email-masked]>
Date: Sat, 07 Apr 2001 13:44:57 +1000

Date:        Fri, 6 Apr 2001 13:46:01 -0700 (PDT)
    From:        Sam Trenholme <[email-masked]>
    Message-ID:  <[email-masked]>

  | I would change this to say:

I know what you're getting at, and why, but that isn't the best solution.

Better would be...

   Slave servers should note however, that there are some implementations
   where a master server will simply close the connection when no access
   to the zone is to be provided to the slave.   Slaves SHOULD interpret
   a premature graceful close of a TCP connection as "Query Refused"
   (equvalent to RCODE 5 in RFC1035 section 4.1.1).

Aside from formatting, there are two differences there from your text.
First, only "graceful close" is to be treated as "refused" - TCP
connections can be reset for all kinds of other reasons (master rebooted
at just the wrong time, etc) - none of that usually means "refused".

And second, there's no need to make it seem that there's ever a rational
reason for the master to do this (by changing MUST to SHOULD) - keep the
requirement that the server respond properly - just add the advise to
implementors that there are broken servers, and how they should be treated.

kre

ps: I wish we could get back to 1034/1035 terminology - servers are primary
and secondary, not master & slave, "master" applies to the zone file held
by the primary server.  (Unfortunately, there are a few places where the
text slipped, and "master" is used where "primary" would really have been
better).  1034/1035 don't mention "slave" at all, for anything.

---

From: [email-masked]
Date: Sat, 07 Apr 2001 13:45:49 +1000

> by promptly disconnecting any unauthorized third parties.

	Such nameservers already violate the spirit of 103[45], make
	debugging configurations harder and are just plain rude.  We
	don't need to encode bad behaviour.  

	If existing configurations don't meet this document, that is fine.
	It's no different that what it is today.  However we don't want
	new nameservers to have the same problems.  Conformance to this
	doc should be a MUST.

	This document is doing two things:
	1 stating what you should be doing.
	2 stating what potential problems you can have interoperating
	with old servers which are not conforming to this document.

	The quoted paragraph falls into category 1.

	Mark

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

---

From: Roy Arends <[email-masked]>
Date: Sat, 7 Apr 2001 04:48:02 +0200 (CEST)

> by promptly disconnecting any unauthorized third parties.

I strongly disagree, If a nameserver stumbles upon a query-type (for
instance 252 (axfr)) that it can (or will) not compute, it must answer
with an appropriate RCODE other than NOERROR. Note that AXFR request
responses may not be TCP bound at all, if the amount of data is within the
512 byte UDP boundary. If some master servers will premature disconnect an
unauthorized tcp connection to itself, the "timeout" will take care of the
issue. IMHO not a valid protocol change.

Regards,

Roy Arends 
Nominum

---

From: Robert Elz <[email-masked]>
Date: Sat, 07 Apr 2001 13:44:57 +1000

Better would be...

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Apr 2001 08:26:44 -0000

I am a DNS implementor. My DNS implementation is used at thousands of
sites, including the third-largest and fourth-largest domain hosting
companies on the Internet.

I have raised several objections to this document, including an
undisputed claim that the document violates RFC 2119 section 6. (One of
my messages was discarded by Randy Bush, the namedroppers censor, but is
available through http://cr.yp.to/djbdns/namedroppers.html#2001-03-17.)

There have been a few responses to my objections. I am not at all
satisfied with the responses. Sam Trenholme is another DNS implementor,
and he has stated elsewhere that he isn't satisfied either.

Gudmundsson claims that this document is, with minor changes, the WG
consensus. I don't see any justification for that claim. I would like to
see a rational discussion of this document by the WG.

Kevin Darcy writes:
> If the master refuses the zone transfer, the client has a right to
> unambiguously know that fact.

Wrong. Zone transfers are between a master and its authorized slaves.
Unauthorized clients have no rights.

> A premature disconnect is ambiguous:

Irrelevant. If the AXFR fails, for whatever reason, the client tries
again later. The reason doesn't matter.

Yes, there are protocols with permanent errors. (``Bounce this mail
immediately; I will never accept it.'') But AXFR is not one of those
protocols. In particular, it would be silly for an AXFR client to treat
REFUSED as a permanent error.

---Dan

---

From: Greg Hudson <[email-masked]>
Date: Sun, 08 Apr 2001 10:30:14 -0400

I don't have a strong opinion on this topic, but at the moment I think
the arguments are stronger for explicit refusals of disallowed zone

> Wrong. Zone transfers are between a master and its authorized
> slaves.  Unauthorized clients have no rights.
[...]
> again later. The reason doesn't matter.

If a master is misconfigured and is rejecting zone transfers from a
slave, or if a slave is misconfigured and is asking the wrong master,
it is useful to be able to distinguish this behavior from a software
or network fault for debugging purposes.

Moreover, an AXFR client might want to know whether to raise a red
flag to the administrator ("you have a misconfiguration here") or just
silently retry.

So while the AXFR client's appropriate network behavior may be the
same in both cases, its appropriate user-visible behavior may not be.

---

From: Sam Trenholme <[email-masked]>
Date: Sun, 8 Apr 2001 23:24:51 -0700 (PDT)

> or network fault for debugging purposes.

I think the fundamental debate here is what balance between security and
convenience one should have.

Those who find convenience more important than security do not mind that a
potentially unauthorized client uses resources and can potentially exploit
securiy via TCP port 53.  Since a verbose "query refused" error message
requires the unauthorized client to connect to port 53, giving the
unauthorized client some (albeit small) level of privledge with the name
server, I can see where a security-conscious person would not want this.

A security-consious person also does not mind the fact that the small
number of standard DNS queries that need more than 512 bytes in the reply
can not be properly processed.  There are ways of shaving most of these
queries down to a reasonable size (the abuse of DNS in the z.zoy.org
domain notwithstanding) [1].

On the other hand, we have the fact that immediately dropping the TCP
connection is a bit "rude", and can make it more difficult to troublshoot
problems.

I feel that the balance between security and convenience here is an
engineering one that the implementor of a DNS server should make.  I do
not find it appropriate for an IETF RFC to make that decision for the
implementor.

This is why I oppose the wording of "it MUST respond with a single DNS
message containing an appropriate RCODE other than NOERROR" (when the
server does not want to perform an AXFR) in section three of the AXFR
clarify document.

- Sam (Just my two cents)

---

From: Greg Hudson <[email-masked]>
Date: Mon, 09 Apr 2001 11:52:28 -0400

Sam Trenholme wrote:
> Those who find convenience more important than security do not mind
> that a potentially unauthorized client uses resources and can
> potentially exploit securiy via TCP port 53.  Since a verbose "query
> refused" error message requires the unauthorized client to connect
> to port 53, giving the unauthorized client some (albeit small) level
> of privledge with the name server, I can see where a
> security-conscious person would not want this.

Unless I'm missing an important detail here, this argument doesn't
seem to follow.  There are two viewpoints:

	* The architect wants a verbose error for easier diagnosis and
	  debugging.

	* The security officer doesn't want to allow connections on
	  port 53 from unauthorized IP addresses, in case there is an
	  exploit.

I don't think the current draft disallows either approach; you're not
required to accept connections on port 53 if you don't want to.

But what you and Dan seem to be advocating is a worst-of-both-worlds
possibility: accept a connection on port 53 and then drop it suddenly.
How does this improve security?  If you have to read the request in
order to decide whether the client is authorized, then that's where
your exploit will be; writing out an error response is not an
error-prone operation.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 9 Apr 2001 10:51:01 -0700 (PDT)

> server, I can see where a security-conscious person would not want this.

If a server refuses all TCP connections to port 53, or immediately
drops all such connections, it is exercising access control at the
transport level, not at the the level of the AXFR protocol.  The TCP
connection attempt may have been for a non-AXFR (or even non-query)
request.  Therefore, I would argue that this issue is outside the
scope of a draft dealing specifically with AXFR.

This is similar to how people use tools like "tcpwrappers" to deny
access to other protocols such as telnet, FTP, or SMTP, even though
the specifications of those protocols do not explicitly specify that
closing the TCP connection is a valid way of indicating unwillingness
to provide service.

Only when the DNS server accepts the connection, receives and decodes
a request, identifies it as an AXFR request, and decides to deny it in
that capacity, does the draft require the server to send an error
response.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 09 Apr 2001 18:17:57 -0400

> Unauthorized clients have no rights.

I apologize for anthromorphizing; obviously it doesn't make sense, strictly
speaking, to say that a client has "rights" or doesn't have "rights". But
the *administrators* of those clients, I think, have a right for their jobs
to not be unduly complicated and burdened by enshrining broken behavior
into an RFC. Why should anyone have to chase their tails trying to nail
down what *looks* like a networking problem, only to discover that the
idiot DNS admin forgot to modify a zone transfer ACL? As I said in my
original message, unambiguous behavior makes things easier for us
DNS admins in the trenches. And how much code could it be, really, to have
the server send a proper REFUSED response instead of just abruptly closing
the connection? Do we really value the time and effort of a handful of
DNS developers -- i.e. to code the proper behavior -- over the time and
effort of thousands of DNS administrators, i.e. to troubleshoot client
problems? I just don't see how the alleged benefits of this proposal could
possibly be worth the undeniable costs (but of course I'm biased, being
primarily a DNS admin rather than a developer)...

> protocols.

Well, who *says* AXFR is not a protocol where "persistent" (not necessarily
*permanent*) errors might be treated differently than transient ones? Maybe
an AXFR client would want to log a disconnect differently than a refusal,
or maybe it would adopt a different retry strategy. Hell, in some contexts,
maybe the client wouldn't even bother retrying between the hours of, say,
9am and 5pm because it simply *knows* that there are no DNS administrators
who are available outside of those hours to fix a DNS misconfiguration. We
can't predict every possible feature that a DNS implementation might want
to include; we can only specify that behavior be as informative as
unambiguous as possible, and then let the implementations build on that. By
allowing premature disconnects to be considered equivalent to
REFUSED responses, the amount of information available to the application
as to the cause of the failure is obscured, and the ability for it to make
intelligent decisions about further actions is consequently impaired. I am
therefore against the proposal.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 09 Apr 2001 18:39:22 -0400

> server does not want to perform an AXFR) in section three of the AXFR

I'm doubtful that there is much DoS exposure here, if any -- it's just one
packet in, one REFUSED response packet back, no recursion, no
DoS amplification. How is anyone going to exploit this any more than, say,
DoS'ing an HTTP server or an SMTP server or an FTP server or ...? Anyone who
cares about the DoS risk is going to have some sort of IDR in place anyway.

Having said that, however, I wouldn't be averse to watering down the language
such that a nameserver could ignore AXFR requests -- simply tearing down the
connection without sending a REFUSED response -- as long as it behaved that
same way for *all* requests with the same credentials, including ordinary
DNS queries. In other words, if a nameserver wants to "blacklist" a certain
client or set of clients (possibly DoS suspects), then it can do so, but it
should not *discriminate* against AXFR requests in particular. I'm using
"credentials" in a very broad sense here -- a client's source IP address
could, for instance, be considered its "credentials" by a nameserver; or, a
more strict server might insist on some sort of crypto-signature as a way of
determining a client's credentials.

In this way, I would hope to remove any incentive for DNS implementors to be
lazy about how they deal with unauthorized client requests, while still
retaining intact their ability to implement proper safeguards against certain
forms of DNS DoS attacks. I think it would be a reasonable compromise...

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Apr 2001 21:32:33 -0000

Clients aren't authorized to ask me about aol.com. Clients aren't
authorized to send me TCP queries about cr.yp.to---my UDP responses
aren't truncated. Even if I do authorize normal TCP queries someday,
clients won't be authorized to send me AXFR requests.

djbdns doesn't answer queries for unknown domains by default. It refuses
TCP queries by default. Even if it does answer TCP queries, it drops
AXFR connections by default.

This behavior does not create interoperability problems. Prohibiting it
with MUST NOT, or discouraging it with SHOULD NOT, is in violation of
RFC 2119 section 6.

Would it be terribly difficult for djbdns to talk to unauthorized
clients? Of course not. But those clients have no rights. I reject the
notion that I should go to even the slightest effort on their behalf.

---Dan