not resolving from some places?

[Karl Auer]

Some days ago I posted this query.

The answer is interesting (maybe not new to some) so I thought I'd post
it too. The person sending this answer did so off-list, so it has been
sanitised and anonymised here.

On Wed, 2007-07-25 at 23:37 +1000, Karl Auer wrote:
> This name resolves from outside our organisation, but not from within
> our organisation. It also resolves via our organisation's nameservers
> when the query comes from outside.
> [...]

The name people were having trouble with was www.atosresearch.eu, a
CNAME pointing at arroyito.atosorigin.es. atosresearch.eu is served by
n1.atosorigin.es and ns2.atosorigin.es. Further investigation showed
that atosorigin.es was mostly broken as far as our users were concerned,
with answers for the domain coming only from a secondary, ineco.nic.es.
And since atosorigin.es was broken, so too was atosresearch.eu, of
course - but it didn't have the secondary to save it one time in three.

This was the answer I received:

> Something is broken at AtosOrigin. If EDNS0 is used to
> query ns{1,2}.atosorigin.es, the queries time out. They get
> no response. This is wrong. If EDNS0 is not used, all is well.
>
> By default, BIND9 uses EDNS0 and falls back to 1035-style queries
> if it gets a reply which says the remote server doesn't understand
> EDNS0. Since your name server doesn't get any response to its
> queries, it assumes the AtosOrigin name servers are dead => SERVFAIL.
>
> Presumably there's some sort of firewall that's blocking EDNS0
> queries. BTW, this problem will be affecting everyone who uses BIND9
> to lookup [these] domain names, not just you.
>
> You can use a server{} statement to switch off EDNS0 queries to these
> servers.

I had been testing with dig. Dig does not use EDNS0 unless you use the
"+bufsize=XXX" option, so dig was NOT doing the same thing as my
nameservers! That's what was mystifying me, how come a dig to the
problem nameservers involved worked, but resolving via my own
nameservers did not.

The workaround suggested did the trick; I added server{} statements to
prevent my nameservers using EDNS0 with the blocked nameservers. I also
contacted the admins for those nameservers. They didn't believe they had
a problem - because dig worked just fine :-) Eventually, by showing them
a dig with EDNS0 and a dig without EDNS0, I convinced them that they did
have a problem, and I think it's fixed now.

The moral of the story: If weirdness seems to be happening, use dig with
the "+bufsize" option ("+bufsize=500" is pretty safe) to explicitly use
EDNS0, because that's what your BIND9 nameservers are doing!

And: From OUTSIDE your network, try a few EDNS0 queries to your own
nameservers. Common or garden dig queries (without +bufsize) won't tell
you if you have a badly configured firewall turning away legitimate
queries from other nameservers.

My heartfelt thanks to [you know who you are] for your help.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)