Subject: Re: name server without root cache

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

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

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.

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

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