odbc.ucas.com lookup problem

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?

On 20/07/10 15:10, Chris Thompson wrote:
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.

On Tue, 20 Jul 2010, Chris Thompson wrote:
Could it be complaining about the lack of compression?
Tony.

This is a multi-part message in MIME format.
This is a multi-part message in MIME format.
No problems here.
It does look a bit odd that the timeout is 0 actually on all accesses it
is 0
~~~~~~~~~~~~~~~~~~~~~~~~~
silver3:~ carlsen$ dig odbc.ucas.com
; DiG 9.6.0-APPLE-P2 odbc.ucas.com
;; global options: +cmd
;; Got answer:
;; -
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"





No problems here.

It does look a bit odd that the timeout is 0 actually on all
accesses it is 0

~~~~~~~~~~~~~~~~~~~~~~~~~
silver3:~ carlsen$ dig odbc.ucas.com

; <<>> DiG 9.6.0-APPLE-P2 <<>> odbc.ucas.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
11175
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;odbc.ucas.com.            IN    A

;; ANSWER SECTION:
odbc.ucas.com.        0    IN    A    62.189.0.245

;; AUTHORITY SECTION:
odbc.ucas.com.        3600    IN    NS    ns-lp.ucas.com.

;; Query time: 681 msec
;; SERVER: 192.168.16.32#53(192.168.16.32)
;; WHEN: Tue Jul 20 18:13:49 2010
;; MSG SIZE  rcvd: 67
~~~~~~~~~~~~~~~~~~~~~~~~

Timing is ok from this place with the latencies I have.




However, I haven't yet been able to work out exactly *what* is wrong
with the response, as demonstrated by dig (say). Any ideas?


Could it be complaining about the lack of compression?
Tony.


Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"

On 7/20/2010 11:15 AM, Phil Mayers wrote:
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

On Tue, 20 Jul 2010, Chris Thompson wrote:
Got it. The nameservers for ucas.com give a referral for odbc.ucas.com.
That means the zone for odbc.ucas.com is odbc.ucas.com. However the
nameservers for odbc.ucas.com give ucas.com as the SOA in their negative
replies. When BIND is checking the format of a NODATA response, it ignores
SOA and NS RR sets in the authority section that are not subdomains of the
query's zone. The result is it gets a negative response in a format that
doesn't match the cases in RFC 2308. The "invalid response" log message is
specific to format errors in negative responses.
; DiG 9.7.1-P2 aaaa odbc.ucas.com. @ns0.netcentral.co.uk.
;; global options: +cmd
;; Got answer:
;; ->>HEADERHEADER

On Tue, 20 Jul 2010, Kevin Darcy wrote:
No, the load balancers are simply braindamaged. Try SOA or NS or TXT
queries and you get a timeout.
Tony.

On 7/20/2010 1:41 PM, Tony Finch wrote:
The contents of the ucas.com SOA record they return in their negative
reply doesn't match up with what the authoritative servers return, so
it's anyone's guess where that's coming from I was trying to give them the benefit of the doubt as to a
misconfiguration of their devices, but I'm starting to agree with you
that this is simply YABLI (Yet Another Braindamaged Load-balancer
Implementation).
Timing out on non-A/non-AAAA queries is of course reprehensible, but
what's even worse is the sending of spurious NXDOMAINs in response to
"unexpected" QTYPEs, under certain configurations of a particular make
of load-balancer. That's a DoS waiting to happen. Fortunately the vendor
in question there recognizes the problem and is working on a fix for it.
- Kevin

In message , Chris Tho
mpson writes:
The load balance is incorrectly configured to serve ucas.com rather
than the zone delegated to it odbc.ucas.com. i.e. the SOA record
at the end should be for odbc.ucas.com not ucas.com.
Mark
ucas.com. 172800 IN NS ns0.netcentral.co.uk.
ucas.com. 172800 IN NS ns1.netcentral.co.uk.
;; Received 83 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 446 ms
odbc.ucas.com. 3600 IN NS ns-lp.ucas.com.
;; Received 115 bytes from 212.57.232.5#53(ns0.netcentral.co.uk) in 667 ms
ucas.com. 86400 IN SOA ucas.com. administrator.ucas.com. 998545544 28800 7200 604800 86400
;; Received 105 bytes from 195.188.99.250#53(ns-lp.ucas.com) in 327 ms