[dns-operations] Name servers returning incorrectly truncated UDP responses

[Robert Edmonds]

Ondřej Surý wrote:
> I am 99% sure the fpdns is wrong and this is not djbdns. The fpdns relies on
> subtle differences between various DNS implementations and is often wrong
> because there’s either not enough data or just not enough differences. That’s
> what I’ve seen when we started with Knot DNS - the quality implementations just
> didn’t had enough differences between than because they adhered to standards
> that fpdns just could not tell the difference.

If you run fpdns with "-d" it will print out the queries/responses, and
fpdns does observe some stereotypical (but maybe not exclusively?)
djbdns behavior like dropping queries that aren't for domains the server
is configured to be authoritative for.

"a.ns", "b.ns" etc. is a nameserver-naming pattern used in the tinydns
documentation.

For the djbdns suite, tinydns only serves UDP traffic and you have to
install an extra daemon called axfrdns to handle TCP queries and AXFR
traffic. If you request an AXFR for a zone that axfrdns is authoritative
for but your source IP isn't on its allowlist, axfrdns _exit()'s without
sending anything, which is consistent with:

    $ dig +tries=1 +tcp +norec @e.ns.email.sonyentertainmentnetwork.com -t AXFR email.sonyentertainmentnetwork.com
    ;; communications error to 207.251.96.133#53: end of file

Regarding the truncation behavior, the djbdns documentation states:
"dnscache ends the packet before all records." It doesn't say how
tinydns behaves but it looks like the code is the same. The answer count
in the header is not updated, which seems to be what is upsetting the
various message parsers. According to the CHANGES file:

    20000210
            internal: response_tc() reduces len, simplifying udprespond().
            ui: response_tc() now truncates immediately after query. this
                    should work around the Squid parsing bug reported by
                    Stuart Henderson.

So I'm inclined to think they probably actually are using djbdns, or
maybe a load balancer in front of djbdns. At least I don't see anything
inconsistent with this being a djbdns deployment.

You are right about high quality implementations not having enough
subtle idiosyncratic differences to reliably distinguish between them,
though.

-- 
Robert Edmonds