On 7/20/2010 11:15 AM, Phil Mayers wrote:
On 20/07/10 15:10, Chris Thompson wrote:
We're having some local reports about delays resolving odbc.ucas.com.
The problem is undoubtedly the response of "ns-lp.ucas.com", which
seems to be some sort of load balancer, to AAAA queries. I get log
entries from BIND like
Jul 20 14:35:12 koala.csi.cam.ac.uk named[4539]: [ID 873579
daemon.notice]
DNS format error from 194.80.160.250#53 resolving odbc.ucas.com/AAAA
for client 127.0.0.1#42869: invalid response
However, I haven't yet been able to work out exactly *what* is wrong
with the response, as demonstrated by dig (say). Any ideas?
FWIW we can't resolve it either. My colleague says that UCAS have
broken their DNS in the past as well, though possibly not in the same
way.
An odbc.ucas.com/AAAA query gets a NODATA response containing the SOA
for ucas.com. I think BIND is rejecting that because it earlier followed
a more-specific delegation of odbc.ucas.com to the load-balancers. This
response is an "upwards referral", in other words, which constitutes a
form of delegated-server "lameness".
It seems that UCAS is just proxying non-A queries from its
load-balancers back to its regular nameservers. That doesn't work too
well, since they're not authoritative for the relevant zone
(odbc.ucas.com) and *cannot* be, otherwise they would answer
odbc.ucas.com queries directly and that would defeat the whole
load-balancing scheme. In order to get the proper NXDOMAIN/NODATA
responses, the load-balancers would need to proxy non-A queries to a
special "shadow" version of the odbc.ucas.com zone, either hosted on
different nameservers, on the same nameservers as those for ucas.com,
but in a different view, or some combination of the two approaches.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
