[dns-operations] Is NXDOMAIN wrong when a record of the same label but different type exists?

[Robert L Mathews]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20240805/293d06f5/attachment.html>