Problem resolving domains with valid GLUE records but misconfigured NS records

[Kevin Darcy]

Well, the zone is publishing NS records that all return REFUSED when I 
query them, so from my point of view the whole domain is broken.

The *best* approach here is to contact the domain admin and get them to 
fix it.

In the absence of that, how to circumvent it? ns1.ecb.int apparently 
doesn't allow zone transfers of ecb.eu, so the only other thing that 
comes immediately to mind is to set up a "type forward" zone for ecb.eu, 
pointing to a *reliable* resolver of names in the domain (whether that 
be ns1.ecb.int, Google's DNS, or someone else). Be aware, however, that 
if there are descendant zones of ecb.eu, which aren't resolvable via 
recursive queries to your "reliable" forwarder, you may need to also 
define those descendant zones, on a case-by-case basis, explicitly in 
your config (as slave, stub, or forwarding somewhere else).

That workaround is ugly and fragile (i.e. very prone to unexpected 
breakage). It would be better to get the domain fixed.

                                                                         
                         - Kevin


On 3/16/2010 12:08 PM, Gilbert Cassar wrote:
> Hi,
>
> We have a recurring problem with recursive domain resolution using a 
> bind 9.6 caching server.  An example of such a zone is ecb.eu. The 
> problem seems due to a misconfiguration on their side where all the 
> (supposedly authorative) NS records listed in their zone file do not 
> answer requests to resolve ecb.eu hosts. This prevents us from 
> resolving anything under the domain after that the NS records are 
> cached (the first query goes through as the GLUE record seems to 
> work). The interesting thing is that it works fine if we try to 
> resolve the domain using either Windows DNS or using Google open DNS 
> service.
>
> Since a number of sites seem to have this type of problems we would 
> like to be able to resolve them as well. Any idea of how can we 
> configure to be able to circumvent this problem?
>
> Please find below some digs I did to diagnose the problem.
>
> Regards and Thanks
> Gilbert
> University of Malta
>
> ----
> Asking the EU servers
> root at wenzu:~/bind-9.7.0# dig ns ecb.eu @a.nic.eu
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58355
> ;; AUTHORITY SECTION:
> ecb.eu.            86400    IN    NS    ns1.ecb.int.
>
> Checking for the NS records ...
> root at wenzu:~/bind-9.7.0# dig ns ecb.eu @ns1.ecb.int.
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3891
> ;; ANSWER SECTION:
> ecb.eu.            86400    IN    NS    ns1.de.colt.net.
> ecb.eu.            86400    IN    NS    ns0.de.colt.net.
> ecb.eu.            86400    IN    NS    auth02.ns.de.uu.net.
> ecb.eu.            86400    IN    NS    auth52.ns.de.uu.net.
>
> Asking their NS Servers:
> root at wenzu:~/bind-9.7.0# dig ns ecb.eu @auth02.ns.de.uu.net
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27397
> ----
>
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>