gmane.network.djbdns

Re: General amusement (nothing to do with TBP DHP nameservice or dead Wikileaks.org)

Chris Pugh — 2010-12-03T16:22:27

O>Sean Doran:

On 3 December 2010 08:41, Richard J. Sexton <richard< at >vrx.net> wrote:

Neither of which takes into account RFC 793 (
http://tools.ietf.org/html/rfc793 ),..

General amusement (nothing to do with TBP DHP nameservice or dead Wikileaks.org)

Richard J. Sexton — 2010-12-03T07:41:09

--
Richard J. Sexton  rich4< at >rd.vrx.net  +1 (206) 333-1798 skype: rsx11s
http://rs79.vrx.net http://mbz.org http://killi.net http://aquaria.net

Re: Very long delays, is it just djbdns?

Sabahattin Gucukoglu — 2010-11-15T13:24:46

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

Re: Very long delays, is it just djbdns?

Daryl Tester — 2010-11-15T11:27:42

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

On 15/11/10 21:40, Hauke Lampe wrote:


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

Re: Very long delays, is it just djbdns?

Hauke Lampe — 2010-11-15T11:10:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 13.11.2010 08:19, Sabahattin Gucukoglu wrote:


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.


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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzhFS0ACgkQKIgAG9lfHFNLBgCePcxF85Vs/tgFjGvYt1D82+Zu
Yz8AoINTeVaAqmCdzhOe4XI7+XC2x+7k
=OcQD
-----END PGP SIGNATURE-----

Re: Very long delays, is it just djbdns?

Chris Pugh — 2010-11-15T08:14:54

On 14 November 2010 10:46, Sabahattin Gucukoglu
<mail< at >sabahattin-gucukoglu.com> wrote:

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

real0m0.086s
user0m0.001s


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

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


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


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.

Re: Very long delays, is it just djbdns?

richard lucassen — 2010-11-14T13:39:36

On Sat, 13 Nov 2010 07:19:39 +0000
Sabahattin Gucukoglu <mail< at >sabahattin-gucukoglu.com> wrote:


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.

Re: Very long delays, is it just djbdns?

Sabahattin Gucukoglu — 2010-11-14T09:46:40

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


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

Re: Very long delays, is it just djbdns?

Chris Pugh — 2010-11-13T19:56:53

On 13 November 2010 08:19, Sabahattin Gucukoglu
<mail< at >sabahattin-gucukoglu.com> wrote:

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

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

and/or it's equivalent?


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.

Very long delays, is it just djbdns?

Sabahattin Gucukoglu — 2010-11-13T07:19:39

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

Re: IPv6 readiness and tinydns.

Dean Anderson — 2010-11-02T21:12:40


Hmm:

[dean< at >citation2 dean]$ dig +noall +answer any ns1.google.com
ns1.google.com.         345600  IN      A       216.239.32.10
[dean< at >citation2 dean]$ dig +noall +answer any ns2.google.com
ns2.google.com.         345437  IN      A       216.239.34.10
[dean< at >citation2 dean]$ dig +noall +answer any ns3.google.com
ns3.google.com.         345600  IN      A       216.239.36.10
[dean< at >citation2 dean]$ dig +noall +answer any ns4.google.com
ns4.google.com.         345600  IN      A       216.239.38.10
[dean< at >citation2 dean]$ dig +noall +answer any www.google.com
www.google.com.         496777  IN      CNAME   www.l.google.com.
[dean< at >citation2 dean]$ dig +noall +answer any www.l.google.com
www.l.google.com.       300     IN      A       72.14.204.99
www.l.google.com.       300     IN      A       72.14.204.103
www.l.google.com.       300     IN      A       72.14.204.104
www.l.google.com.       300     IN      A       72.14.204.147

It's not time yet. But from the FAQ: 

  We enable Google over IPv6 on request for networks where IPv6 access 
  will provide the same or better quality of experience of Google 
  services as IPv4. 

  Our measurements show that enabling Google over IPv6 can result in a 
  small percentage of users experiencing problems or delays accessing 
  Google services. In many cases, we have found this to be due to user 
  network issues such as misconfiguration or equipment that does not 
  properly support IPv6. 

That percentage isn't really that small. Its large enough that they only
turn it on, on request. You might want to consider this before spending
a lot of time on IPV6:

http://www.ietf.org/mail-archive/web/tls/current/msg07143.html

And this message was sent to list, hasn't shown up in archives yet:

====================================================
Date: Mon, 01 Nov 2010 17:57:26 +1300
From: Peter Gutmann <pgut001< at >cs.auckland.ac.nz>
To: dean< at >av8.com, Jeff.Hodges< at >KingsMountain.com
Cc: tls< at >ietf.org
Subject: Re: [TLS] Server Name Indication (SNI) in an IPv6 world?

Dean Anderson <dean< at >av8.com> writes:


This sounded sufficiently controversial that I had to try it:

Google "ipv6" -> 11m hits.
Google "ipv6"+"disable" -> 0.9m hits.
Google "ipv6"+"turn off" -> 1.8m hits.

So roughly 10-20% of references to IPv6 are on how to disable it.  Wow.

Peter.
====================================================




On Tue, 2 Nov 2010, Russell Sutherland wrote:

Re: IPv6 readiness and tinydns.

Sabahattin Gucukoglu — 2010-11-02T22:38:46

This is fixed by the Fefe.de patch, which honours IPv6 glue just as IPv4 very nicely.

The only thing that patch doesn't seem to do is recurse over IPv6 in dnscache.

Cheers,
Sabahattin

Re: IPv6 readiness and tinydns.

Colm MacCárthaigh — 2010-11-02T19:45:23

Even when you do this, without modification TinyDNS does not append AAAA
records to the additional section (as per RFC3596 section 3) for MX, NS or
SRV targets (although A records suffer from this too for SRV).

Another thing to keep in mind if you plan to use stock TinyDNS to serve AAAA
records is that their order will not be randomised in rrsets containing more
than one AAAA record. This shouldn't matter - but in practice some resolvers
don't randomise their processing.

2010/11/2 Maciej Żenczykowski <zenczykowski< at >gmail.com>

Re: IPv6 readiness and tinydns.

Richard J. Sexton — 2010-11-02T19:36:32

:s/Google/Paypal/g
--
Richard J. Sexton  rich4< at >rd.vrx.net  +1 (206) 333-1798 skype: rsx11s
http://rs79.vrx.net http://mbz.org http://killi.net http://aquaria.net

Re: Wildcards not supported in & records?

Paul Jarc — 2010-11-02T18:29:28

It will work if 2.1.in-addr.arpa, or some larger superdomain, is
delegated to you.  If 3.2.1.in-addr.arpa is the domain that is
delegated to you, then that won't work, but you could tell your parent
to delegate that domain to your customer's servers instead of your
own.


paul

Re: Wildcards not supported in & records?

Harm van Tilborg — 2010-11-02T17:59:06

Hi David,

On 2-11-2010 18:12, David Hubbard wrote:

If you are in control of the entire 1.2.3.0/24, this should be enough to
set the delegation for the /24 to your preferred name servers:

&3.2.1.in-addr.arpa:1.2.3.4:ns1.customerdns.com:3600
&3.2.1.in-addr.arpa:3.4.5.32:ns2.customerdns.com:3600
&3.2.1.in-addr.arpa:3.4.5.31:ns1.customerdns.net:3600
&3.2.1.in-addr.arpa:1.2.3.254:ns2.customerdns.net:3600

This also implies your netblock owner (RIPE, ARIN, APNIC, or any
intermediary) must set these four name servers for that specific reverse
DNS zone.

Re: Wildcards not supported in & records?

Maciej Żenczykowski — 2010-11-02T17:50:08

if you're going to delegata *, why not delegate one level higher and
not have to do that?

On Tue, Nov 2, 2010 at 10:12, David Hubbard
<dhubbard< at >dino.hostasaurus.com> wrote:

Re: IPv6 readiness and tinydns.

Maciej Żenczykowski — 2010-11-02T17:54:34

Strictly speaking, you don't ever need IPv6 addresses in MX or NS records.
They don't actually reference any IP, they reference a hostname, with
an optional ip.
This results in a MX/NS record being generated (mapping domain to
hostname), and optionally an A record to map that hostname to an IP.

As such if you're like me and never pass in an IP in the MX or NS
record, then you're already good to go.

Basically split your MX/NS records into MX/NS records and A records,
and then add AAAA records.  Or even without splitting just add AAAA
records.

[ie. all you are losing is not particularly useful syntactic sugar]

On Tue, Nov 2, 2010 at 08:34, Russell Sutherland
<russell.sutherland< at >utoronto.ca> wrote:

RE: Wildcards not supported in & records?

David Hubbard — 2010-11-02T17:54:05

From: Maciej Żenczykowski [mailto:zenczykowski< at >gmail.com] 

Oh, can I do that?  Just &3.2.1 and send the whole thing over
to him?  I was not clear on if that would work or not.

David

Wildcards not supported in & records?

David Hubbard — 2010-11-02T17:12:52

Was trying to delegate the first of several /24's worth
of in-addr.arpa records to a customer's name servers,
some of which are present on said /24 and some not, so
I did the following (first three octets and the domain
name changed obviously):

&*.3.2.1.in-addr.arpa:1.2.3.4:ns1.customerdns.com:3600
&*.3.2.1.in-addr.arpa:3.4.5.32:ns2.customerdns.com:3600
&*.3.2.1.in-addr.arpa:3.4.5.31:ns1.customerdns.net:3600
&*.3.2.1.in-addr.arpa:1.2.3.254:ns2.customerdns.net:3600

Did not get successful ptr lookups after putting that in
place, just get an SOA response from our dns showing our
dns.  I changed the records to test just one IP:

&50.3.2.1.in-addr.arpa:1.2.3.4:ns1.customerdns.com:3600
&50.3.2.1.in-addr.arpa:3.4.5.32:ns2.customerdns.com:3600
&50.3.2.1.in-addr.arpa:3.4.5.31:ns1.customerdns.net:3600
&50.3.2.1.in-addr.arpa:1.2.3.254:ns2.customerdns.net:3600

Now it's happy.  Querying for 50.3.2.1.in-addr.arpa on
my tinydns gives back four NS authority records of the
customer's DNS servers.  If I do a straight root lookup
of that ptr I get proper traversal to customer's dns and
a correct response.

So, I can of course write a little script to generate
the thousand or so lines of records I'll need, but was
hoping I could get away with four like you can with A
records?

Thanks,

David

IPv6 readiness and tinydns.

Russell Sutherland — 2010-11-02T15:34:06

I am attempting to prepare our infrastructure here to be IPv6 ready.
Part of that is DNS. For several years we have used the fefe.de patch to
serve up AAAA records for several sub-domains. In the documentation it
states explicitly that:

    .... tinydns-edit won't accept IPv6 addresses for NS or MX records yet

So my short question is, can one use a patched version of tinydns to fulling
support an IPv6 environment?

<snip>
On 2008-01-12 Russ Nelson wrote:

   "When Google has an AAAA record, we can talk about adding IPv6 support."

I think we are ready to start talking:

   http://www.google.com/intl/en/ipv6/faq.html
</snip>