Bind9 Random Whois and Dig Fails

[Sri Harsha Yalamanchili]

The query-source address is nat'ed address inside the firewall. We opted 
for that to make our firewall less porous but may be we should re-visit 
that strategy.

The forwarder actually works. That was the primary/only DNS server we 
were using until we decided to install our own internal dns and delegate 
non-internal DNSqueries to that particular forwarder - 66.7.224.17.

Yes we will try to debug Whois and DNS separately. But were just curious 
about the strange behavior that seems to be connected to us changing the 
DNS servers.

As for logging bind queries, here's a line in our named.conf.log that 
does the logging:

    category queries { query_log; };

Not much luck using tcpdump either. We know, from both the query_log and 
tcpdump logging, that the queries are going out. But we never get a 
reply back. That's the confusing part. The Google DNS server replies 
back but not our own ISP's DNS. It times out multiple times before 
replying once if at all.

Thank you,
--
Harsha

On 6/7/11 7:57 AM, Stephane Bortzmeyer wrote:
> On Fri, Jun 03, 2011 at 03:09:13PM -0700,
>   Sri Harsha Yalamanchili<harsha at thought-matrix.com>  wrote
>   a message of 145 lines which said:
>
>>           o query-source address X.X.X.X port 53;
> That's typically a very bad idea because it makes the source port
> predictable and therefore makes you much more vulnerable to the
> Kaminsky vulnerability.
>
>>                  forwarders {
>>                      66.7.224.17; //Telepacific's DNS server
>>                  };
> Did you try this forwarder with, for instance, dig? Does it really
> work?
>
>>     * The whois lookup works as long as we're telepacific's dns
>>       server.
> I don't really understand the sentence but, anyway, remember that
> whois and DNS are two different and unrelated protocols. I suggest to
> debug them separately.
>
>> We can clearly see that the queries are going out from the query
>> log.
> BIND logs the outgoing queries? I didn't know. Anyway, I suggest using
> tcpdump to see what is really going in and out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110607/a6b64149/attachment.html>