[dns-operations] why does that domain resolve?

[Mark Delany]

On 07Jun21, Giovane C. M. Moura via dns-operations allegedly wrote:

> FWIW, we did a study a couple of years ago [1] analyzing these
> inconsistencies. We found 13 million second-level domains (out of 166M)
> that were inconsistent [0] (table 1, data from 2019-10-16)

Asking for a friend. Did you use a tool that is generally available to the average Joe
such that they can test their own domains?

The most common DNS support questions I get from small-time dns admins invariably revolve
around discrepancies between delegation, name servers and hidden masters.

I use a home-grown command-line tool which sorta, kinda works, but it's rough. For
example, here's what it says about apple.com:

apple.com. Errors: 12
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:c.ns.apple.com./204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:c.ns.apple.com./204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:d.ns.apple.com./204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:d.ns.apple.com./204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:b.ns.apple.com./17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:b.ns.apple.com./17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name Server:a.ns.apple.com./17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name Server:a.ns.apple.com./17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./192.5.6.30

Which is a lot of verbosity to say the glue from a.gtld-servers.net (and presumably all
other GTLD servers) lacks the ipv6 addresses for a.ns.apple.com and b.ns.apple.com yet
they're present in the in-bailiwick name servers.

This of course is a minor matter rather than a fault, but it does mean that the ipv6 name
servers will get a vastly reduced set of queries compared to all other name servers. To my
mind this is indicative of an oversight on the domain admin's front.

I'll really like to upgrade to a clearer command-line tool which can be incorporated into
a zone update work-flow so that my friends can immediately know when they have messed
up.

Does such a beast exist?


Mark.