date:20160601

different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

Hi all,

We have 3 recursive resolvers on the same subnet, and one of them is
getting different answers for the same things from google's
authoritative dns servers.

[root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
ns3.google.com. ns4.google.com."
[root@syz3ns01 ~]# SITES="www.google.com. www.google.gr."
[root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
@${resolver})" ; done ; done
ns1.google.com. www.google.com. 216.58.211.4
ns1.google.com. www.google.gr. 216.58.211.3
ns2.google.com. www.google.com. 216.58.211.4
ns2.google.com. www.google.gr. 216.58.211.3
ns3.google.com. www.google.com. 216.58.211.4
ns3.google.com. www.google.gr. 216.58.211.3
ns4.google.com. www.google.com. 216.58.211.4
ns4.google.com. www.google.gr. 216.58.211.3

[root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
ns3.google.com. ns4.google.com."
[root@syz3ns02 ~]# SITES="www.google.com. www.google.gr."
[root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
@${resolver})" ; done ; done
ns1.google.com. www.google.com. 216.58.211.36
ns1.google.com. www.google.gr. 216.58.211.35
ns2.google.com. www.google.com. 216.58.211.36
ns2.google.com. www.google.gr. 216.58.211.35
ns3.google.com. www.google.com. 216.58.211.36
ns3.google.com. www.google.gr. 216.58.211.35
ns4.google.com. www.google.com. 216.58.211.36
ns4.google.com. www.google.gr. 216.58.211.35

[root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
ns3.google.com. ns4.google.com."
[root@syz3ns03 ~]# SITES="www.google.com. www.google.gr."
[root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
@${resolver})" ; done ; done
ns1.google.com. www.google.com. 172.217.16.36
ns1.google.com. www.google.gr. 172.217.16.35
ns2.google.com. www.google.com. 172.217.16.36
ns2.google.com. www.google.gr. 172.217.16.35
ns3.google.com. www.google.com. 172.217.16.36
ns3.google.com. www.google.gr. 172.217.16.35
ns4.google.com. www.google.com. 172.217.16.36
ns4.google.com. www.google.gr. 172.217.16.35

The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and
84.205.252.20 respectively.

The problem with the third answer set is on the users' browsers, it
produces an ssl certificate error and users cannot access google.

traceroute to google's dns servers are different on the penultimate hop
(hop 12)

[root@syz3ns01 ~]# traceroute ns3.google.com.
traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets
 1  syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1)  0.405 ms  0.262
ms  0.217 ms
 2  84.205.252.6 (84.205.252.6)  0.718 ms  0.504 ms  0.511 ms
 3  193.92.42.169 (193.92.42.169)  0.937 ms  1.024 ms  0.482 ms
 4  194.219.208.29 (194.219.208.29)  1.017 ms  1.004 ms  0.946 ms
 MPLS Label=757472 CoS=5 TTL=1 S=0
 5  xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193)  0.950 ms  1.063
ms  0.982 ms
 6  74.125.48.74 (74.125.48.74)  8.373 ms  8.374 ms  8.341 ms
 7  72.14.237.27 (72.14.237.27)  8.352 ms 72.14.237.189 (72.14.237.189)
12.085 ms 72.14.237.27 (72.14.237.27)  8.979 ms
 8  209.85.253.114 (209.85.253.114)  26.920 ms  26.114 ms  25.789 ms
 MPLS Label=772454 CoS=5 TTL=1 S=0
 9  216.239.58.8 (216.239.58.8)  50.816 ms 209.85.241.233
(209.85.241.233)  42.159 ms  43.461 ms
 MPLS Label=756878 CoS=5 TTL=1 S=0
10  209.85.251.178 (209.85.251.178)  45.549 ms  44.474 ms  45.682 ms
 MPLS Label=720256 CoS=5 TTL=1 S=0
11  74.125.37.103 (74.125.37.103)  39.998 ms 216.239.49.244
(216.239.49.244)  48.116 ms 74.125.37.150 (74.125.37.150)  42.865 ms
 MPLS Label=25186 CoS=5 TTL=1 S=0
12  209.85.251.231 (209.85.251.231)  39.575 ms 72.14.238.43
(72.14.238.43)  43.933 ms 209.85.242.165 (209.85.242.165)  46.748 ms
13  * *Icmp checksum is wrong
 *
14  ns3.google.com (216.239.36.10)  41.453 ms  39.987 ms  47.545 ms
[root@syz3ns01 ~]#

[root@syz3ns02 ~]# traceroute ns3.google.com.
traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets
 1  syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1)  0.232 ms  0.283
ms  0.209 ms
 2  84.205.252.6 (84.205.252.6)  0.688 ms  0.535 ms  0.455 ms
 3  193.92.42.169 (193.92.42.169)  1.715 ms  0.835 ms  0.726 ms
 4  194.219.208.29 (194.219.208.29)  1.248 ms  0.876 ms  0.773 ms
 MPLS Label=757472 CoS=5 TTL=1 S=0
 5  xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193)  0.755 ms  1.047
ms  0.944 ms
 6  74.125.48.74 (74.125.48.74)  8.331 ms  8.546 ms  8.328 ms
 7  72.14.237.189 (72.14.237.189)  12.286 ms 72.14.237.27 (72.14.237.27)
 5.935 ms 72.14.237.189 (72.14.237.189)  13.211 ms
 8  209.85.253.114 (209.85.253.114)  22.488 ms 209.85.240.160
(209.85.240.160)  25.713 ms  26.401 ms
 MPLS Label=554255 CoS=5 TTL=1 S=0
 9  216.239.57.244 (216.239.57.244)  41.070 ms 209.85.241.233
(209.85.241.233)  34.822 ms 209.85.242.79 (209.85.242.79)  38.180 ms
 MPLS Label=27780 CoS=5 TTL=1 S=0
10  209.85.251

Re: different answers from google's authoritative servers

2016-06-01 Thread Kevin Kretz

Sotiris, 

There could be multiple A records for load balancing. 

From: "Sotiris Tsimbonis"  
To: bind-us...@isc.org 
Sent: Wednesday, June 1, 2016 7:34:00 AM 
Subject: different answers from google's authoritative servers 

Hi all, 

We have 3 recursive resolvers on the same subnet, and one of them is 
getting different answers for the same things from google's 
authoritative dns servers. 

[root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
ns3.google.com. ns4.google.com." 
[root@syz3ns01 ~]# SITES="www.google.com. www.google.gr." 
[root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in 
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
@${resolver})" ; done ; done 
ns1.google.com. www.google.com. 216.58.211.4 
ns1.google.com. www.google.gr. 216.58.211.3 
ns2.google.com. www.google.com. 216.58.211.4 
ns2.google.com. www.google.gr. 216.58.211.3 
ns3.google.com. www.google.com. 216.58.211.4 
ns3.google.com. www.google.gr. 216.58.211.3 
ns4.google.com. www.google.com. 216.58.211.4 
ns4.google.com. www.google.gr. 216.58.211.3 

[root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
ns3.google.com. ns4.google.com." 
[root@syz3ns02 ~]# SITES="www.google.com. www.google.gr." 
[root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in 
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
@${resolver})" ; done ; done 
ns1.google.com. www.google.com. 216.58.211.36 
ns1.google.com. www.google.gr. 216.58.211.35 
ns2.google.com. www.google.com. 216.58.211.36 
ns2.google.com. www.google.gr. 216.58.211.35 
ns3.google.com. www.google.com. 216.58.211.36 
ns3.google.com. www.google.gr. 216.58.211.35 
ns4.google.com. www.google.com. 216.58.211.36 
ns4.google.com. www.google.gr. 216.58.211.35 

[root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
ns3.google.com. ns4.google.com." 
[root@syz3ns03 ~]# SITES="www.google.com. www.google.gr." 
[root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in 
${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
@${resolver})" ; done ; done 
ns1.google.com. www.google.com. 172.217.16.36 
ns1.google.com. www.google.gr. 172.217.16.35 
ns2.google.com. www.google.com. 172.217.16.36 
ns2.google.com. www.google.gr. 172.217.16.35 
ns3.google.com. www.google.com. 172.217.16.36 
ns3.google.com. www.google.gr. 172.217.16.35 
ns4.google.com. www.google.com. 172.217.16.36 
ns4.google.com. www.google.gr. 172.217.16.35 

The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and 
84.205.252.20 respectively. 

The problem with the third answer set is on the users' browsers, it 
produces an ssl certificate error and users cannot access google. 

traceroute to google's dns servers are different on the penultimate hop 
(hop 12) 

[root@syz3ns01 ~]# traceroute ns3.google.com. 
traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets 
1 syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1) 0.405 ms 0.262 
ms 0.217 ms 
2 84.205.252.6 (84.205.252.6) 0.718 ms 0.504 ms 0.511 ms 
3 193.92.42.169 (193.92.42.169) 0.937 ms 1.024 ms 0.482 ms 
4 194.219.208.29 (194.219.208.29) 1.017 ms 1.004 ms 0.946 ms 
MPLS Label=757472 CoS=5 TTL=1 S=0 
5 xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193) 0.950 ms 1.063 
ms 0.982 ms 
6 74.125.48.74 (74.125.48.74) 8.373 ms 8.374 ms 8.341 ms 
7 72.14.237.27 (72.14.237.27) 8.352 ms 72.14.237.189 (72.14.237.189) 
12.085 ms 72.14.237.27 (72.14.237.27) 8.979 ms 
8 209.85.253.114 (209.85.253.114) 26.920 ms 26.114 ms 25.789 ms 
MPLS Label=772454 CoS=5 TTL=1 S=0 
9 216.239.58.8 (216.239.58.8) 50.816 ms 209.85.241.233 
(209.85.241.233) 42.159 ms 43.461 ms 
MPLS Label=756878 CoS=5 TTL=1 S=0 
10 209.85.251.178 (209.85.251.178) 45.549 ms 44.474 ms 45.682 ms 
MPLS Label=720256 CoS=5 TTL=1 S=0 
11 74.125.37.103 (74.125.37.103) 39.998 ms 216.239.49.244 
(216.239.49.244) 48.116 ms 74.125.37.150 (74.125.37.150) 42.865 ms 
MPLS Label=25186 CoS=5 TTL=1 S=0 
12 209.85.251.231 (209.85.251.231) 39.575 ms 72.14.238.43 
(72.14.238.43) 43.933 ms 209.85.242.165 (209.85.242.165) 46.748 ms 
13 * *Icmp checksum is wrong 
* 
14 ns3.google.com (216.239.36.10) 41.453 ms 39.987 ms 47.545 ms 
[root@syz3ns01 ~]# 

[root@syz3ns02 ~]# traceroute ns3.google.com. 
traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets 
1 syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1) 0.232 ms 0.283 
ms 0.209 ms 
2 84.205.252.6 (84.205.252.6) 0.688 ms 0.535 ms 0.455 ms 
3 193.92.42.169 (193.92.42.169) 1.715 ms 0.835 ms 0.726 ms 
4 194.219.208.29 (194.219.208.29) 1.248 ms 0.876 ms 0.773 ms 
MPLS Label=757472 CoS=5 TTL=1 S=0 
5 xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193) 0.755 ms 1.047 
ms 0.944 ms 
6 74.125.48.74 (74.125.48.74) 8.331 ms 8.546 ms 8.328 ms 
7 72.14.237.189 (72.14.237.189) 12.286 ms 72.14.237.27 (72.14.237.27) 
5.935 ms 72.14.237.189 (72.14.237.189) 13.211 ms 
8 209.85.253.114 (209.85.253.114) 22.488 ms 209.85.240.160 
(209.85.240.160) 25.713 ms 26.401 ms 
MPLS Label=554255 CoS=5 TTL=1 S

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 14:41, Kevin Kretz wrote:
> Sotiris,
> 
> There could be multiple A records for load balancing.
> 

Of course, but answers of the first and second servers are on the same
subnet, and more importantly, work on the users' browsers.

The third set of answers is on a completely different subnet and
produces ssl errors in the browsers.. Like if it's a cluster for another
service, region or whatever..

Sot.

> 
> *From: *"Sotiris Tsimbonis" 
> *To: *bind-us...@isc.org
> *Sent: *Wednesday, June 1, 2016 7:34:00 AM
> *Subject: *different answers from google's authoritative servers
> 
> Hi all,
> 
> We have 3 recursive resolvers on the same subnet, and one of them is
> getting different answers for the same things from google's
> authoritative dns servers.
> 
> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
> ns3.google.com. ns4.google.com."
> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr."
> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
> @${resolver})" ; done ; done
> ns1.google.com. www.google.com. 216.58.211.4
> ns1.google.com. www.google.gr. 216.58.211.3
> ns2.google.com. www.google.com. 216.58.211.4
> ns2.google.com. www.google.gr. 216.58.211.3
> ns3.google.com. www.google.com. 216.58.211.4
> ns3.google.com. www.google.gr. 216.58.211.3
> ns4.google.com. www.google.com. 216.58.211.4
> ns4.google.com. www.google.gr. 216.58.211.3
> 
> [root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
> ns3.google.com. ns4.google.com."
> [root@syz3ns02 ~]# SITES="www.google.com. www.google.gr."
> [root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
> @${resolver})" ; done ; done
> ns1.google.com. www.google.com. 216.58.211.36
> ns1.google.com. www.google.gr. 216.58.211.35
> ns2.google.com. www.google.com. 216.58.211.36
> ns2.google.com. www.google.gr. 216.58.211.35
> ns3.google.com. www.google.com. 216.58.211.36
> ns3.google.com. www.google.gr. 216.58.211.35
> ns4.google.com. www.google.com. 216.58.211.36
> ns4.google.com. www.google.gr. 216.58.211.35
> 
> [root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
> ns3.google.com. ns4.google.com."
> [root@syz3ns03 ~]# SITES="www.google.com. www.google.gr."
> [root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
> @${resolver})" ; done ; done
> ns1.google.com. www.google.com. 172.217.16.36
> ns1.google.com. www.google.gr. 172.217.16.35
> ns2.google.com. www.google.com. 172.217.16.36
> ns2.google.com. www.google.gr. 172.217.16.35
> ns3.google.com. www.google.com. 172.217.16.36
> ns3.google.com. www.google.gr. 172.217.16.35
> ns4.google.com. www.google.com. 172.217.16.36
> ns4.google.com. www.google.gr. 172.217.16.35
> 
> The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and
> 84.205.252.20 respectively.
> 
> The problem with the third answer set is on the users' browsers, it
> produces an ssl certificate error and users cannot access google.
> 
> traceroute to google's dns servers are different on the penultimate hop
> (hop 12)
> 
> [root@syz3ns01 ~]# traceroute ns3.google.com.
> traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets
>  1  syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1)  0.405 ms  0.262
> ms  0.217 ms
>  2  84.205.252.6 (84.205.252.6)  0.718 ms  0.504 ms  0.511 ms
>  3  193.92.42.169 (193.92.42.169)  0.937 ms  1.024 ms  0.482 ms
>  4  194.219.208.29 (194.219.208.29)  1.017 ms  1.004 ms  0.946 ms
>  MPLS Label=757472 CoS=5 TTL=1 S=0
>  5  xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193)  0.950 ms  1.063
> ms  0.982 ms
>  6  74.125.48.74 (74.125.48.74)  8.373 ms  8.374 ms  8.341 ms
>  7  72.14.237.27 (72.14.237.27)  8.352 ms 72.14.237.189 (72.14.237.189)
> 12.085 ms 72.14.237.27 (72.14.237.27)  8.979 ms
>  8  209.85.253.114 (209.85.253.114)  26.920 ms  26.114 ms  25.789 ms
>  MPLS Label=772454 CoS=5 TTL=1 S=0
>  9  216.239.58.8 (216.239.58.8)  50.816 ms 209.85.241.233
> (209.85.241.233)  42.159 ms  43.461 ms
>  MPLS Label=756878 CoS=5 TTL=1 S=0
> 10  209.85.251.178 (209.85.251.178)  45.549 ms  44.474 ms  45.682 ms
>  MPLS Label=720256 CoS=5 TTL=1 S=0
> 11  74.125.37.103 (74.125.37.103)  39.998 ms 216.239.49.244
> (216.239.49.244)  48.116 ms 74.125.37.150 (74.125.37.150)  42.865 ms
>  MPLS Label=25186 CoS=5 TTL=1 S=0
> 12  209.85.251.231 (209.85.251.231)  39.575 ms 72.14.238.43
> (72.14.238.43)  43.933 ms 209.85.242.165 (209.85.242.165)  46.748 ms
> 13  * *Icmp checksum is wrong
>  *
> 14  ns3.google.com (216.239.36.10)  41.453 ms  39.987 ms  47.545 ms
> [root@syz3ns01 ~]#
> 
> [root@syz3ns02 ~]# traceroute ns3.google.com.
> traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets
>  1  syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1)  0.2

Re: different answers from google's authoritative servers

2016-06-01 Thread Kevin Kretz

Whether the responses to the query work properly in the browsers is a different 
issue. There's nothing inherently wrong with multiple and different responses 
to queries in different subnets or regions. 


From: "Sotiris Tsimbonis"  
To: "Kevin Kretz"  
Cc: bind-us...@isc.org 
Sent: Wednesday, June 1, 2016 7:46:38 AM 
Subject: Re: different answers from google's authoritative servers 

On 1/6/16 14:41, Kevin Kretz wrote: 
> Sotiris, 
> 
> There could be multiple A records for load balancing. 
> 

Of course, but answers of the first and second servers are on the same 
subnet, and more importantly, work on the users' browsers. 

The third set of answers is on a completely different subnet and 
produces ssl errors in the browsers.. Like if it's a cluster for another 
service, region or whatever.. 

Sot. 

>  
> *From: *"Sotiris Tsimbonis"  
> *To: *bind-us...@isc.org 
> *Sent: *Wednesday, June 1, 2016 7:34:00 AM 
> *Subject: *different answers from google's authoritative servers 
> 
> Hi all, 
> 
> We have 3 recursive resolvers on the same subnet, and one of them is 
> getting different answers for the same things from google's 
> authoritative dns servers. 
> 
> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
> ns3.google.com. ns4.google.com." 
> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr." 
> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in 
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
> @${resolver})" ; done ; done 
> ns1.google.com. www.google.com. 216.58.211.4 
> ns1.google.com. www.google.gr. 216.58.211.3 
> ns2.google.com. www.google.com. 216.58.211.4 
> ns2.google.com. www.google.gr. 216.58.211.3 
> ns3.google.com. www.google.com. 216.58.211.4 
> ns3.google.com. www.google.gr. 216.58.211.3 
> ns4.google.com. www.google.com. 216.58.211.4 
> ns4.google.com. www.google.gr. 216.58.211.3 
> 
> [root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
> ns3.google.com. ns4.google.com." 
> [root@syz3ns02 ~]# SITES="www.google.com. www.google.gr." 
> [root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in 
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
> @${resolver})" ; done ; done 
> ns1.google.com. www.google.com. 216.58.211.36 
> ns1.google.com. www.google.gr. 216.58.211.35 
> ns2.google.com. www.google.com. 216.58.211.36 
> ns2.google.com. www.google.gr. 216.58.211.35 
> ns3.google.com. www.google.com. 216.58.211.36 
> ns3.google.com. www.google.gr. 216.58.211.35 
> ns4.google.com. www.google.com. 216.58.211.36 
> ns4.google.com. www.google.gr. 216.58.211.35 
> 
> [root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
> ns3.google.com. ns4.google.com." 
> [root@syz3ns03 ~]# SITES="www.google.com. www.google.gr." 
> [root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in 
> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
> @${resolver})" ; done ; done 
> ns1.google.com. www.google.com. 172.217.16.36 
> ns1.google.com. www.google.gr. 172.217.16.35 
> ns2.google.com. www.google.com. 172.217.16.36 
> ns2.google.com. www.google.gr. 172.217.16.35 
> ns3.google.com. www.google.com. 172.217.16.36 
> ns3.google.com. www.google.gr. 172.217.16.35 
> ns4.google.com. www.google.com. 172.217.16.36 
> ns4.google.com. www.google.gr. 172.217.16.35 
> 
> The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and 
> 84.205.252.20 respectively. 
> 
> The problem with the third answer set is on the users' browsers, it 
> produces an ssl certificate error and users cannot access google. 
> 
> traceroute to google's dns servers are different on the penultimate hop 
> (hop 12) 
> 
> [root@syz3ns01 ~]# traceroute ns3.google.com. 
> traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets 
> 1 syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1) 0.405 ms 0.262 
> ms 0.217 ms 
> 2 84.205.252.6 (84.205.252.6) 0.718 ms 0.504 ms 0.511 ms 
> 3 193.92.42.169 (193.92.42.169) 0.937 ms 1.024 ms 0.482 ms 
> 4 194.219.208.29 (194.219.208.29) 1.017 ms 1.004 ms 0.946 ms 
> MPLS Label=757472 CoS=5 TTL=1 S=0 
> 5 xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193) 0.950 ms 1.063 
> ms 0.982 ms 
> 6 74.125.48.74 (74.125.48.74) 8.373 ms 8.374 ms 8.341 ms 
> 7 72.14.237.27 (72.14.237.27) 8.352 ms 72.14.237.189 (72.14.237.189) 
> 12.085 ms 72.14.237.27 (72.14.237.27) 8.979 ms 
> 8 209.85.253.114 (209.85.253.114) 26.920 ms 26.114 ms 25.789 ms 
> MPLS Label=772454 CoS=5 TTL=1 S=0 
> 9 216.239.58.8 (216.239.58.8) 50.816 ms 209.85.241.233 
> (209.85.241.233) 42.159 ms 43.461 ms 
> MPLS Label=756878 CoS=5 TTL=1 S=0 
> 10 209.85.251.178 (209.85.251.178) 45.549 ms 44.474 ms 45.682 ms 
> MPLS Label=720256 CoS=5 TTL=1 S=0 
> 11 74.125.37.103 (74.125.37.103) 39.998 ms 216.239.49.244 
> (216.239.49.244) 48.116 ms 74.125.37.150 (74.125.37.150) 42.865 ms 
> MPLS Label=25186 CoS=5 TTL=1 S=0 
> 12 209.85.251.231 (209.85.251.231) 39.575 ms 72

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 15:08, Kevin Kretz wrote:
> Whether the responses to the query work properly in the browsers is a
> different issue.  There's nothing inherently wrong with multiple and
> different responses to queries in different subnets or regions.
> 

True. But I'm trying to figure out why do the answers differ so much,
when from my side everything is on the same subnet, announced as
84.205.252.0/23 on our BGP. I would expect all of them to end up on the
same google anycast cluster and receive the same answer (or nearly the
same).

Sot.

> 
> *From: *"Sotiris Tsimbonis" 
> *To: *"Kevin Kretz" 
> *Cc: *bind-us...@isc.org
> *Sent: *Wednesday, June 1, 2016 7:46:38 AM
> *Subject: *Re: different answers from google's authoritative servers
> 
> On 1/6/16 14:41, Kevin Kretz wrote:
>> Sotiris,
>>
>> There could be multiple A records for load balancing.
>>
> 
> Of course, but answers of the first and second servers are on the same
> subnet, and more importantly, work on the users' browsers.
> 
> The third set of answers is on a completely different subnet and
> produces ssl errors in the browsers.. Like if it's a cluster for another
> service, region or whatever..
> 
> Sot.
> 
>> 
>> *From: *"Sotiris Tsimbonis" 
>> *To: *bind-us...@isc.org
>> *Sent: *Wednesday, June 1, 2016 7:34:00 AM
>> *Subject: *different answers from google's authoritative servers
>>
>> Hi all,
>>
>> We have 3 recursive resolvers on the same subnet, and one of them is
>> getting different answers for the same things from google's
>> authoritative dns servers.
>>
>> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
>> ns3.google.com. ns4.google.com."
>> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr."
>> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
>> @${resolver})" ; done ; done
>> ns1.google.com. www.google.com. 216.58.211.4
>> ns1.google.com. www.google.gr. 216.58.211.3
>> ns2.google.com. www.google.com. 216.58.211.4
>> ns2.google.com. www.google.gr. 216.58.211.3
>> ns3.google.com. www.google.com. 216.58.211.4
>> ns3.google.com. www.google.gr. 216.58.211.3
>> ns4.google.com. www.google.com. 216.58.211.4
>> ns4.google.com. www.google.gr. 216.58.211.3
>>
>> [root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
>> ns3.google.com. ns4.google.com."
>> [root@syz3ns02 ~]# SITES="www.google.com. www.google.gr."
>> [root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
>> @${resolver})" ; done ; done
>> ns1.google.com. www.google.com. 216.58.211.36
>> ns1.google.com. www.google.gr. 216.58.211.35
>> ns2.google.com. www.google.com. 216.58.211.36
>> ns2.google.com. www.google.gr. 216.58.211.35
>> ns3.google.com. www.google.com. 216.58.211.36
>> ns3.google.com. www.google.gr. 216.58.211.35
>> ns4.google.com. www.google.com. 216.58.211.36
>> ns4.google.com. www.google.gr. 216.58.211.35
>>
>> [root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
>> ns3.google.com. ns4.google.com."
>> [root@syz3ns03 ~]# SITES="www.google.com. www.google.gr."
>> [root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
>> @${resolver})" ; done ; done
>> ns1.google.com. www.google.com. 172.217.16.36
>> ns1.google.com. www.google.gr. 172.217.16.35
>> ns2.google.com. www.google.com. 172.217.16.36
>> ns2.google.com. www.google.gr. 172.217.16.35
>> ns3.google.com. www.google.com. 172.217.16.36
>> ns3.google.com. www.google.gr. 172.217.16.35
>> ns4.google.com. www.google.com. 172.217.16.36
>> ns4.google.com. www.google.gr. 172.217.16.35
>>
>> The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and
>> 84.205.252.20 respectively.
>>
>> The problem with the third answer set is on the users' browsers, it
>> produces an ssl certificate error and users cannot access google.
>>
>> traceroute to google's dns servers are different on the penultimate hop
>> (hop 12)
>>
>> [root@syz3ns01 ~]# traceroute ns3.google.com.
>> traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets
>>  1  syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1)  0.405 ms  0.262
>> ms  0.217 ms
>>  2  84.205.252.6 (84.205.252.6)  0.718 ms  0.504 ms  0.511 ms
>>  3  193.92.42.169 (193.92.42.169)  0.937 ms  1.024 ms  0.482 ms
>>  4  194.219.208.29 (194.219.208.29)  1.017 ms  1.004 ms  0.946 ms
>>  MPLS Label=757472 CoS=5 TTL=1 S=0
>>  5  xe-0-3-1.core-lsf-08.forthnet.gr (213.16.247.193)  0.950 ms  1.063
>> ms  0.982 ms
>>  6  74.125.48.74 (74.125.48.74)  8.373 ms  8.374 ms  8.341 ms
>>  7  72.14.237.27 (72.14.237.27)  8.352 ms 72.14.237.189 (72.14.237.189)
>> 12.085 ms 72.14.237.27 (72.14.237.27)  8.979 ms
>>  8  209.85.253.114 (209.85.253.114)  26.920 ms  26.114 ms  25.789 ms
>>

Re: different answers from google's authoritative servers

2016-06-01 Thread Kevin Kretz

There's also no reason to assume that the different responses have anything to 
do with the client network. They could, of course (with views), but that you 
get different responses from the same/similar IP is, again, not anything wrong. 


From: "Sotiris Tsimbonis"  
To: "Kevin Kretz"  
Cc: bind-us...@isc.org 
Sent: Wednesday, June 1, 2016 8:20:54 AM 
Subject: Re: different answers from google's authoritative servers 

On 1/6/16 15:08, Kevin Kretz wrote: 
> Whether the responses to the query work properly in the browsers is a 
> different issue. There's nothing inherently wrong with multiple and 
> different responses to queries in different subnets or regions. 
> 

True. But I'm trying to figure out why do the answers differ so much, 
when from my side everything is on the same subnet, announced as 
84.205.252.0/23 on our BGP. I would expect all of them to end up on the 
same google anycast cluster and receive the same answer (or nearly the 
same). 

Sot. 

>  
> *From: *"Sotiris Tsimbonis"  
> *To: *"Kevin Kretz"  
> *Cc: *bind-us...@isc.org 
> *Sent: *Wednesday, June 1, 2016 7:46:38 AM 
> *Subject: *Re: different answers from google's authoritative servers 
> 
> On 1/6/16 14:41, Kevin Kretz wrote: 
>> Sotiris, 
>> 
>> There could be multiple A records for load balancing. 
>> 
> 
> Of course, but answers of the first and second servers are on the same 
> subnet, and more importantly, work on the users' browsers. 
> 
> The third set of answers is on a completely different subnet and 
> produces ssl errors in the browsers.. Like if it's a cluster for another 
> service, region or whatever.. 
> 
> Sot. 
> 
>>  
>> *From: *"Sotiris Tsimbonis"  
>> *To: *bind-us...@isc.org 
>> *Sent: *Wednesday, June 1, 2016 7:34:00 AM 
>> *Subject: *different answers from google's authoritative servers 
>> 
>> Hi all, 
>> 
>> We have 3 recursive resolvers on the same subnet, and one of them is 
>> getting different answers for the same things from google's 
>> authoritative dns servers. 
>> 
>> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
>> ns3.google.com. ns4.google.com." 
>> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr." 
>> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in 
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
>> @${resolver})" ; done ; done 
>> ns1.google.com. www.google.com. 216.58.211.4 
>> ns1.google.com. www.google.gr. 216.58.211.3 
>> ns2.google.com. www.google.com. 216.58.211.4 
>> ns2.google.com. www.google.gr. 216.58.211.3 
>> ns3.google.com. www.google.com. 216.58.211.4 
>> ns3.google.com. www.google.gr. 216.58.211.3 
>> ns4.google.com. www.google.com. 216.58.211.4 
>> ns4.google.com. www.google.gr. 216.58.211.3 
>> 
>> [root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
>> ns3.google.com. ns4.google.com." 
>> [root@syz3ns02 ~]# SITES="www.google.com. www.google.gr." 
>> [root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in 
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
>> @${resolver})" ; done ; done 
>> ns1.google.com. www.google.com. 216.58.211.36 
>> ns1.google.com. www.google.gr. 216.58.211.35 
>> ns2.google.com. www.google.com. 216.58.211.36 
>> ns2.google.com. www.google.gr. 216.58.211.35 
>> ns3.google.com. www.google.com. 216.58.211.36 
>> ns3.google.com. www.google.gr. 216.58.211.35 
>> ns4.google.com. www.google.com. 216.58.211.36 
>> ns4.google.com. www.google.gr. 216.58.211.35 
>> 
>> [root@syz3ns03 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
>> ns3.google.com. ns4.google.com." 
>> [root@syz3ns03 ~]# SITES="www.google.com. www.google.gr." 
>> [root@syz3ns03 ~]# for resolver in ${RESOLVERS} ; do for site in 
>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
>> @${resolver})" ; done ; done 
>> ns1.google.com. www.google.com. 172.217.16.36 
>> ns1.google.com. www.google.gr. 172.217.16.35 
>> ns2.google.com. www.google.com. 172.217.16.36 
>> ns2.google.com. www.google.gr. 172.217.16.35 
>> ns3.google.com. www.google.com. 172.217.16.36 
>> ns3.google.com. www.google.gr. 172.217.16.35 
>> ns4.google.com. www.google.com. 172.217.16.36 
>> ns4.google.com. www.google.gr. 172.217.16.35 
>> 
>> The IP addresses of our servers are 84.205.252.16, 84.205.252.18 and 
>> 84.205.252.20 respectively. 
>> 
>> The problem with the third answer set is on the users' browsers, it 
>> produces an ssl certificate error and users cannot access google. 
>> 
>> traceroute to google's dns servers are different on the penultimate hop 
>> (hop 12) 
>> 
>> [root@syz3ns01 ~]# traceroute ns3.google.com. 
>> traceroute to ns3.google.com (216.239.36.10), 30 hops max, 38 byte packets 
>> 1 syz3fw01-dmz.servers.n3.syzefxis.gov.gr (10.95.1.1) 0.405 ms 0.262 
>> ms 0.217 ms 
>> 2 84.205.252.6 (84.205.252.6) 0.718 ms 0.504 ms 0.511 ms 
>> 3 193.92.42.169 (193.92.4

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 15:30, Kevin Kretz wrote:
> There's also no reason to assume that the different responses have
> anything to do with the client network.  They could, of course (with
> views), but that you get different responses from the same/similar IP
> is, again, not anything wrong.
> 

True, so below is probably the visualisation of load balancing ... which
most of the times gives me "the wrong logical answer".

[root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig
+short A www.google.com. @ns3.google.com.)" ; done
...
Wed Jun  1 15:42:31 EEST 2016 172.217.16.36
Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
Wed Jun  1 15:42:32 EEST 2016 216.58.208.100
Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
Wed Jun  1 15:42:33 EEST 2016 216.58.208.100
Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
Wed Jun  1 15:42:34 EEST 2016 216.58.208.100
Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
Wed Jun  1 15:42:35 EEST 2016 172.217.16.36
...

So what I'm really trying to find out is if there's anything from my
side to influence the load balancer's decision..

Sot.

> 
> *From: *"Sotiris Tsimbonis" 
> *To: *"Kevin Kretz" 
> *Cc: *bind-us...@isc.org
> *Sent: *Wednesday, June 1, 2016 8:20:54 AM
> *Subject: *Re: different answers from google's authoritative servers
> 
> On 1/6/16 15:08, Kevin Kretz wrote:
>> Whether the responses to the query work properly in the browsers is a
>> different issue.  There's nothing inherently wrong with multiple and
>> different responses to queries in different subnets or regions.
>>
> 
> True. But I'm trying to figure out why do the answers differ so much,
> when from my side everything is on the same subnet, announced as
> 84.205.252.0/23 on our BGP. I would expect all of them to end up on the
> same google anycast cluster and receive the same answer (or nearly the
> same).
> 
> Sot.
> 
>> 
>> *From: *"Sotiris Tsimbonis" 
>> *To: *"Kevin Kretz" 
>> *Cc: *bind-us...@isc.org
>> *Sent: *Wednesday, June 1, 2016 7:46:38 AM
>> *Subject: *Re: different answers from google's authoritative servers
>>
>> On 1/6/16 14:41, Kevin Kretz wrote:
>>> Sotiris,
>>>
>>> There could be multiple A records for load balancing.
>>>
>>
>> Of course, but answers of the first and second servers are on the same
>> subnet, and more importantly, work on the users' browsers.
>>
>> The third set of answers is on a completely different subnet and
>> produces ssl errors in the browsers.. Like if it's a cluster for another
>> service, region or whatever..
>>
>> Sot.
>>
>>> 
>>> *From: *"Sotiris Tsimbonis" 
>>> *To: *bind-us...@isc.org
>>> *Sent: *Wednesday, June 1, 2016 7:34:00 AM
>>> *Subject: *different answers from google's authoritative servers
>>>
>>> Hi all,
>>>
>>> We have 3 recursive resolvers on the same subnet, and one of them is
>>> getting different answers for the same things from google's
>>> authoritative dns servers.
>>>
>>> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
>>> ns3.google.com. ns4.google.com."
>>> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr."
>>> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in
>>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
>>> @${resolver})" ; done ; done
>>> ns1.google.com. www.google.com. 216.58.211.4
>>> ns1.google.com. www.google.gr. 216.58.211.3
>>> ns2.google.com. www.google.com. 216.58.211.4
>>> ns2.google.com. www.google.gr. 216.58.211.3
>>> ns3.google.com. www.google.com. 216.58.211.4
>>> ns3.google.com. www.google.gr. 216.58.211.3
>>> ns4.google.com. www.google.com. 216.58.211.4
>>> ns4.google.com. www.google.gr. 216.58.211.3
>>>
>>> [root@syz3ns02 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
>>> ns3.google.com. ns4.google.com."
>>> [root@syz3ns02 ~]# SITES="www.google.com. www.google.gr."
>>> [root@syz3ns02 ~]# for resolver in ${RESOLVERS} ; do for site in
>>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
>>> @${resolver})" ; done ; done
>>> ns1.google.com. www.google.com. 216.58.211.36
>>> ns1.google.com. www.google.gr. 216.58.211.35
>>> ns2.google.com. www.google.com. 216.58.211.36
>>> ns2.google.com. www.google.gr. 216.58.211.35
>>> ns3.google.com. www.google.com. 216.58.211.36
>>> ns3.google.com. www.google.gr. 216.58.211.35
>>> ns4.google.com. www.google.com. 216.58.211.36
>>> ns4.google.com. www.goo

Re: different answers from google's authoritative servers

2016-06-01 Thread Nico CARTRON

Hi Sotiris,
On 1 June 2016 at 14:47:31, Sotiris Tsimbonis (sts...@forthnet.gr) wrote:

On 1/6/16 15:30, Kevin Kretz wrote: 
> There's also no reason to assume that the different responses have 
> anything to do with the client network. They could, of course (with 
> views), but that you get different responses from the same/similar IP 
> is, again, not anything wrong. 
> 

True, so below is probably the visualisation of load balancing ... which 
most of the times gives me "the wrong logical answer". 

[root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig 
+short A www.google.com. @ns3.google.com.)" ; done 
... 
Wed Jun 1 15:42:31 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:35 EEST 2016 172.217.16.36 
... 

So what I'm really trying to find out is if there's anything from my 
side to influence the load balancer's decision.. 


Why would you want to influence the LB decision?  
Is there any difference between the different IP addresses you have as answers?

You mentioned SSL errors in the browser, could you give more details?
I don’t think you should have to fix that on your side, but rather find out 
what is happening.

Cheers,

-- 
Nico___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: different answers from google's authoritative servers

2016-06-01 Thread Kevin Kretz

I don't know what you mean by "the wrong logical answer". 

I get a different set of changing IPs when querying ns3.google.com than you, so 
the set you're getting likely is dependent on your IP/location. 


74.125.141.99 
74.125.141.106 
74.125.141.103 
74.125.141.105 
74.125.141.147 
74.125.141.104 

74.125.141.99 
74.125.141.103 
74.125.141.147 
74.125.141.105 
74.125.141.104 
74.125.141.106 

From: "Sotiris Tsimbonis"  
To: "Kevin Kretz"  
Cc: bind-us...@isc.org 
Sent: Wednesday, June 1, 2016 8:47:13 AM 
Subject: Re: different answers from google's authoritative servers 

On 1/6/16 15:30, Kevin Kretz wrote: 
> There's also no reason to assume that the different responses have 
> anything to do with the client network. They could, of course (with 
> views), but that you get different responses from the same/similar IP 
> is, again, not anything wrong. 
> 

True, so below is probably the visualisation of load balancing ... which 
most of the times gives me "the wrong logical answer". 

[root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig 
+short A www.google.com. @ns3.google.com.)" ; done 
... 
Wed Jun 1 15:42:31 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 216.58.208.100 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
Wed Jun 1 15:42:35 EEST 2016 172.217.16.36 
... 

So what I'm really trying to find out is if there's anything from my 
side to influence the load balancer's decision.. 

Sot. 

>  
> *From: *"Sotiris Tsimbonis"  
> *To: *"Kevin Kretz"  
> *Cc: *bind-us...@isc.org 
> *Sent: *Wednesday, June 1, 2016 8:20:54 AM 
> *Subject: *Re: different answers from google's authoritative servers 
> 
> On 1/6/16 15:08, Kevin Kretz wrote: 
>> Whether the responses to the query work properly in the browsers is a 
>> different issue. There's nothing inherently wrong with multiple and 
>> different responses to queries in different subnets or regions. 
>> 
> 
> True. But I'm trying to figure out why do the answers differ so much, 
> when from my side everything is on the same subnet, announced as 
> 84.205.252.0/23 on our BGP. I would expect all of them to end up on the 
> same google anycast cluster and receive the same answer (or nearly the 
> same). 
> 
> Sot. 
> 
>>  
>> *From: *"Sotiris Tsimbonis"  
>> *To: *"Kevin Kretz"  
>> *Cc: *bind-us...@isc.org 
>> *Sent: *Wednesday, June 1, 2016 7:46:38 AM 
>> *Subject: *Re: different answers from google's authoritative servers 
>> 
>> On 1/6/16 14:41, Kevin Kretz wrote: 
>>> Sotiris, 
>>> 
>>> There could be multiple A records for load balancing. 
>>> 
>> 
>> Of course, but answers of the first and second servers are on the same 
>> subnet, and more importantly, work on the users' browsers. 
>> 
>> The third set of answers is on a completely different subnet and 
>> produces ssl errors in the browsers.. Like if it's a cluster for another 
>> service, region or whatever.. 
>> 
>> Sot. 
>> 
>>>  
>>> *From: *"Sotiris Tsimbonis"  
>>> *To: *bind-us...@isc.org 
>>> *Sent: *Wednesday, June 1, 2016 7:34:00 AM 
>>> *Subject: *different answers from google's authoritative servers 
>>> 
>>> Hi all, 
>>> 
>>> We have 3 recursive resolvers on the same subnet, and one of them is 
>>> getting different answers for the same things from google's 
>>> authoritative dns servers. 
>>> 
>>> [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com. 
>>> ns3.google.com. ns4.google.com." 
>>> [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr." 
>>> [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in 
>>> ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site} 
>>> @${resolver})" ; done ; done 
>>> ns1.google.com. www.google.com. 216.58.211.4 
>>> ns1.google.com. www.google.gr. 216.58.211.3 
>>> ns2.google.com. www.google.com. 216.58.211.4 
>>> ns2.google.com. www.google.gr. 216.58.211.3 
>>> ns3.google.com. www.google.com. 216.58.211.4 
>>> ns3.google.com. www.google.gr. 216.58.211.3 
>>> ns4.google.com. www.google.com. 216.58.211.4 
>>> ns4.google.com. www.google.gr. 216.58.211.3 
>>> 
>>> [root@syz3ns02 ~]# RESOLVERS="ns1.google.c

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 15:50, Nico CARTRON wrote:
> Hi Sotiris,
> 
> On 1 June 2016 at 14:47:31, Sotiris Tsimbonis (sts...@forthnet.gr
> ) wrote:
> 
>> On 1/6/16 15:30, Kevin Kretz wrote: 
>> > There's also no reason to assume that the different responses have 
>> > anything to do with the client network. They could, of course (with 
>> > views), but that you get different responses from the same/similar IP 
>> > is, again, not anything wrong. 
>> > 
>>
>> True, so below is probably the visualisation of load balancing ... which 
>> most of the times gives me "the wrong logical answer". 
>>
>> [root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig 
>> +short A www.google.com. @ns3.google.com.)" ; done 
>> ... 
>> Wed Jun 1 15:42:31 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:32 EEST 2016 216.58.208.100 
>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:33 EEST 2016 216.58.208.100 
>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:34 EEST 2016 216.58.208.100 
>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>> Wed Jun 1 15:42:35 EEST 2016 172.217.16.36 
>> ... 
>>
>> So what I'm really trying to find out is if there's anything from my 
>> side to influence the load balancer's decision.. 
> 
> 
> Why would you want to influence the LB decision?
> Is there any difference between the different IP addresses you have as
> answers?
> 
> You mentioned SSL errors in the browser, could you give more details?
> I don’t think you should have to fix that on your side, but rather find
> out what is happening.

Because when google resolves to 172.217.16.*, browsers report an HSTS
violation and SEC_ERROR_UNKNOWN_ISSUER if firefox or
NET::ERR_CERT_AUTHORITY_INVALID in chrome.

When google resolves to 216.58.208.* they work as intented (no error).

Sot.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 16:00, Kevin Kretz wrote:
> I don't know what you mean by "the wrong logical answer". 
> 
> I get a different set of changing IPs when querying ns3.google.com than
> you, so the set you're getting likely is dependent on your IP/location.
> 
> 
> 74.125.141.99
> 74.125.141.106
> 74.125.141.103
> 74.125.141.105
> 74.125.141.147
> 74.125.141.104
> 
> 74.125.141.99
> 74.125.141.103
> 74.125.141.147
> 74.125.141.105
> 74.125.141.104
> 74.125.141.106

Of course, but all your answers are in 74.125.141.* which is probably
the closest (geo) cluster for you..

I assume that it's 216.58.208.* for me, but not 172.217.16.*.

Sot.

> 
> *From: *"Sotiris Tsimbonis" 
> *To: *"Kevin Kretz" 
> *Cc: *bind-us...@isc.org
> *Sent: *Wednesday, June 1, 2016 8:47:13 AM
> *Subject: *Re: different answers from google's authoritative servers
> 
> On 1/6/16 15:30, Kevin Kretz wrote:
>> There's also no reason to assume that the different responses have
>> anything to do with the client network.  They could, of course (with
>> views), but that you get different responses from the same/similar IP
>> is, again, not anything wrong.
>>
> 
> True, so below is probably the visualisation of load balancing ... which
> most of the times gives me "the wrong logical answer".
> 
> [root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig
> +short A www.google.com. @ns3.google.com.)" ; done
> ...
> Wed Jun  1 15:42:31 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:32 EEST 2016 216.58.208.100
> Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:32 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:33 EEST 2016 216.58.208.100
> Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:33 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:34 EEST 2016 216.58.208.100
> Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:34 EEST 2016 172.217.16.36
> Wed Jun  1 15:42:35 EEST 2016 172.217.16.36
> ...
> 
> So what I'm really trying to find out is if there's anything from my
> side to influence the load balancer's decision..
> 
> Sot.
> 
>> 
>> *From: *"Sotiris Tsimbonis" 
>> *To: *"Kevin Kretz" 
>> *Cc: *bind-us...@isc.org
>> *Sent: *Wednesday, June 1, 2016 8:20:54 AM
>> *Subject: *Re: different answers from google's authoritative servers
>>
>> On 1/6/16 15:08, Kevin Kretz wrote:
>>> Whether the responses to the query work properly in the browsers is a
>>> different issue.  There's nothing inherently wrong with multiple and
>>> different responses to queries in different subnets or regions.
>>>
>>
>> True. But I'm trying to figure out why do the answers differ so much,
>> when from my side everything is on the same subnet, announced as
>> 84.205.252.0/23 on our BGP. I would expect all of them to end up on the
>> same google anycast cluster and receive the same answer (or nearly the
>> same).
>>
>> Sot.
>>
>>> 
>>> *From: *"Sotiris Tsimbonis" 
>>> *To: *"Kevin Kretz" 
>>> *Cc: *bind-us...@isc.org
>>> *Sent: *Wednesday, June 1, 2016 7:46:38 AM
>>> *Subject: *Re: different answers from google's authoritative servers
>>>
>>> On 1/6/16 14:41, Kevin Kretz wrote:
 Sotiris,

 There could be multiple A records for load balancing.

>>>
>>> Of course, but answers of the first and second servers are on the same
>>> subnet, and more importantly, work on the users' browsers.
>>>
>>> The third set of answers is on a completely different subnet and
>>> produces ssl errors in the browsers.. Like if it's a cluster for another
>>> service, region or whatever..
>>>
>>> Sot.
>>>
 
 *From: *"Sotiris Tsimbonis" 
 *To: *bind-us...@isc.org
 *Sent: *Wednesday, June 1, 2016 7:34:00 AM
 *Subject: *different answers from google's authoritative servers

 Hi all,

 We have 3 recursive resolvers on the same subnet, and one of them is
 getting different answers for the same things from google's
 authoritative dns servers.

 [root@syz3ns01 ~]# RESOLVERS="ns1.google.com. ns2.google.com.
 ns3.google.com. ns4.google.com."
 [root@syz3ns01 ~]# SITES="www.google.com. www.google.gr."
 [root@syz3ns01 ~]# for resolver in ${RESOLVERS} ; do for site in
 ${SITES}; do echo "${resolver} ${site} $(dig +short A ${site}
 @${resolver})" ; done ; done
 ns1.google.com. www.google.com. 216.58.211.4
 ns

Re: different answers from google's authoritative servers

2016-06-01 Thread Sotiris Tsimbonis

On 1/6/16 16:10, Sotiris Tsimbonis wrote:
> On 1/6/16 15:50, Nico CARTRON wrote:
>> Hi Sotiris,
>>
>> On 1 June 2016 at 14:47:31, Sotiris Tsimbonis (sts...@forthnet.gr
>> ) wrote:
>>
>>> On 1/6/16 15:30, Kevin Kretz wrote: 
 There's also no reason to assume that the different responses have 
 anything to do with the client network. They could, of course (with 
 views), but that you get different responses from the same/similar IP 
 is, again, not anything wrong. 

>>>
>>> True, so below is probably the visualisation of load balancing ... which 
>>> most of the times gives me "the wrong logical answer". 
>>>
>>> [root@syz3ns03 ~]# while true ; do sleep 0.1 ; echo "$(date) $(dig 
>>> +short A www.google.com. @ns3.google.com.)" ; done 
>>> ... 
>>> Wed Jun 1 15:42:31 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:32 EEST 2016 216.58.208.100 
>>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:32 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:33 EEST 2016 216.58.208.100 
>>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:33 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:34 EEST 2016 216.58.208.100 
>>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:34 EEST 2016 172.217.16.36 
>>> Wed Jun 1 15:42:35 EEST 2016 172.217.16.36 
>>> ... 
>>>
>>> So what I'm really trying to find out is if there's anything from my 
>>> side to influence the load balancer's decision.. 
>>
>>
>> Why would you want to influence the LB decision?
>> Is there any difference between the different IP addresses you have as
>> answers?
>>
>> You mentioned SSL errors in the browser, could you give more details?
>> I don’t think you should have to fix that on your side, but rather find
>> out what is happening.
> 
> Because when google resolves to 172.217.16.*, browsers report an HSTS
> violation and SEC_ERROR_UNKNOWN_ISSUER if firefox or
> NET::ERR_CERT_AUTHORITY_INVALID in chrome.
> 
> When google resolves to 216.58.208.* they work as intented (no error).
> 

We just found out that the router in front of our servers had a static
route for 172.0.0.0/255.0.0.0 to some other interface.

This has now been changed to 172.16.0.0/255.240.0.0 and routing to
google subnet has been restored, browsers work as expected etc..

Thanks for your help to pinpoint this :)
Sot.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND 9.11.0a3 introduces catalog zones

2016-06-01 Thread Michael McNally

BIND 9.11.0a3, the third alpha development pre-release of BIND 9.11,
is now available for download from ISC's website:
http://www.isc.org/downloads

This release includes the debut of an experimental new 9.11 feature,
catalog zones.  Catalog zones are designed to allow easier dynamic
configuration of zones on secondary servers than previous methods,
as described in this snippet from the release announcement:

  A special zone of a new type, a catalog zone (CZ), is set up on the
  master and secondary servers in the normal way.  Once a catalog zone
  is configured, when an operator wishes to add a new zone to the nameserver
  constellation s/he can provision the zone on the master server and add
  an entry describing the zone to the catalog zone.  As the secondary
  servers receive the updated copy of the catalog zone data they will
  note the new entry and automatically create a zone for it, pull the
  zone data from the master server in the normal way, and begin serving
  the zone.

  Deletion of a zone listed in a CZ is done by deleting the entry in the
  catalog zone data.  The update of the CZ data on the secondary
  servers will cause them to stop serving the zone in question and to
  delete it from the secondaries, after which the operator can manually
  remove the zone from the master server.

We'd like your feedback on catalog zones and the other new features in
the development release.  Please see the release notes at:
ftp://ftp.isc.org/isc/bind9/9.11.0a3/RELEASE-NOTES-bind-9.11.0a3.html
and give the new release a try if you have a chance.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

Re: different answers from google's authoritative servers

BIND 9.11.0a3 introduces catalog zones

13 matches

Site Navigation

Mail list logo

Footer information