On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote:
On Wed, Jul 27, 2011 at 09:59:32AM +0200,
Danilo Godec<[email protected]> 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 178.79.70.66.53> 145.72.79.222.53: [udp sum ok]
7984 [1au] A? ns.rabobank.nl. 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 rabobank.nl, 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 'rabobank.nl'...
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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
