[dns-operations] NXDOMAIN and negative caching

[Mark Andrews]

In message <56AFE88B.4050803 at lbl.gov>, Michael Smitasin writes:
> Just wanted to confirm my understanding:
> 
> - An NXDOMAIN / Name Error response indicates the domain name does not 
> exist, while a No Data response indicates the domain exists but no data 
> of the queried type exists. (Mostly looking at RFC 1035 Section 5.2.1)
> - An NXDOMAIN should be cached for a given QNAME, QCLASS. (RFC 2038 
> Section 5)
> 
> What I infer from that (perhaps it's explicitly stated elsewhere?) is 
> two things:
> 
> - An NXDOMAIN indicates /no/ records exist for that name.

Or for a child domain.

> - When an NXDOMAIN is cached, it will be returned for /any/ QTYPE 
> matching the same QNAME, QCLASS.
> 
> We have a situation where an authoritative server (outside our control) 
> is returning a good A record but when the same name is queried for an NS 
> record, it returns NXDOMAIN. Once our caching nameservers get that 
> NXDOMAIN, they start returning it to our client queries for the A 
> record. If my understanding of the above is true, our caching 
> nameservers are behaving correctly, but the authoritative server should 
> not be returning NXDOMAIN for that name? If so, is anyone familiar with 
> the circumstances where that would be the case or have recommendations I 
> can forward on to the operators of that authoritative server?
 
Load balancers that forward non A/AAAA queries to a backing nameserver
often exhibit this behaviour with the zone in the backing nameserver
that does not have A/AAAA records at the names being handled by the
load balancers.  The load balance and the backing nameserver need
to be configured consistently.

When load balancers only handled A records, AAAA records got NXDOMAIN
resposes and the following advisary was issued:

	  https://www.kb.cert.org/vuls/id/714121

Twelve years later we are still seeing these issues.  The load
balancer should be able to catch these errors.  It's only a matter
of querying the backing nameserver for the records it is configured
to answer for and confirming that you get a appropriate RRset
returned.

Mark

> Thanks,
> 
> -- 
> Michael Smitasin
> Network Engineer
> LBLnet Services Group
> Lawrence Berkeley National Laboratory
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org