not resolving from some places?

Karl Auer kauer at
Mon Jul 30 02:01:23 UTC 2007

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, a
CNAME pointing at is served by and Further investigation showed
that was mostly broken as far as our users were concerned,
with answers for the domain coming only from a secondary,
And since was broken, so too was, 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}, 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                   +61-2-64957160 (h)                  +61-428-957160 (mob)

More information about the bind-users mailing list