Subject: name server without root cache

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Apr 2002 09:19:26 +0200 (CEST)

during the testing of nsd (the authorative-only name server developed at
nlnetlabs) a protocol question regarding name servers without a root cache
has been raised.

the basic question: is it required by a name server to provide a referral
(to the root or elsewhere)? if it can not provide a referral, what status
code should it return?

my personal view: if it is required, a name server without a root cache
should return SERVFAIL if it can not provide a referral. if it is not
required, a nameserver without a root cache may return REFUSED if it
choose not to answer the query.

	jakob

--
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: bert hubert <[email-masked]>
Date: Wed, 3 Apr 2002 10:22:00 +0200

> nlnetlabs) a protocol question regarding name servers without a root cache

Interesting. The PowerDNS nameserver pdns (http://www.powerdns.com/pdns)
also has no 'hints' file.

> (to the root or elsewhere)? if it can not provide a referral, what status

I can only add the voice of experience as I am no standards guru. We return
a regular unauthoritative answer with an empty answer section which appears
to satisfy recursing nameservers visiting us.

When I investigated this I found that sending out 'hints' was not mandatory
and in fact (imnsho) only confuses matters. 

> choose not to answer the query.

Of greater importance is how the vast installed base out there would react
to that. 'REFUSED' has different connotations ie 'I would have answered but
your IP address doesn't allow me to'. 

Another interesting case is that of the 'out of bailiwick CNAME'. Bind8
responds with a SERVFAIL if it encounters a CNAME for which it
can't/shouldn't resolve the RHS. 

PDNS doesn't as it considers that it has done all it can and has not failed. 

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Apr 2002 10:37:59 +0200 (CEST)

> your IP address doesn't allow me to'.

REFUSED could mean 'I maybe could have answered but I did not feel like
it'.

bind8 returns SERVFAIL without any root cache, bind9 returns REFUSED if
configured not do recursion and not to supply additional from cache,
otherwise it returns it's built-in root cache if I remember correctly.

	jakob

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 3 Apr 2002 11:04:32 +0200 (CEST)

> and in fact (imnsho) only confuses matters.

According to my view, the best practice is to have a hint file, and return
a referal to the root.

> your IP address doesn't allow me to'.

I agree. If there is no hint file, SERVFAIL is the correct response.

One problem with DNS is that the status NOERROR is overloaded with
different meanings. We want the server to say

"The name you asked for is not within any of the domains that I handle,
and I don't do any recursion (or you asked me not to recurse)"

The NS records to root as such are of no importance, but must be there to
give a reasonble responce.

Mats

----------------------------------------------------------------------
Mats Dufberg				             Registry TeliaNet
[email-masked]                                  Skanova/AO Networks
+46 8 456 7274                                               Box 10707
+46 70 258 2588                                    SE-121 29 Stockholm
----------------------------------------------------------------------

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Apr 2002 19:13:26 +0200 (CEST)

> I agree. If there is no hint file, SERVFAIL is the correct response.

if the hints file was missing unintentionally, I agree that SERVFAIL is
the correct response. however, if the file was left out due to policy,
REFUSED is better since I did leave it out on purpose. put in other words,
I simply choose to refuse to answer queries not in my zones.

	jakob

---

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

> I simply choose to refuse to answer queries not in my zones.

if REFUSED meant what it sounds like it means, i would agree.

|RFC 1035        Domain Implementation and Specification    November 1987
|...
|                2               Server failure - The name server was
|                                unable to process this query due to a
|                                problem with the name server.
|...
|                5               Refused - The name server refuses to
|                                perform the specified operation for
|                                policy reasons.  For example, a name
|                                server may not wish to provide the
|                                information to the particular requester,
|                                or a name server may not wish to perform
|                                a particular operation (e.g., zone
|                                transfer) for particular data.
|...
|Mockapetris                                                    [Page 27]

"configuration" != "policy".  not having a hints file is, according to
other parts of the standard, a "problem with the name server."  it's
certainly possible that since "authoritative only" name servers were 
not contemplated by the standard, that this is an obscure corner case
and would have been resolved differently had such contemplation occurred.

some here would like to say that "policy" includes such decisions as "i
choose to have no hints file."  but rfc1035 doesn't give you that choice,
and so your choice would equate to a "problem with the name server."

but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer.

---

From: bert hubert <[email-masked]>
Date: Wed, 3 Apr 2002 22:09:12 +0200

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

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.

Thanks for your time.

Regards,

bert hubert

---

From: Rob Austein <[email-masked]>
Date: Wed, 03 Apr 2002 15:22:34 -0500

I don't think that RFC 1035 rules out RCODE=5 in this case, because
nothing in the text Paul quoted restricts the subset of all possible
requestors to which one is refusing service to being a proper subset.

---

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

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

> about something.else.com.?

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: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 13:02:35 -0800

> requestors to which one is refusing service to being a proper subset.

the way i read it, RCODE=2 is "i don't have what you want" whereas RCODE=5
is "i have it but i'm just not going to tell you."

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 03 Apr 2002 16:06:32 -0500

> but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer.

Quoth RFC 1034:

     If recursive service is not requested or is not available, the non-
     recursive response will be one of the following:

        - An authoritative name error indicating that the name does not
          exist.

        - A temporary error indication.

        - Some combination of:

          RRs that answer the question, together with an indication
          whether the data comes from a zone or is cached.

          A referral to name servers which have zones which are closer
          ancestors to the name than the server sending the reply.

        - RRs that the name server thinks will prove useful to the
          requester.

According to strict interpretation of this standard, an implementation conforms
as long as it provides at least one RRset that it considers "useful to the
requester". Under this vague standard, I vote for returning !AA, ANCOUNT=0, and
an NS RRset in the Authority Section for one of the nameserver's authoritative
zones, chosen at random, or based on some arbitrary measure of predicted
"usefulness" to the requestor. :-)

Seriously, though, I think the spirit of the standards dictates that REFUSED is
only used for deliberate, policy-based denials of access (as Paul implied).
SERVFAIL, on the other hand, implies an operational problem with the
nameserver. Just because the nameserver is implemented as authoritative-only
without any root hints doesn't, in my opinion, warrant a SERVFAIL response.
Implementation != operation. As a DNS administrator, first and foremost,
I don't want to go on a wild goose chase, looking to find an operational
problem with someone's nameserver, only to discover in the final analysis that
the implementation simply doesn't support root hints.

I think a compelling argument can be made for NOTIMP here: after all, the
query, being outside of the server's authoritative zones, is one which the
particular server implementation is not equipped to handle...

- Kevin

P.S. One more thing to put on the TODO list for the inevitable RFC 1034/1035
rewrite...

---

From: Rob Austein <[email-masked]>
Date: Wed, 03 Apr 2002 16:33:12 -0500

> is "i have it but i'm just not going to tell you."

Whereas I read RCODE=2 as "I'm broken" and RCODE=5 as "Thhhppt!".

---

From: Alexis Yushin <[email-masked]>
Date: Wed, 3 Apr 2002 23:47:50 +0200 (CEST)

>the name server" and in this case "2" (SERVFAIL) is the appropriate answer.

What's wrong with giving the CNAME alone without the data it points to
and let the resolver fetch it somewhere else?

Alexis

---

From: Bob Halley <[email-masked]>
Date: 03 Apr 2002 14:02:12 -0800

> is "i have it but i'm just not going to tell you."

I agree with Rob.

I read RCODE=2 as a combination of "I am broken" and "I could not
answer your question due to problems in the DNS system".  (It would be
nice if there were separate codes for the two concepts, but oh well.)

I read RCODE=5 as "I don't want to serve this request for my own
reasons".  That includes the policy "I only answer questions for which
I am authoritative".

/Bob

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 04 Apr 2002 00:05:41 +0200

* I think a compelling argument can be made for NOTIMP here: after all, the
 * query, being outside of the server's authoritative zones, is one which the
 * particular server implementation is not equipped to handle...
 
But in the case of NSD the nameserver has a mechanism for returning
'hints' available but either an error is made or a policy
decision. NOTIMP is I would say not the proper return code.

We made it a (not so explicit) requirement for NSD that a hints file
is to be included if the server is not authoritative for the
root. Hence a SERVFAIL if it is not there.

Now Jacob argues that one should be able to refuse handing out the
hints, as a policy. If that is a requirement for NSD we should return
REFUSE.

Judging from the RFCs (the bit which says that useful data should be
returned in the answer) and the discussion on the list I would say we
stick with the requirement that hints MUST be configured. We'll make
that requirement more explicit.

Thanks for the input.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 03 Apr 2002 17:16:29 -0500

Olaf Kolkman wrote:

> decision.

Okay, I misunderstood the context. I thought root hints was simply not a
capability that the implementation supported. In such a (apparently
hypothetical) case, I'd say NOTIMP would be correct.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 03 Apr 2002 17:37:50 -0500

> reasons".  That includes the policy "I only answer questions for which

Right, but is it a *policy* or a *capability*? In the hypothetical case of a
nameserver implementation which only serves authoritative zones and has no
provision for root hints, I think NOTIMP is even more appropriate than REFUSED.
REFUSED might mislead a resolver into thinking that the query might succeed if
it uses a different signing key, for example, or a different query source
address (if it has a choice of same) or changing some other attribute or
characteristic of the query transaction in order to placate the nameserver's
policy-based access controls. NOTIMP is more final/definitive.

I guess the antecedent question here is: do the standards *mandate* that
nameservers support root hints? I don't think they do (under a strict reading,
at least), nor do I think they *should*.

- Kevin

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 15:13:59 -0800

> and let the resolver fetch it somewhere else?

RD=1 means "i can't iterate so don't bother sending me a delegation or
anything else i would have to process and follow, i'm sending this one
question, and i'm going to act based on the one answer, and that's that."

---

From: Rob Austein <[email-masked]>
Date: Wed, 03 Apr 2002 18:30:04 -0500

> policy-based access controls. NOTIMP is more final/definitive.

That's plausable, iff we believe that everybody either groks NOTIMP or
will fail in some sane way without understanding NOTIMP.

> at least), nor do I think they *should*.

I'm pretty sure that there's explicit requirement that a name server
know anything at all beyond the (possibly empty) set of zones for
which it is authoritative, but I will confess that it's been a few
years since I had cause to read that part of the spec carefully.

Keep in mind that the "safety belt" information that's sometimes
incorrectly referred to as "root hints" is really just a list of IP
addresses of name servers for an iterative resolver to ask when it has
no better idea of where to send a query.  This is most commonly used
by an iterative resolver that's trying to find the root during what
BIND refers as the priming query, but the protocol allows queries to
complete without the resolver ever knowing where the root is, if the
resolver just happens by chance to ask the right name server (and
choses to believe the answer).

It's clear that the resolution process will never complete in the
general case unless -somebody- in the query path knows where the root
is, but the core protocol doesn't assume either that every name server
knows or that every resolver knows.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 4 Apr 2002 08:59:15 +0859 ()

Rob Austin;

> knows or that every resolver knows.

RFC 1034:

: 5.3.1. Stub resolvers
: 
: One option for implementing a resolver is to move the resolution
: function out of the local machine and into a name server which supports
: recursive queries.

RFC 1035:

: In either case,
: resolvers are replaced with stub resolvers which act as front ends to
: resolvers located in a recursive server in one or more name servers
: known to perform that service:
: 
:                    Local Hosts                     |  Foreign
:                                                    |
:     +---------+                                    |
:     |         | responses                          |
:     | Stub    |<--------------------+              |
:     | Resolver|                     |              |
:     |         |----------------+    |              |
:     +---------+ recursive      |    |              |
:                 queries        |    |              |
:                                V    |              |
:     +---------+ recursive     +----------+         |  +--------+
:     |         | queries       |          |queries  |  |        |
:     | Stub    |-------------->| Recursive|---------|->|Foreign |
:     | Resolver|               | Server   |         |  |  Name  |
:     |         |<--------------|          |<--------|--| Server |
:     +---------+ responses     |          |responses|  |        |
:                               +----------+         |  +--------+
:                               |  Central |         |
:                               |   cache  |         |
:                               +----------+         |

It's just a malconfiguration at the resolver side that it is not
surprising that there can be no proper behaviour at the server side.

							Masataka Ohta

---

From: Alexis Yushin <[email-masked]>
Date: Thu, 4 Apr 2002 04:34:11 +0200 (CEST)

>question, and i'm going to act based on the one answer, and that's that."

Alright, we've missed that one. I was ignoring RD at all, I'll fix it.

Alexis

---

From: Alexis Yushin <[email-masked]>
Date: Thu, 4 Apr 2002 04:35:45 +0200 (CEST)

>no better idea of where to send a query.  This is most commonly used

Worst case scenario is when RA=0 server has outdated .hints file.

Alexis

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Apr 2002 21:32:25 -0000

tinydns discards misdirected queries.

Mats Dufberg writes:
> According to my view, the best practice is to have a hint file, and
> return a referal to the root.

Root referrals are useless. Caches discard them. (Any cache that doesn't
is horribly broken.)

Maintaining the root addresses in a non-caching server is a waste of
administrative time. There's no reason that the server should know
anything about the roots.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "Jesper G. Hoy" <[email-masked]>
Date: Thu, 4 Apr 2002 09:28:40 -0500

D. J. Bernstein writes:
> Root referrals are useless. Caches discard them. (Any cache that
> doesn't is horribly broken.)
> Maintaining the root addresses in a non-caching server is a
> waste of administrative time. There's no reason that the server
> should know anything about the roots.

I second that!!

Further - why invent new logic (lines of code to execute) to provide an
error code for this situation ?

If a server cannot provide a referral (to root servers or otherwise),
that's not an error, just a fact.
IMHO the appropriate response from such a server would simply be empty -
no error code and no answer/referral (following the RFC1034 section
4.3.2 algorithm).

Jesper G. Hoy

---

From: [email-masked]
Date: Fri, 05 Apr 2002 07:42:17 +1000

> no error code and no answer/referral (following the RFC1034 section

	Do you really want to say that the name exist but there is no
	data to every query you are not authoritative for?  If you
	can't answer the query you do not give back bogus answers.

	As for Dan and tinydns not answering.  All that does is
	slow up everything creates additional unnecessary retransmissions
	and what for?  A 12 byte REFUSED/SERVFAIL error message.
	Error codes were created for a reason.  They should be used.
	
	As for the claim that a root referral is useless that is bogus.
	It allows the calling server to determine the the delegation
	is lame and to take appropriate action.

	Mark

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

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 5 Apr 2002 00:11:12 +0200 (CEST)

> error code for this situation ?

Because it makes life much easier if we get predictable responses that we
can interpret in some meaningful way. If we just get SERVFAIL or NOTIMP
we cannot draw the conclusion that the server does not have the zon.

Yes, a different status code would be simpler, but we are not there, so
let's keep thing transparent until a new status model is in place (the
status codes of DNS are unfortunately too overloaded).

Some people like me like to be able to analyse broken delegations and come
to some reasonable conclusion what is wrong. Knowing that the server is
not configured with the zone is a good start for communcating with
sometimes "broken" DNS administrators.

Mats

---

From: "Jesper G. Hoy" <[email-masked]>
Date: Thu, 4 Apr 2002 19:26:55 -0500

>	can't answer the query you do not give back bogus answers.

No - not at all!!
<name exists - but no data> would require a SOA-record in the Authority
section.
That's very different from what I was suggesting: an empty response
(nothing in the Answer, Authority and Additional sections).
If believe that RFC2308 (Negative caching...) goes into some detail on
this.

>	Error codes were created for a reason.  They should be used.

I agree that the server should respond.
Ignoring the query would probably result in multiple re-transmissions -
not desirable.

>	is lame and to take appropriate action.

The calling server should be able to determine the lame situation based
on the missing AA flag and no referral to closer servers.

Looking specifically for the root servers in the response to determine
this situation (lame) could even be dangerous - imagine some server
using an "alternate root server list" - like Pacific Root and the
like...

From a programming standpoint it makes sense to return the root server
list because it's the simple thing to do - same logic as any other cache
lookup.
I suspect this is the only reason why most implementations do it.

But I'm still with Dan on this point - I don't see how this response
(root server list) can be used for anything by the calling server.

Jesper G. Hoy

---

From: "Jesper G. Hoy" <[email-masked]>
Date: Thu, 4 Apr 2002 19:41:12 -0500

> we cannot draw the conclusion that the server does not have the zon.

I agree - SERVFAIL / NOTIMP are not the solutions for this.
We already have a well defined way to determine if a server has a zone -
the AA-flag in the response.

> sometimes "broken" DNS administrators.

DNS could certainly use more specific status codes.
However, for this particular scenario I think it's already pretty well
defined (AA-flag / missing closer referral) and unnecessary to invent
more...

Jesper G. Hoy

---

From: [email-masked]
Date: Fri, 05 Apr 2002 12:37:21 +1000

> <name exists - but no data> would require a SOA-record in the Authority

	Not it doesn't.  It requires a SOA to be cachable.  It
	doesn't require a SOA to be a valid answer.

> If believe that RFC2308 (Negative caching...) goes into some detail on

	Yes. I wrote RFC 2308.

> (root server list) can be used for anything by the calling server.

	I just told you how it is used.  Whether it is cached or not
	is another matter entirerly.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 12:43:17 +1000

> defined (AA-flag / missing closer referral) and unnecessary to invent

	No.  You either return a valid answer or a error indication.
	
	rcode=noerror, nscount=0 is not a valid answer

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 5 Apr 2002 12:07:41 +0859 ()

Mark;

> 	No.  You either return a valid answer or a error indication.

The other option is to silently igrore a query and return nothing.

							Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Thu, 04 Apr 2002 19:49:22 -0800

> The other option is to silently igrore a query and return nothing.

Which, as has been pointed out, is a bad idea as it triggers retransmission
and causes pointless waiting.

Rgds,
-drc

---

From: Rob Austein <[email-masked]>
Date: Thu, 04 Apr 2002 23:25:06 -0500

> rcode=noerror, nscount=0 is not a valid answer

I'm pretty sure that RFC 1035 permits

  QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0

To the best of my limited ability to remember the contents of 15 year
old packet dumps, this is exactly how the JEEVES nameserver program
responded when its resolver program was disabled and it received a
query for a QNAME that wasn't in any of the zones for which it had
authoritative data loaded.

Whether such a response would be -advisable- given what current
software might think it means is a separate question.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 14:47:27 +1000

Rob.  You lost the context when you quoted.

>   QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0

	Sure RFC 1035 permits it.  However if your a authoritative
	only server and the query is above all of the zone you are
	serving then you are returning a bogus answer.
 
> authoritative data loaded.

	I'd argue that JEEVES was broken if it returned that response.
	It shouldn't be making up answers about zones that it is not
	configured to serve.

	Mark

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Apr 2002 01:10:39 -0500

> Rob.  You lost the context when you quoted.

At least one of us is confused. :)

> Sure RFC 1035 permits it.  However if your a authoritative only
> server and the query is above all of the zone you are serving then
> you are returning a bogus answer.

I don't see in what way this is a bogus answer, and you didn't
elaborate, so I'll assume we're still talking about the topic named in
the subject line and the objection you raised several messages back:

> Do you really want to say that the name exist but there is no data
> to every query you are not authoritative for?  If you can't answer
> the query you do not give back bogus answers.

With AA=0 the name server isn't saying "the name QNAME is valid but no
such RRset exists", it's saying "I don't have any such RRset cached, I
am not entitled to an opinion as to whether such an RRset or such a
QNAME exists because I'm not authoritative, I have no suggestions on
where you should look next, and everything's fine, have a nice day."

With AA=1, this would be your RFC 2308 "TYPE 3 NODATA", but with AA=0
it's just "not my department".  Singularly unhelpful, but not bogus.

As I said, at least one of us is confused.  Please feel free to
demonstrate that it's me.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 17:10:07 +1000

> it's just "not my department".  Singularly unhelpful, but not bogus.

	NODATA is independent of AA.  It's the lack of referral and soa
	that makes the response a NODATA.

	If we had a NODATA rcode then you could interpret the response
	the way you want to.

---

From: Alan Barrett <[email-masked]>
Date: Fri, 5 Apr 2002 09:36:14 +0200

I think that when a server wants to say "I have no idea what the
answer is, and I refuse to even give you a referral to the root", it
should use RCODE=REFUSED.

However, if existing resolvers behave sanely upon receiving
<QR=RESPONSE AA=0 RA=0 RCODE=NOERROR ANCOUNT=0 NSCOUNT=0 ADCOUNT=0>
then blessing it as a way to say "I have no idea" might be
reasonable; perhaps even for the RA=1 case, where the server could
have given a referral to the roots, but might want to reduce the
packet size.

More comments below.

On Fri, 05 Apr 2002, Rob Austein wrote:
   [JEEVES answered like this when it meant "I have no idea":]
> the subject line and the objection you raised several messages back:

RCODE=NOERROR combined with ANCOUNT=0 means "The name exists but doesn't
have any RRs of the type you asked about".  It's a bogus answer because
the server has no basis for asserting that the name exists.

> such RRset exists", it's saying "I don't have any such RRset cached,
> I am not entitled to an opinion as to whether such an RRset or such a

No, with AA=0, it's saying, "I don't have any such RRset cached, I
am not authoritative for this name, but I nevertheless believe that
the QNAME exists (probably because I have other cached RRsets for the
same QNAME)".  Such a response without any NS records in the authority
section might be confusing to existing resolvers.

--apb (Alan Barrett)

---

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 10:30:42 +0200 (CEST)

>  QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0

In fact this answer means (according to the RFC's) something else: 
the name exists but there's no requested RR found. It is advisable
to include the SOA as well, but I believe it is still not required.

Alexis

---

From: bert hubert <[email-masked]>
Date: Fri, 5 Apr 2002 10:39:16 +0200

> have given a referral to the roots, but might want to reduce the

Before rushing off to what everybody 'thinks', please be so kind as to
determine how recursors react to your thoughts. They are not going to change
anytime soon [1].

You do not want to see hammering retransmits but you also don't want a
nameserver to declare you 'dead' or 'broken' and not sending other queries
to you!

The data we have indicate that the world is happy with:
<QR=RESPONSE AA=0 RA=0 RCODE=NOERROR ANCOUNT=0 NSCOUNT=0 ADCOUNT=0>

We've just switched TK. over to:
<QR=RESPONSE AA=0 RA=0 RCODE=SERVFAIL ANCOUNT=0 NSCOUNT=0 ADCOUNT=0>

And that also appears to go down well. I'm not going to try 'REFUSED'
though.

> the server has no basis for asserting that the name exists.

With AA=1 this is correct.

> section might be confusing to existing resolvers.

This is getting highly philosophical for what is a *technical* issue. It is
in fact not confusing existing resolvers, but I feel with Paul that SERVFAIL
is the right answer.

Perhaps this should be modulated by the RD flag.

Sending back pointers to rootservers for an RD=1 packet is, to say the
least, misguided, but might be right for RD=0. But even then I think it
complicates matters. 

Regards.

bert

[1] Interestingly on a busy authoritative server, we only see ~3000
different remote IP addresses over a time of 15 minutes. Will now measure
over 12 hours to see how many there are. I would hate to see that the ISP
world has consolidated so much that there are only a few thousand important
resolvers left!

---

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 11:21:46 +0200 (CEST)

>have given a referral to the roots, but might want to reduce the

I agree with the above and the rest of Alan's comments. Now it seems
that nobody really knows how the resolvers would react yet we need to
have a clear answer on what authorative only (non-recursive) nameserver
should (must) do when it doesnt know anything about the query it has
received. Current RFC's are not much of a help since apparently nobody
thought back then that there will be name servers who wont do any
recursion.

Ok, since we dont recurse, we cannot give referrals to the root
servers, which definitely would be the right thing to do for a
recursive server (and giving servfail if the priming query failed
or hints were not available). We cannot do that because such referral
would need to be updated every TTL time, in bandwith, with the TTLs
clicking down and the nameserver fetching and caching it every time
its time to do so. That would mean we'd need to implement caching/recursion
and we dont do it by definition.

So: no hints, no root referral, no SERVFAIL (I'll give more arguments
to no SERVFAIL below).

What we want to do is to answer the query with ``I cannot help you
on this, I dont have any suggestions either, and this is not a
temporary failure''.

Now lets see. Technically it is a NOTIMPL since we dont have recursion
implemented, but giving a NOTIMPL to a perferctly normal and otherwise
most likely very basic query is probably least thing a resolver software
engineer expects. This error code will probably fall under ``all other
funny error codes'' so I wouldnt expect a consise resolver behaviour
after that. It might go away maybe not. So my opinion is that NOTIMPL
is a bad idea.

If we give SERVFAIL, next to the arguement above, the resolver will be
encouraged to come back later thinking somebody might have fixed the
nameserver. So no SERVFAIL.

Dropping the query on the floor wont help much, we'll only get endless
retransmitions. Bad idea.

Giving an empty answer with AA bit either on or off according to my
understanding of the RFC's is plainly wrong. Even if it is my
misinterpritation the chance is rather big that somebody else
misinterpreted it in the same way or wasnt very carefull crosschecking
the AA bit and we'll give ``name is there, but now particular RR''
and that will break things down.

If you're with me this far, I hope we agree that we need to answer
such a query and we have to give a error code back.

Lets see what error codes we have left. This is definitely not a
Format Error. So we have Name Error and Refused.

Giving a Name Error with AA=0 is in fact equal (as bad) as
giving an empty answer with AA=0. In both cases we're saying
that we dont have this information and since we're not authorative for
it, but I'm afraid that both will equally lead the resolvers to
believe that the name either exists or doesnt exist. So I advocate
not to give a Name Error in combination with AA=0 :)

So unless we want to really quickly invent a new standard the
only error code we have left this far is Refused.

To refresh everybody's mind:

                5               Refused - The name server refuses to
                                perform the specified operation for
                                policy reasons.  For example, a name
                                server may not wish to provide the
                                information to the particular requester,
                                or a name server may not wish to perform
                                a particular operation (e.g., zone
                                transfer) for particular data.

We Refuse to do recursion (``a particular operation''). Whether it is
a ``policy reason'' is argueable. After all separating authorative
only server and caching forwarder in two independant servers is a sort
of a policy.

If we had a RD=1 in the query, we can RA=0 to make the answer more
meaningfull. Or we can even voluntarily set RD=1, RA=0 to indicate
the reason, but I guess it is not all that necessary, the result remains
the same, you're not getting an aswer from me on this, go away, who
cares why?

I agree it is not all that pretty (more things with DNS are lately not)
but that'll work and I think Refused is the only right way to do it.

Thanks to everybody who managed to read it all :)

Alexis

---

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 11:31:49 +0200 (CEST)

>nameserver to declare you 'dead' or 'broken' and not sending other queries

I agree, however a recursor should not have come to you with the stupid
query in first place. If the recursor got referred to you by your parent
(as it should be) it will ask you a questing you'd have an answer to.

If the recursor asked something silly first and got REFUSED, even though
you might get tagged as ``broken'' (why actually broken? rather unfriendly)
my best guess is that it will come talk to you again if it got referred
to you directly. And if not, well somebody else will do it for him.
(Hmm, is recursor really a him or a her, or could it be both? :)

>And that also appears to go down well. I'm not going to try 'REFUSED'

You might want to though (see my previous mail). It would give everybody
here a very valuable otherwise unattainable input!

Alexis

---

From: bert hubert <[email-masked]>
Date: Fri, 5 Apr 2002 11:40:08 +0200

> (as it should be) it will ask you a questing you'd have an answer to.

We mostly send out these packets for domains that have been delegated to us
but not yet entered in the database. So those queries aren't stupid. 

> here a very valuable otherwise unattainable input!

I'll see what happens but not on the TK. rootservers. 'Refused' might be
interpreted as 'I'm not talking to your IP address'. So who knows what might
happen.

The world is screaming for RCODE=NotAuth. I'll also try to measure how many
of our resolving clients proclaim EDNS0 compliance.

Regards,

bert

---

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 11:48:51 +0200 (CEST)

>but not yet entered in the database. So those queries aren't stupid. 

Ooooh, that's not the right way to things mister! The first thing I learned
about getting a domain name, was: set up the primary and secondary first,
then request delegation. Lateron, being delegator myself, the rule was,
check the primary & secondary first (mostly done by an automatic script
that process delegation requests) then delegate.

>interpreted as 'I'm not talking to your IP address'. So who knows what might

Well I am getting more and more convinced that Refused is the way to go. It
doesnt mean the IP is bad, it only means you dont want to do certain operation
for certain reasons. Think of REFUSED to AXFR, it has nothing to do with IP.

But I'm afraid I dont really have any new arguements, I'm repeating myself.

Alexis

---

From: bert hubert <[email-masked]>
Date: Fri, 5 Apr 2002 12:05:03 +0200

> that process delegation requests) then delegate.

Tell that to Verisign :-) We have no control over what people delegate to
us. See http://express.powerdns.com - it is a low cost dns hosting solution.

> But I'm afraid I dont really have any new arguements, I'm repeating myself.

I really don't care for the philosophical arguments. We want to send out an
answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely.

New PDNS behaviour:

$ host pietjepuk.nl ns-c.taloha.tk
pietjepuk.nl A record not found at ns-c.taloha.tk, server failure

Old:

$ host pietjepuk.nl dns-eu1.powerdns.net
pietjepuk.nl A record currently not present at dns-eu1.powerdns.net

With root referral: 

$ host pietjepuk.nl a.gtld-servers.net   
pietjepuk.nl A record currently not present at a.gtld-servers.net

DJBDNS 'I'm not answering you':
$ host pietjepuk.nl a.ns.yp.to
Nameserver a.ns.yp.to not responding
pietjepuk.nl A record not found at a.ns.yp.to, try again

UltraDNS 'Version 2.4.2 Build 131' also gives out a root referral.

I don't know of anybody running the microsoft nameserver.

DJBDNS is really acting silly in this respect - not answering to queries *at
all* means hammering. If I were to delegate a big domain to a.ns.yp.to he
would see huge amounts of traffic coming his way.

We've seen 500 packets/second for a nameserver normally receiving 10
packets/second in this case. See also:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-00.txt

Regards,

bert hubert

---

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 12:35:46 +0200 (CEST)

>answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely.

We're not talking philosophical arguement, we're talking adhering to the
standards. If you forgot why we do it, it is because we have no control or
say about existing or future resolver implementations, and the standards
are the guidlines and guarantee that if adhered to, there will be
interoperability.

The standards, not a New PDNS or BIND behaviour, that coninsidently happen
to do the trick.

>pietjepuk.nl A record currently not present at a.gtld-servers.net

The only thing the above illustrates is how certain implementation of
host(1) verbalizes different name server answers.

Alexis

---

From: bert hubert <[email-masked]>
Date: Fri, 5 Apr 2002 14:18:07 +0200

> are the guidlines and guarantee that if adhered to, there will be

RFC 1034/1035 are not a viable guideline. Actual practice diverges on many
places. Cf the SOA 'ttl_minimum' field. Or the AXFR protocol, which is not
even defined in 1034 & 1035! 

(see
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt)

The DNS rfcs simply are not as precise as, for example, the TCP/IP rfcs. 

So we argue over parts the RFCs gloss over, like what to do when not sending
out the optional root referral. This arguing should partly be 'in the
spirit' of the existing RFCs but as there is an important real world
installed userbase we should take care not to lose compatibility with it due
to the divine inspiration we get from reading Mockapetris et al.

Oh, fwiw, the microsoft nameserver implementation agrees with Paul and sends
out a SERVFAIL when not authoritative and not giving out a root referral.

Regards,

bert

---

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.

---

From: Rob Austein <[email-masked]>
Date: Fri, 05 Apr 2002 12:39:55 -0500

> that makes the response a NODATA.

My point is that RFC 1035 doesn't say that.  You're reading semantics
into that response form that simply aren't in RFC 1035.  SOAs in the
Authority section are optional in RFC 1035, and, the behavior of
certain widely deployed software notwithstanding, there is nothing in
RFC 1035 that requires a name server either to know where the root is
or to supply a referal if it doesn't know.

So I think you're telling me that RFC 2308 changes the semantics.  If
so, and if the WG agrees with that change, it should be made explicit.

---

From: [email-masked]
Date: Sat, 06 Apr 2002 12:43:28 +1000

> into that response form that simply aren't in RFC 1035.

	Explain how a recursive server is supposed to reconstruct a
	nodata response at the end of a cname chain when the
	authoritative server doesn't return a SOA in the authority
	section.

		aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=0 rcode=0

	and with SOA 

		aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=1 rcode=0

> SOAs in the

	SOA are optional.  But you can only tell the difference between
	a nodata response and a referral by looking at the authority
	section and interperting the contents there.

	If you don't know what the root servers are then you can't
	give a non-error answer.

---

From: Rob Austein <[email-masked]>
Date: Sat, 06 Apr 2002 14:25:22 -0500

> 		aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=1 rcode=0

Neither of which is the response form I was talking about, since
ANCOUNT is nonzero.

In the case you show here, one infers the absence of the desired RRset
by the presence of the CNAME RRs (which, I assume, are what
"ancount=1+" indicates) combined with RCODE=0, RA=1, RD=1, and the
absence of any RRs matching QTYPE at the end of the chain.

> 	SOA are optional.

At least we agree on something today. :)

>       But you can only tell the difference between a nodata response
>       and a referral by looking at the authority section and
>       interperting the contents there.

You might be able to convince me of that for responses with RD=1 and
RA=1, although I'm still skeptical as to the practical value of such a
distinction.  Responses with RD=1 and RA=1 don't ordinarily contain
referrals anyway, so why do you care?  But I digress.

I don't think your reasoning applies to responses with RA=0 or RD=0.
For the nonrecursive cases, you can get back an answer, a referral, an
error, or an empty RCODE=0 response indicating that you have asked a
server that has nothing useful to tell you about the question you
asked.  You keep claiming that the last case is "bogus", or an
"error", by which I assume you mean a protocol violation.  I disagree.

> 	If you don't know what the root servers are then you can't

Sorry, I still say that it's a legal response in the non-recursive
case.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Apr 2002 19:55:20 -0000

[ post by non-subscriber ]

bert hubert writes:
> DJBDNS is really acting silly in this respect - not answering to
> queries *at all* means hammering.

Get a grip. The Internet could save more bandwidth by leaving out the P
in each HTTP connection.

> If I were to delegate a big domain to a.ns.yp.to he

Try to think about this rationally. If you delegate a domain to my
servers without authorization, I could

   (1) return a root referral, which will reduce the traffic somewhat if
       all your other servers are lame, but which is more likely to have
       no effect, or

   (2) point the unauthorized domain to some offensive site and watch
       the traffic dwindle to nothing as you lose all your customers.

Do you seriously expect me to do #1 instead of #2?

---

From: bert hubert <[email-masked]>
Date: Sun, 7 Apr 2002 10:37:03 +0200

> Get a grip. The Internet could save more bandwidth by leaving out the P

Hammering is never good. Even if it 'only' means saving 500 packets/second.

>        all your other servers are lame, but which is more likely to have

You only have to return a SERVFAIL which will do the trick just fine. And
contrary to your opinion, our experiments indicate that it does have effect.
For our setups it saves a factor of *10* in traffic for a 5 minute 'no
answers' silence on all nameservers. We haven't had the option to measure
beyond that but I expect things to get worse.

Are there any reasons *not* to send a SERVFAIL? In other words, is there a
cost greater than getting hammered.

> Do you seriously expect me to do #1 instead of #2?

Why not program defensively? It's not that hard. Things get misdelegated by
mistake and it would be great if that could be handled gracefully where the
operator of djbdns would not be punished for that mistake.

But it's your nameserver. Dnscache really rocks.

Regards,

bert

---

From: Jim Reid <[email-masked]>
Date: Sun, 07 Apr 2002 05:28:59 -0700

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    >> DJBDNS is really acting silly in this respect - not answering
    >> to queries *at all* means hammering.

    djb> Get a grip. The Internet could save more bandwidth by leaving
    djb> out the P in each HTTP connection.

Perhaps. But think of the time people could save if they didn't have
hang about waiting for their name servers to time out while expecting
a from a response from your name server that isn't going to happen. And
then there's the second order effect of RTT smoothing by other name
servers. Since your server didn't respond, other servers will consider
it to be "unavailable" and won't query it as often as they could. By
saying nothing, your server is making a DoS attack against itself and
the zones it serves.

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 7 Apr 2002 23:23:13 +0200 (CEST)

> and we dont do it by definition.

I do not beleive that you save much load on the server by not keeping
updated information on the root servers.

> only server and caching forwarder in two independant servers is a sort

Technically it is maybe correct, but it makes Internet less transparent.
For an administrator is of great importance to be able to deduce from the
reply that the server has not been (or is no loger) configured with the
zone in question.

An non-recursive nameserver SHOULD reply with NOERROR, answer count=0 and
the root NS in authority section.

Mats

---

From: Paul Vixie <[email-masked]>
Date: Sun, 07 Apr 2002 18:02:24 -0700

> updated information on the root servers.

load, no.

operational complexity, yes.

> Technically it is maybe correct, but it makes Internet less transparent.

if you're asking me a question you should not be asking, then you deserve
an answer that will do you no good.

> reply that the server has not been (or is no loger) configured with the

that's an argument for REFUSED.  however, REFUSED just encourages retries,
so it actually hurts server load.  

> the root NS in authority section.

that's a very reasonable interpretation of rfc 1034, and also follows the
robustness principle.  however, this also means there are more servers who
have to know who the roots are, and therefore more opportunities for out-
of-date or just-plain-wrong data to be stored and transmitted.

most of the kashpureff-style delegation responses i've seen are actually
from innocent authority-only servers with bad root.cache files.

fundamentally though, asking a recursive question of a nonrecursive server
is wrong, and the server should choose a response which is best for it,
which in my case means discourages retries of the same query.  

if it's a nonrecursive query then it indicates lameness of a delegation,
and the response ought to be servfail.

---

From: Mats Dufberg <[email-masked]>
Date: Mon, 8 Apr 2002 09:08:34 +0200 (CEST)

> so it actually hurts server load.

The query could be non-recursive, but for a zone delegated to the server
in error, or by miss-management the zone has not been added to the server.
Or the server is a slave, and AXFR has fail or been refused. Or the server
is a master, and has failed loading the zone (rejected), or it is a slave
and the zone has expired.

I could have all reasons to ask for the data, even though it is not there.
And it would help the management to get a uniq answer for that situation.

Mats

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Apr 2002 22:19:06 +0859 ()

David;

> and causes pointless waiting.

That is a pointless evaluation.

The proper evaluation criteria is how quickly can we let an
administrator of a client fix wrong configuration.

							Masataka Ohta