odbc.ucas.com lookup problem

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