Subject: Re: name server without root cache

From: [email-masked]
Date: Fri, 05 Apr 2002 07:42:17 +1000

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

	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.

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

	Mark

> 
> 
> Jesper G. Hoy
>  
> 
> 
> 
> 
> --
> 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: Mats Dufberg <[email-masked]>
Date: Fri, 5 Apr 2002 00:11:12 +0200 (CEST)

> error code for this situation ?

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.

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.

Mats

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