Dan stop assuming things about BIND 9's behaviour based on
BIND 8's behaviour. We have said many times that there
are architectual flaws in BIND 8. BIND 9 was written from
scratch to get around those problems. The server in question
is running BIND 9.1.
The elasped time also includes retries due to EDNS probes.
drugs# ps ax | grep named
150 ?? Ss 0:00.77 /usr/local/sbin/named
719 p0 S+ 0:00.00 grep named
drugs# kill 150
drugs# /usr/local/sbin/named
drugs# dig www.monty.de
; <<>> DiG 8.3 <<>> www.monty.de
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; www.monty.de, type = A, class = IN
;; ANSWER SECTION:
www.monty.de. 1D IN CNAME monty.de.
monty.de. 1D IN A 151.189.12.194
;; AUTHORITY SECTION:
monty.de. 1D IN NS ns2.norplex.net.
monty.de. 1D IN NS ns.norplex.net.
;; ADDITIONAL SECTION:
ns.norplex.net. 23h59m58s IN A 151.189.12.193
ns2.norplex.net. 23h59m58s IN A 151.189.26.234
;; Total query time: 6887 msec
;; FROM: drugs.dv.isc.org to SERVER: default -- 127.0.0.1
;; WHEN: Fri Jan 26 00:36:21 2001
;; MSG SIZE sent: 30 rcvd: 138
drugs#
Now with A6 and DNSSEC stub resolvers are being pushed as
both potentialy require a deal of work to be performed
before a answer is returned. A full service resolver
is much better suited to dealing with A6 and DNSSEC.
With A6 you *can* follow all the address delegations but
you don't *have* to. Personally I expect sites to be too
paraniod to have chains that go outside their administrative
control and you will, likely as not, get the full chain
returned.
Mark
> Here's what the bind-users report said about www.monty.de: ``I recently
> had to explain to customers that no it's not our fault that our name
> servers can't resolve that name. And by the way, no it doesn't work on
> the second try or the third.''
>
> C'mon, everybody, try it! Ask your cache for the www.monty.de address.
> I tried several BIND caches; they all failed. I've already explained in
> detail how much work dnscache has to go through to find the address.
>
> Elz seems to understand that the www.monty.de disaster is a powerful
> argument against the relevant aspects of the DNS design. So now he's
> denying the facts. He wants you to believe that www.monty.de is okay.
>
> Robert Elz writes:
> > ;; Total query time: 1850 msec
>
> That's nice. Try again from an empty cache.
>
> > Note that the answer had the AA bit set - it didn't just appear out
> > of some local cache.
>
> Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net.
> What you had in your cache was the addresses of those servers.
>
> > so to find that A record, all that could have been needed (in practice)
> > was just 2 round trips...
>
> Don't be an idiot. In practice, most caches don't have the *.norplex.net
> addresses lying around when they are asked about www.monty.de.
>
> ---Dan
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
