odbc.ucas.com lookup problem
Kevin Darcy
kcd at chrysler.com
Tue Jul 20 17:29:06 UTC 2010
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
More information about the bind-users
mailing list