[dns-operations] Fun with DNAME and DNSSEC

[Tony Finch]

Casey Deccio <casey at deccio.net> wrote:
>
> DNSViz should now work too--no longer "discombobulated" :), but still slow
> (needs a performance facelift).  It was actually handling DNAME properly;
> it just wasn't querying for PTR outside of arpa, so it wasn't following the
> synthesized CNAME.

Looks good, thanks!

Well, mostly. It's complaining about being unable to get the
in-addr.arpa.cam.ac.uk DNSKEY RRset from 129.169.8.8, which I thought my
colleagues fixed yesterday - it works when I try the query from a couple
of off-campus locations.

> Note that there are two "bubbles" for CNAME because one server provided a
> different TTL (0) than the others (86400), the former following RFC 2672,
> and the latter following updated TTL guidelines in RFC 6672.  Curiously,
> for the server returning the 0 TTL, the corresponding IPv6 address (i.e.,
> by the same name) returns the 86400 TTL.

This is ns.ripe.net which appears to be load-balancing across multiple
name server implementations, on IPv4 and IPv6 - that is, the difference
you saw was due to the load balancing not the different IP version. I can
see three distinct behaviours when I repeat the following queries:

$ dig +nsid @ns.ripe.net. 252.252.232.128.in-addr.arpa. in ptr
$ dig +nsid @ns.ripe.net. version.bind. ch txt

ns1.ams.authdns.ripe.net returns a CNAME with a full TTL and an empty
authority section. It is running "9.9.4-P2".

ns2.ams.authdns.ripe.net returns a CNAME with a zero TTL and a SOA in the
authority section. It is running "Knot DNS 1.4.2".

ns3.ams.authdns.ripe.net returns a CNAME with a zero TTL and an empty
authority section. It is running "NSD 4.0.1".

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.