Yes. The two servers are in separate logical /29s in our 10.x network but both physically route through the same devices and get NATted to the 12.44.84.21x addresses shown below. So far as I know there is nothing in the query that would let target servers know about our internal network - that is to say I would expect any location aware routines to be based on those 12.44.84.21x addresses.
I spoke with our chief network engineer and he confirmed this. Is there a DNS command that I could run from the servers themselves that would tell me what IP is being seen when it sends a query? Interestingly, this morning, both servers ARE reporting the same range of IPs for news.google.com even though we didn't make any changes. (The range for both master and slave is now the one I indicated below for slave yesterday.) I suspect this was something odd happening on Google's NS servers rather than our own. -----Original Message----- From: Warren Kumari [mailto:war...@kumari.net] Sent: Tuesday, May 24, 2011 6:12 PM To: Lightner, Jeff Cc: bind-users@lists.isc.org Subject: Re: Getting different name resolution for news.google.com from master and slave BIND And are those definitely the source addresses that the queries are coming from (e.g you don't have multiple interfaces / tunnels? you are not forwarding, etc?) W On May 24, 2011, at 4:33 PM, Lightner, Jeff wrote: > They aren't in different subnets from an internet perspective and are > not geographically separated. (Yes I know not best practice but I > don't make those decisions.) > > The master is dswadns1.water.com at 12.44.84.213 and the slave is > dswadns2.water.com at 12.44.84.214. > > The fact they are not in different locations or in a separate subnet is > why I don't understand why I'd be getting separate "location specific" > IPs handed to the two servers. > > -----Original Message----- > From: Warren Kumari [mailto:war...@kumari.net] > Sent: Tuesday, May 24, 2011 4:06 PM > To: Lightner, Jeff > Cc: bind-users@lists.isc.org > Subject: Re: Getting different name resolution for news.google.com from > master and slave BIND > > > On May 24, 2011, at 2:28 PM, Lightner, Jeff wrote: > >> Is anyone else seeing odd results with news.google.com? My BIND 9 > master and slave are getting different results. > > > Presumably your slave and master are in different subnets? > > Google (and many other large networks) perform geolocation and hand out > A records that a "close" to your resolver. Presumably we believe that > 72.14.209.99 is (network wise) close to your master and 74.125.65.99 is > close to your slave. > > If you provide IPs and actual locations for your slaves and master I can > check.... > > W > > >> If I go out to other sites such as Kloth.net or iptools.com they also > get different results from each other and different from what my master > and slave are reporting. >> >> I'm running BIND 9.3 (The RedHat version that has backported patches > and enhancements from later BIND versions in it so please don't tell me > to use a newer version.) >> >> On doing some research I found that Google has made a couple of > changes in the past week or so affecting their news stuff. The one > that seems like it might explain why Kloth.net, iptools.com and my > server get different answers is the May 13th introduction of "news near > you" discussed in this article: >> http://www.pcmag.com/article2/0,2817,2385369,00.asp >> >> That is aimed at mobile devices but I could see how they might also > try to make it work with static sites. However it wouldn't explain why > both my servers coming from the same location would get different > results. I'm thinking maybe there is something else obvious I'm > missing. >> >> I am not caching on these servers and have bounced named on both but > it didn't help. >> >> Does anyone have any ideas? Other than the fact that they're master > and slave with different IPs and setup to talk to each other the > named.conf on both hosts is the same. They both have the same OS and > same hardware. Also we have some Windows DNS servers in house and they > seem to be giving the same results as my slave so the master appears to > be the odd man out. >> >> When I run "dig news.google.com" from my BIND 9 master I'm getting: >> ; <<>> DiG 9.3.4-P1 <<>> news.google.com >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46508 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 2 >> >> ;; QUESTION SECTION: >> ;news.google.com. IN A >> >> ;; ANSWER SECTION: >> news.google.com. 603615 IN CNAME news.l.google.com. >> news.l.google.com. 300 IN A 72.14.209.99 >> news.l.google.com. 300 IN A 72.14.209.104 >> >> ;; AUTHORITY SECTION: >> google.com. 170523 IN NS ns1.google.com. >> google.com. 170523 IN NS ns2.google.com. >> google.com. 170523 IN NS ns3.google.com. >> google.com. 170523 IN NS ns4.google.com. >> >> ;; ADDITIONAL SECTION: >> ns3.google.com. 344424 IN A 216.239.36.10 >> ns4.google.com. 343339 IN A 216.239.38.10 >> >> ;; Query time: 6 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Tue May 24 14:17:14 2011 >> ;; MSG SIZE rcvd: 190 >> >> Yet on my slave I get: >> ; <<>> DiG 9.3.4-P1 <<>> news.google.com >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30872 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;news.google.com. IN A >> >> ;; ANSWER SECTION: >> news.google.com. 603986 IN CNAME news.l.google.com. >> news.l.google.com. 300 IN A 74.125.65.99 >> news.l.google.com. 300 IN A 74.125.65.103 >> news.l.google.com. 300 IN A 74.125.65.104 >> news.l.google.com. 300 IN A 74.125.65.105 >> news.l.google.com. 300 IN A 74.125.65.106 >> news.l.google.com. 300 IN A 74.125.65.147 >> >> ;; AUTHORITY SECTION: >> google.com. 171986 IN NS ns4.google.com. >> google.com. 171986 IN NS ns1.google.com. >> google.com. 171986 IN NS ns2.google.com. >> google.com. 171986 IN NS ns3.google.com. >> >> ;; Query time: 5 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Tue May 24 14:18:03 2011 >> ;; MSG SIZE rcvd: 222 >> >> >> Proud partner. Susan G. Komen for the Cure. >> >> Please consider our environment before printing this e-mail or > attachments. >> ---------------------------------- >> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or > confidential information and is for the sole use of the intended > recipient(s). If you are not the intended recipient, any disclosure, > copying, distribution, or use of the contents of this information is > prohibited and may be unlawful. If you have received this electronic > transmission in error, please reply immediately to the sender that you > have received the message in error, and delete it. Thank you. >> ---------------------------------- >> _______________________________________________ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
