Couldn't resolve certain major sites

[Barry Margolin]

In article <ehqvvp$2thu$1 at sf1.isc.org>, MBernha at bart.gov wrote:

> We are running BIND 9.2.3 (yes, I know I need to upgrade, I'm working on
> it). Yesterday we had a problem in which suddenly after 2 years of
> flawless operation, we could no longer resolve Google, Yahoo and Microsoft
> queries. After about 3 hours, Yahoo was resolvable but the others were
> not. Other sites were fine, though "slow." Although it is possible that
> our problems were due to faulty router hardware, I need to go through this
> question first, so please bear with me. I looked through the archives but
> found no directly usable information.
> 
> I reconfigured our DNS servers to forward-only to our ISP's servers, and
> everything worked. I looked at our configuration and we have been set up
> so that we were using source port 53 for queries. I removed that, removed
> the forward-only, and everything worked normally. I also had to push a new
> access list to our outside routers to make this work, hence the doubt
> about router hardware (the only change was to allow source port 53 to
> high-numbered ports on our DNS servers). Our firewall policy, inside those
> routers, did not change.
> 
> Doing a packet trace, I saw that requests to Microsoft simply were not
> answered. The packet trace lined up with the firewall log in that the
> firewall was not dropping any queries or replies that came its way. I did
> notice a single ICMP administrative-prohibited if I restarted BIND and
> queried again.

Did you happen to save the source address of this?  This will tell you 
the router that has the problematic filter, which may help you determine 
where along the path the blocking is occurring.

> 
> My questions:
> 1. Do these site suddenly now require BIND default behavior i.e.
> high-numbered source port? Is it now considered unacceptable to source
> from port 53?

There are many sites that block UDP packets with low-numbered source 
ports, for some reason.  However, I'm very surprised that major sites 
like Google, Yahoo, and Microsoft do.

> 2. What is BIND's behavior when this message is received? 

I suspect it ignores it.

> 3. With Google in particular, we found that we could resolve "google.com"
> but not "www.google.com." I never even saw the query hit the sniffer,
> presumable because DNS had already cached a negative response. Using dig
> would turn up SERVFAIL. Any idea on this?

www.google.com is an alias for www.<letter>.google.com, and the servers 
for the <letter>.google.com subdomains are different from the servers 
for google.com (this is part of a geographic load balancing system).  So 
it sounds like your packets are being blocked to the subdomain servers, 
but not the parent domain servers.

> 4. After I began allowing named to use high-numbered source ports, dig
> commands such as +trace began working on all domains- they didn't work on
> any previously. Is there a good reason for this?

It's not the change in named that did this, it's your firewall change.  
Dig uses a high-numbered source port by default, and your firewall was 
previously blocking these.

> 5. Do you think the problem described were related to BIND at all or
> should I be focusing on other causes?

As I said above, I'm very suspicious of the claim that these major sites 
are blocking this traffic.  I think it was happening somewhere else 
along the way, and it might be useful to figure out where it is.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***