[dns-operations] NXDOMAIN and negative caching

Mark Andrews marka at isc.org
Tue Feb 2 00:39:09 UTC 2016

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:


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


> 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

More information about the dns-operations mailing list