Subject: Re: ZXFR specification?

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Apr 2002 11:45:27 -0700

> I was trying to find out more about ZXFR but I can't find anything. Is there
> more specification than the bind source?

zxfr was a crude hack that doesn't work and isn't standard and will never be.
(it predates edns, for one thing; today we'd make compression a negotiable
fact about a transfer.  in fact, today we'd make incremental differences a
negotiable fact about a transfer.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jim Reid <[email-masked]>
Date: Tue, 30 Apr 2002 01:09:30 -0700

>>>>> "bert" == bert hubert <[email-masked]> writes:

    bert> So I wouldn't worry too much about this, as a root-server
    bert> often gets in the order of 3000 questions/second already.

This is an easy thing for someone who doesn't run a root server to
say. The root servers get so much crap flung at them the last thing
they need is even more gratuitously unnecessary traffic. What makes
this all the more depressing is most of this load would go away if
people configured their name servers and stub resolvers correctly or
ran servers that understood negative caching. Take a look at the work
done by the people at CAIDA analysing root server traffic. I think
this was presented at a recent NANOG meeting and it will be presented
at the DNS Working Group at RIPE42 on Thursday.

BTW, 5000+ qps is the typical load on a root server these days: you
can double that for a.root-servers.net.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 12:20:16 -0800

> > but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer.
> 
> Noted. PDNS 1.99.8 will send out SERVFAIL. So far we have sometimes seen
> unexplicable high question rates for domains for which we are not
> authoritative, which may be related to the fact that currently we send out
> an unauthoritative 'NOERROR' empty answer.

indeed.  resolvers don't know what to do with REFUSED, so many of them just
treat it as an uncached SERVFAIL, meaning they move on to the next NS RR and
don't fail the query until all NS RRs answer with the same error.  and when
the next similar query comes in from the application layer, they do it all
again.  a few (very few) implementations will cache the SERVFAIL in this
case but none i have seen will cache the REFUSED.

> How about a server which has this as its only zone:
> 
> @		IN	SOA ...
> something	IN	CNAME	something.else.com.
> 
> And receives a question for 'something', but cannot recurse to find data
> about something.else.com.?
> 
> Bind 8 sends SERVFAIL.

BIND8 uses SERVFAIL too liberally.  one truly does wish for the NOTAUTH code
standardized in RFC2136 to be available for normal queries.  it may even be
worth checking existing resolver behaviour in the face of such a code -- it
will not be recognized and it's hopeful that it would cause the query to fail
rather than the next NS to be tried.

sending back an upward delegation is the way nameservers can refer to the 
root servers to get rid of these pesky clients.  which is no doubt why most
of the answers sent back by any given root server are repeated NXDOMAINs or
repeated delegations.  a server which is lame ought to have a way to cause
the transaction to just terminate.  though that raises robustness issues.

a truncated CNAME chain, where the "next hop" is in a zone the current
server isn't authoritative for and recursion is disabled IS a "problem with
the name server" and in this case "2" (SERVFAIL) is the appropriate answer.

a lot of the conceptual damage is done in the forwarding model.  authority
servers should not see queries for which RD is set -- if recursive servers
made their own upstream queries and regenerated the responses back to the
requestor, then CNAME chaining would not occur in authority servers at all.

---

From: Jim Reid <[email-masked]>
Date: Fri, 05 Apr 2002 05:44:18 -0800

>>>>> "bert" == bert hubert <[email-masked]> writes:

    bert> RFC 1034/1035 are not a viable guideline. Actual practice
    bert> diverges on many places. Cf the SOA 'ttl_minimum' field.

Well for this particular example RFC2308 updates 1034/35, so I don't
understand the point you're trying to make here. If you are saying
that there are holes in 1034/35 that need plugged or further
clarification is necessary, feel free to submit an appropriate
draft. Until then 1034/35 and the RFCs which update it are the only
viable guidelines we have.

Now to get back to the original question, my feeling is it probably
doesn't matter too much what sort of answer a non-recursive,
authoritative only server returns when it's asked for something it's
not authoritative for. As long as the server answers. After all the
resolver originating the query is broken and deserves all it gets.
However the server should give some sort of answer that prevents
repeated queries and reduces latency. It would be good manners and
common sense to give a referral: it's not as if this is expensive to
do or code. Quibbling over the semantics for an error reply instead
doesn't seem worth a discussion. Does it matter whether a SERVFAIL --
"I don't know what to tell you" -- or REFUSED -- "I don't want to tell
you" -- is returned? For this scenario, both ultimately mean pretty
much the same thing: you shouldn't have asked me.