[dns-operations] Fun with DNAME and DNSSEC
dot at dotat.at
Wed Jan 29 15:15:02 UTC 2014
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 22.214.171.124, 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".
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.
More information about the dns-operations