[dns-operations] why does that domain resolve?

[Warren Kumari]

On Tue, Jun 8, 2021 at 6:03 AM Mark Delany <b9w at charlie.emu.st> wrote:

> 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.
>

Related to this, does anyone have a list of good web based "DNS checkers"?
I *feel* like there used to be a number of good tools, but I managed to
throw away that set of bookmarks. There are still many "test your recursive
servers <here>" pages, but I'm looking for something that tests
authoratives, and walks all possible paths, checks for v4 and v6, MTU, etc.

At the moment the main site that I'm recommending for this is IIS.SEs
Zonemaster - https://zonemaster.iis.se/ and DNSViz.

Zonemaster is really close, but I'd like a few other options as well.
DNSViz is, of course, excellent for DNSSEC debugging, but it can be fairly
confusing to less experienced people trying to debug non-DNSSEC issues.

So, what are people's favorite tools, especially those that you can just
point a user at?

W



>
> 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.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210611/9c82980f/attachment.html>