While debugging a mail delivery problem, I've encountered the following behavior that was surprising to me, and I wanted to check my understanding.
If I query this on my own recursive nameservers (that uses BIND 9.16.50-1~deb11u1): $ dig mx.l3harris.com <http://mx.l3harris.com/> A ... I get back a valid A record, with "status: NOERROR" and "ANSWER: 1". So far, so good. If I then query the same label with a TXT type: $ dig mx.l3harris.com <http://mx.l3harris.com/> TXT ... I get back a "status: NXDOMAIN" response. That's fine, but if I then repeat the first query: $ dig mx.l3harris.com <http://mx.l3harris.com/> A ... it no longer works. I get a "status: NXDOMAIN" response until the negative cache result from the TXT lookup expires. I don't think this is just my server, because I'm able to reproduce this at some public recursive DNS servers, like 134.195.4.2: $ dig mx.l3harris.com A @134.195.4.2 | grep -o -E '(status|ANSWER): \S+' status: NOERROR, ANSWER: 1, $ dig mx.l3harris.com TXT @134.195.4.2 | grep -o -E '(status|ANSWER): \S+' status: NXDOMAIN, ANSWER: 0, $ dig mx.l3harris.com A @134.195.4.2 | grep -o -E '(status|ANSWER): \S+' status: NXDOMAIN, ANSWER: 0, Am I correct that it's wrong for an authoritative DNS server to return NXDOMAIN for a TXT query in the case where an A query for the same label would be successful? If so, why do some recursive servers cache that result, and others don't? And finally, does anyone know of a reputable-seeming public tool I can use to show the administrator of this zone that there's a problem? -- Robert L Mathews
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
