Problem resolving one particular domain

Danilo Godec danilo.godec at
Wed Jul 27 10:37:27 UTC 2011

On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote:
> On Wed, Jul 27, 2011 at 09:59:32AM +0200,
>   Danilo Godec<danilo.godec at>  wrote
>   a message of 247 lines which said:
>> Weirdness number 2 - using dig directly with their servers works:
> Nothing weird here: dig does not behave like the BIND resolver. It
> does not use EDNS at all by default, it does not use the same source
> port, etc.

Yes, I was expecting that - I just used it as a way of checking whether 
it's a network/firewall problem (being blocked or something).

>>> 09:53:23.643138> [udp sum ok]
>>> 7984 [1au] A? ar: . OPT UDPsize=512 (43) (ttl 63,
>>> id 5640, len 71)
> There is one weird thing here: your resolver uses always the same
> source port, 53:
> 1) It means you are vulnerable to Kaminsky-style cache poisoning. In
> 2011, 'query-source port 53;' should have disappeared a long time
> ago. Source ports must be random.
> 2) It may create problems with some firewalls (this would not explain
> why, on the same servers, work).

Thank you, that's what it was. Removed the 'query-source port 53' and 
resolving started working.

It is still very weird why it worked with ''...

> A second weird thing is the use of EDNS with a buffer size of
> 512. This is completely useless, since default size is already 512
> (but it is probably not the cause of the problem since all answers
> from Rabobank are short).

In the process of trying to figure out the problemI was fiddling with 
the 'edns-udp-size' option setting it to 512.

I guess I still had that in when I was doing the copy&paste - have since 
removed it and the packets sent out now have 'OPT UDPsize=4096'.

Thanks again, Danilo

More information about the bind-users mailing list