Subject: Re: name server without root cache

From: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 11:48:51 +0200 (CEST)

Once bert hubert wrote:
>> I agree, however a recursor should not have come to you with the stupid
>> query in first place. If the recursor got referred to you by your parent
>> (as it should be) it will ask you a questing you'd have an answer to.
>
>We mostly send out these packets for domains that have been delegated to us
>but not yet entered in the database. So those queries aren't stupid. 

Ooooh, that's not the right way to things mister! The first thing I learned
about getting a domain name, was: set up the primary and secondary first,
then request delegation. Lateron, being delegator myself, the rule was,
check the primary & secondary first (mostly done by an automatic script
that process delegation requests) then delegate.

>> >And that also appears to go down well. I'm not going to try 'REFUSED'
>> >though.
>> 
>> You might want to though (see my previous mail). It would give everybody
>> here a very valuable otherwise unattainable input!
>
>I'll see what happens but not on the TK. rootservers. 'Refused' might be
>interpreted as 'I'm not talking to your IP address'. So who knows what might
>happen.

Well I am getting more and more convinced that Refused is the way to go. It
doesnt mean the IP is bad, it only means you dont want to do certain operation
for certain reasons. Think of REFUSED to AXFR, it has nothing to do with IP.

But I'm afraid I dont really have any new arguements, I'm repeating myself.

Alexis

--
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: Fri, 5 Apr 2002 12:05:03 +0200

> that process delegation requests) then delegate.

Tell that to Verisign :-) We have no control over what people delegate to
us. See http://express.powerdns.com - it is a low cost dns hosting solution.

> But I'm afraid I dont really have any new arguements, I'm repeating myself.

I really don't care for the philosophical arguments. We want to send out an
answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely.

New PDNS behaviour:

$ host pietjepuk.nl ns-c.taloha.tk
pietjepuk.nl A record not found at ns-c.taloha.tk, server failure

Old:

$ host pietjepuk.nl dns-eu1.powerdns.net
pietjepuk.nl A record currently not present at dns-eu1.powerdns.net

With root referral: 

$ host pietjepuk.nl a.gtld-servers.net   
pietjepuk.nl A record currently not present at a.gtld-servers.net

DJBDNS 'I'm not answering you':
$ host pietjepuk.nl a.ns.yp.to
Nameserver a.ns.yp.to not responding
pietjepuk.nl A record not found at a.ns.yp.to, try again

UltraDNS 'Version 2.4.2 Build 131' also gives out a root referral.

I don't know of anybody running the microsoft nameserver.

DJBDNS is really acting silly in this respect - not answering to queries *at
all* means hammering. If I were to delegate a big domain to a.ns.yp.to he
would see huge amounts of traffic coming his way.

We've seen 500 packets/second for a nameserver normally receiving 10
packets/second in this case. See also:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-00.txt

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: Alexis Yushin <[email-masked]>
Date: Fri, 5 Apr 2002 12:35:46 +0200 (CEST)

>answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely.

We're not talking philosophical arguement, we're talking adhering to the
standards. If you forgot why we do it, it is because we have no control or
say about existing or future resolver implementations, and the standards
are the guidlines and guarantee that if adhered to, there will be
interoperability.

The standards, not a New PDNS or BIND behaviour, that coninsidently happen
to do the trick.

>pietjepuk.nl A record currently not present at a.gtld-servers.net

The only thing the above illustrates is how certain implementation of
host(1) verbalizes different name server answers.

Alexis

---

From: bert hubert <[email-masked]>
Date: Fri, 5 Apr 2002 14:18:07 +0200

> are the guidlines and guarantee that if adhered to, there will be

RFC 1034/1035 are not a viable guideline. Actual practice diverges on many
places. Cf the SOA 'ttl_minimum' field. Or the AXFR protocol, which is not
even defined in 1034 & 1035! 

(see
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt)

The DNS rfcs simply are not as precise as, for example, the TCP/IP rfcs. 

So we argue over parts the RFCs gloss over, like what to do when not sending
out the optional root referral. This arguing should partly be 'in the
spirit' of the existing RFCs but as there is an important real world
installed userbase we should take care not to lose compatibility with it due
to the divine inspiration we get from reading Mockapetris et al.

Oh, fwiw, the microsoft nameserver implementation agrees with Paul and sends
out a SERVFAIL when not authoritative and not giving out a root referral.

Regards,

bert

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Apr 2002 19:55:20 -0000

[ post by non-subscriber ]

bert hubert writes:
> DJBDNS is really acting silly in this respect - not answering to
> queries *at all* means hammering.

Get a grip. The Internet could save more bandwidth by leaving out the P
in each HTTP connection.

> If I were to delegate a big domain to a.ns.yp.to he

Try to think about this rationally. If you delegate a domain to my
servers without authorization, I could

   (1) return a root referral, which will reduce the traffic somewhat if
       all your other servers are lame, but which is more likely to have
       no effect, or

   (2) point the unauthorized domain to some offensive site and watch
       the traffic dwindle to nothing as you lose all your customers.

Do you seriously expect me to do #1 instead of #2?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: bert hubert <[email-masked]>
Date: Sun, 7 Apr 2002 10:37:03 +0200

> Get a grip. The Internet could save more bandwidth by leaving out the P

Hammering is never good. Even if it 'only' means saving 500 packets/second.

>        all your other servers are lame, but which is more likely to have

You only have to return a SERVFAIL which will do the trick just fine. And
contrary to your opinion, our experiments indicate that it does have effect.
For our setups it saves a factor of *10* in traffic for a 5 minute 'no
answers' silence on all nameservers. We haven't had the option to measure
beyond that but I expect things to get worse.

Are there any reasons *not* to send a SERVFAIL? In other words, is there a
cost greater than getting hammered.

> Do you seriously expect me to do #1 instead of #2?

Why not program defensively? It's not that hard. Things get misdelegated by
mistake and it would be great if that could be handled gracefully where the
operator of djbdns would not be punished for that mistake.

But it's your nameserver. Dnscache really rocks.

Regards,

bert