[AusNOG] DNS Craziness

Tue Feb 18 22:47:54 EST 2014

Hey Skeeve,

Do the connections come from different subnets?

Google has edns-client-subnet active on its recursive DNS clusters (https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00) - not sure if this is active between Google and Amazon Route53, but it could be playing a part, in the form of signalling to Route53 a different client subnet.

I can't find anything recent to confirm whether AWS supports this or not, other than some articles from 2012 which seemed to indicate they didn't (however a lot can change in a year...)

- Chris

On 18 Feb 2014, at 10:41 pm, Skeeve Stevens <skeeve+ausnog at eintellegonetworks.com> wrote:

> Hey all,
> 
> I hope to hell I haven't missed something here, but I have spent a lot of hours trying to figure out this problem and it is proving a little hard to nail down.
> 
> Simply, googles public DNS 8.8.8.8 is giving me two different responses from different peering connections.
> 
> A response from 8.8.8.8 over Megaport MLPA is giving me a different response to 8.8.8.8 over direct iPrimus -> Google peering.
> 
> The DNS is being sourced from AWS Route53 - so there shouldn't be any conflicting information.
> 
> There is no round-robin involved because both sides are consistently returning the same information.
> 
> The correct answer is actually via the iPrimus connection.
> 
> The mind blowing thing is that I get the same 'different' response if I query the AWS DNS server directly via each connection (as below).
> 
> I hope this makes sense... and that I haven't missed something obvious.  It almost feels like there is some split-view DNS going on here, but 8.8.8.8 wouldn't do that.
> 
> Alternatively, one of the connections has some sort of transparent DNS... i.e. the Megaport one.. but it is just going through a Juniper SRX550 cluster doing NAT into a Juniper MX border going into Megaport - none of which is doing DNS magic.
> 
> The iPrimus connection is going into Checkpoints as the edge straight into iPrimus... but they are reporting the correct answer.
> 
> My head hurts :(
> 
> 
> VIA MEGAPORT
> 
> [root at auth01n ~]# traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>  1  10.x.0.3 (10.x.0.3)  0.382 ms  0.353 ms  0.256 ms
>  2  10.x.0.62 (10.x.0.62)  3.370 ms  3.325 ms  3.320 ms
>  3  10.x.0.25 (10.x.0.25)  3.314 ms  3.297 ms  3.269 ms
> NAT HERE
>  4  as15169.sydney.megaport.com (103.26.68.56)  3.180 ms  3.142 ms  3.142 ms
>  5  72.14.237.21 (72.14.237.21)  3.125 ms  3.070 ms  3.077 ms
>  6  google-public-dns-a.google.com (8.8.8.8)  3.042 ms  2.331 ms  2.236 ms
> 
> 
> [root at auth01n ~]# dig a vpn.x.com @8.8.8.8   
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> a vpn.x.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24261
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;vpn.x.com.                        IN      A
> 
> ;; ANSWER SECTION:
> vpn.x.com.         299     IN      A       x.x.171.124
> 
> ;; Query time: 166 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Tue Feb 18 22:28:24 2014
> ;; MSG SIZE  rcvd: 48
> 
> =============
> 
> VIA IPRIMUS/EQUINIX
> 
> [root at auth01 ~]# traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>  1  10.x.65.2 (10.x.65.2)  0.476 ms  1.003 ms  1.227 ms
>  2  10.x.126.5 (10.x.126.5)  0.471 ms  0.608 ms  0.410 ms
> NAT HERE
>  3  x.x.static.syd.iprimus.net.au (203.134.x.x)  2.253 ms  2.064 ms  2.075 ms
>  4  atm3-2.ac02.syd.iprimus.net.au (203.134.2.249)  1.149 ms  0.768 ms at-1-0-2.ic02.pth.iprimus.net.au (203.134.2.225)  1.107 ms
>  5  xe-0-3-0.bsr01.equ.iprimus.net.au (203.134.2.234)  1.313 ms  0.646 ms xe-1-0-0.bsr01.equ.iprimus.net.au (203.134.2.254)  1.249 ms
>  6  google-gw.syd.iprimus.net.au (203.134.2.98)  1.406 ms  1.260 ms  1.209 ms
>  7  72.14.237.21 (72.14.237.21)  1.602 ms  1.871 ms  2.017 ms
>  8  google-public-dns-a.google.com (8.8.8.8)  1.333 ms  1.393 ms  1.403 ms
> 
> 
> [root at auth01 ~]# dig a vpn.x.com @8.8.8.8   
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> a vpn.x.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43084
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;vpn.x.com.                        IN      A
> 
> ;; ANSWER SECTION:
> vpn.x.com.         174     IN      A       x.x.102.124
> 
> ;; Query time: 143 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Tue Feb 18 22:30:29 2014
> ;; MSG SIZE  rcvd: 48
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - eintellego Networks Pty Ltd
> skeeve at eintellegonetworks.com ; www.eintellegonetworks.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/eintellegonetworks ; linkedin.com/in/skeeve 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140218/c254b800/attachment.html>