Very long delays, is it just djbdns?

[Sabahattin Gucukoglu]

Try this command from a nice, clean dnscache:
host -v 2001:470:1f09:103e::2354

It took me three tries on my fastest, most well-connected machine to get the NXDOMAIN response. I haven't got to the bottom of it yet, but if anybody has a clue, please do share!

Cheers,
Sabahattin

[Chris Pugh]

On 13 November 2010 08:19, Sabahattin Gucukoglu

Post by Sabahattin Gucukoglu
host -v 2001:470:1f09:103e::2354

host -v ?? Don't you mean..

dnsqr any 2001:470:1f09:103e::2354

and/or it's equivalent?

Post by Sabahattin Gucukoglu
It took me three tries on my fastest, most well-connected machine to get the >NXDOMAIN response.  I haven't got to the bottom of it yet, but if anybody has a >clue, please do share!

No issue from here - an immediate response was received, e.g.

15 2001\072470\0721f09\072103e\072\0722354:
117 bytes, 1+0+1+0 records, response, nxdomain
query: 15 2001\072470\0721f09\072103e\072\0722354
authority: . 10708 SOA a.root-servers.net nstld.verisign-grs.com
2010111300 1800 900 604800 86400

( and that's from a very slow and essentially low spec machine ).

C.

[Sabahattin Gucukoglu]

Post by Chris Pugh
On 13 November 2010 08:19, Sabahattin Gucukoglu

Post by Sabahattin Gucukoglu
host -v 2001:470:1f09:103e::2354

host -v ?? Don't you mean..
dnsqr any 2001:470:1f09:103e::2354
and/or it's equivalent?

Nope, that would just query the root for the FQDN with that literal form. To use dnsqr it would be:
dnsqr ptr 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa

Post by Chris Pugh
It took me three tries on my fastest, most well-connected machine to get the >NXDOMAIN response. I haven't got to the bottom of it yet, but if anybody has a >clue, please do share!
No issue from here - an immediate response was received, e.g.
117 bytes, 1+0+1+0 records, response, nxdomain
query: 15 2001\072470\0721f09\072103e\072\0722354
authority: . 10708 SOA a.root-servers.net nstld.verisign-grs.com
2010111300 1800 900 604800 86400
( and that's from a very slow and essentially low spec machine ).

Yeah, please try the above.

I have taken a look at the dnscache logs for these queries, it finishes up with "drop input/output error" which means my queries are being dropped, but I can't get much more than that. Tracing the delegations up from the roots seem to work fine (except dnscache's "Lame" notation is a bit different from BIND, but that's okay).

As a side note, I do not consider the need for separate log-reading programs to be anything but the sign of a seriously disturbed mind. It's entirely possible to make machine-parseable logfiles without using the psychedelic notation Dan chose so they'd still be readable by less disturbed individuals. (OTOH: the use of separate programs for capturing and timestamping those logs is genius.)

Cheers,
Sabahattin

[Chris Pugh]

On 14 November 2010 10:46, Sabahattin Gucukoglu

Post by Sabahattin Gucukoglu
Nope, that would just query the root for the FQDN with that literal form.
dnsqr ptr 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa
..please try the above.

Gives..

12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa:
147 bytes, 1+0+1+0 records, response, nxdomain
query: 12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa
authority: 4.0.1.0.0.2.ip6.arpa 3588 SOA chia.arin.net
dns-ops.arin.net 2010111419 10800 3600 691200 3600

real 0m0.086s
user 0m0.001s

Post by Sabahattin Gucukoglu

Post by Chris Pugh
It took me three tries on my fastest, most well-connected machine to get the >NXDOMAIN response. I haven't got to the bottom of it yet, but if anybody has a >clue, please do share!

Several tries, again, quick response back wirth no delays.

I'd guess problem has to be local to you.

Post by Sabahattin Gucukoglu
As a side note, I do not consider the need for separate log-reading
programs to be anything but the sign of a seriously disturbed mind.

Personal opinion is personal opinion. Entirely your prerogative. DJB
always seems to be a 'do because he can' type of chap.

Post by Sabahattin Gucukoglu
 It's entirely possible to make machine-parseable logfiles without
using the psychedelic notation Dan chose so they'd still be readable
by less disturbed individuals.  (OTOH: the use of separate programs
for capturing and timestamping those logs is genius.)

Excessive log analysis is itself. much akin to list making, and could be
seen as slightly errant from the norm behaviour. Then again, a bit of
psychedlic now and again simply helps colour a rather drab world.. ;o)

Cheers,


Chris.

[richard lucassen]

On Sat, 13 Nov 2010 07:19:39 +0000

Post by Sabahattin Gucukoglu
host -v 2001:470:1f09:103e::2354
It took me three tries on my fastest, most well-connected machine to
get the NXDOMAIN response. I haven't got to the bottom of it yet,
but if anybody has a clue, please do share!

ipv6 is not mature yet I'd say. That's why I added:

.xaq.nl:127.0.0.1:localhost.xaq.nl:259200
.ip6.arpa::localhost.xaq.nl:259200
^*.ip6.arpa:ipv6.reverse.xaq.nl:7200

to my local tinydns on 127.0.0.1 and added:

echo 127.0.0.1 > /service/dnscache/root/servers/ip6.arpa

and reset your dnscache:

svc -t /service/dnscache

Ok, I get bogus responses, that's true, but I always get a response and
it only takes milliseconds ;)

(I run an ipv6 patched version of tinydns):

$ dnsip6 ipv6.google.com
2a00:1450:8003::63

$ dnsname 2a00:1450:8003::63
ipv6.reverse.xaq.nl

After a clear cache:

$ time dnsname 2a00:1450:8003::63
ipv6.reverse.xaq.nl

real 0m0.004s
user 0m0.000s
sys 0m0.000s

R.

R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Hauke Lampe]

Post by Sabahattin Gucukoglu
host -v 2001:470:1f09:103e::2354

Yes, it's slow for me, too.

It takes dnscache several queries and 25 seconds to return NXDOMAIN.
Unbound responds in 1.5 seconds, including DNSSEC validation and
"harden-referral-path" option.

Post by Sabahattin Gucukoglu
I haven't got to the bottom of it yet, but if anybody has a clue, please do share!

I think it has to do with dnscache resolving all glue before proceeding
to the next level. The log shows a lot of outgoing queries and several
"input/output errors" as well as "protocol errors".


Hauke.

[Daryl Tester]

(* Reply to /dev/null'd *)

Post by Hauke Lampe
I think it has to do with dnscache resolving all glue before proceeding
to the next level. The log shows a lot of outgoing queries and several
"input/output errors" as well as "protocol errors".

Initially I was getting fairly fast lookups, but flushing the cache then
running the query again shows the long lookup behaviour.

# svc -t /service/dnscache

# time dnsqr ptr 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa
12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa:
timed out

real 0m59.117s
user 0m0.000s
sys 0m0.000s

# time dnsqr ptr 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa
12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa:
90 bytes, 1+0+0+0 records, response, authoritative, nxdomain
query: 12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa

real 0m15.066s
user 0m0.000s
sys 0m0.000s

# time dnsqr ptr 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa
12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa:
90 bytes, 1+0+0+0 records, response, authoritative, nxdomain
query: 12 4.5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.e.3.0.1.9.0.f.1.7.7.4.0.1.0.0.2.ip6.arpa

real 0m0.001s
user 0m0.000s
sys 0m0.000s

[Sabahattin Gucukoglu]

Post by Hauke Lampe

Post by Sabahattin Gucukoglu
host -v 2001:470:1f09:103e::2354

Yes, it's slow for me, too.
It takes dnscache several queries and 25 seconds to return NXDOMAIN.
Unbound responds in 1.5 seconds, including DNSSEC validation and
"harden-referral-path" option.

Post by Sabahattin Gucukoglu
I haven't got to the bottom of it yet, but if anybody has a clue, please do share!

I think it has to do with dnscache resolving all glue before proceeding
to the next level. The log shows a lot of outgoing queries and several
"input/output errors" as well as "protocol errors".

Yes. As to why, it's odd, since by default dnscache trusts glue when available and doesn't go up to the authority servers. So, except for resolving the names in delegations, all of these queries seem to be overkill, and a bit counterintuitive. And it only needs one NS in each set, not every single one of them. Really not sure what's happening there ...

Unbound, there's the one half I might get into, not so much NSD, at least not yet.

Cheers,
Sabahattin