Subject: Re: name server without root cache

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

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

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

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