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<har...@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.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
