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: David Conrad <[email-masked]>
Date: Thu, 04 Apr 2002 19:49:22 -0800

On 4/4/02 7:08 PM, "Masataka Ohta" <[email-masked]> wrote:
>> No.  You either return a valid answer or a error indication.
> 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: 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: 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)

On Apr 5, 2002, 11:21 (+0200) Alexis Yushin <[email-masked]> wrote:

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

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

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

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

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

---

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