Subject: Re: name server without root cache

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

Rob.  You lost the context when you quoted.

> At Fri, 05 Apr 2002 12:43:17 +1000, Mark Andrews wrote:
> > 
> > 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

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

	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.
 
> Whether such a response would be -advisable- given what current
> software might think it means is a separate question.

	Mark
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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

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