Subject: RE: name server without root cache

From: Simon Higgs <[email-masked]>
Date: Mon, 29 Apr 2002 17:54:46 -0700

Jesper G. Hoy wrote:

Wrong thread for this but...

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

Cross-root pollution is becoming common place. There are enough resolvers 
out there looking for obscure names to make a dent now.

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

What happens to a query when two separate root systems are returned - i.e. 
ns1.foo returns one root system and ns2.foo returns something else? Would 
the local cache (if any) take precedence or do both roots subsequently get 
queried?

Best Regards,

Simon

--
###

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

Once Paul Vixie wrote:
>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.

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

Alexis

---

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: 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: 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: "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: "Jesper G. Hoy" <[email-masked]>
Date: Thu, 4 Apr 2002 19:26:55 -0500

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

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.

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

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

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

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

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

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

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.

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

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.

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