- Test - lists.nanog.org

AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks?
by Ronald F. Guilmette 25 Aug '17

25 Aug '17

Sorry for the re-post, but it has been brought to my attention that my inclusion, in my prior posting, of various unsavory FQDNs resolving to various IPv4 addresses on AS29073 has triggered some people's spam filters. (Can't imagine why. :-) So I am re-posting this message now, with just a link to where those shady FQDNs and their current forward resolutions may be found. (I also took the opportunity to clean up some minor typos.) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I think that this is primarily Level3's problem to fix. But you be the judge. Please, read on. +_+_+_+_+_+_+_+_ Over the weekend, I stumbled upon an interesting blog calld "Bad Packets", where a fellow named Troy has written about various unsavory goings on involving various newtorks. One network that he called out in particular was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has noted at length some break-in attempts originating from AS29073 and his inability to get anyone, in particular RIPE NCC, to give a damn. https://badpackets.net/the-master-needler-80-82-65-66/ https://badpackets.net/a-conversation-with-ripe-ncc-regarding-quasi-network… https://badpackets.net/quasi-networks-responds-as-we-witness-the-death-of-t… The fact that RIPE NCC declined to accept the role of The Internet Police didn't surprise me at all... they never have and probably never will. But I decided to have a quick look at what this newtork was routing, at present, which can be easily see here: http://bgp.he.net/AS29073#_prefixes So I was looking through the announced routes for AS29073, and it all looked pretty normal... a /24 block, check, a /24 block, check, a /21 block check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF GOD! WHAT'S THIS??? 196.16.0.0/14 !!! So how does a little two-bit network with a rather dubious reputation and a grand total of only about a /19 to its name suddenly come to be routing an entire /14 block?? And of course, its a legacy (abandoned) Afrinic block. And of course, there's no reverse DNS for any of it, because there is no valid delegation for the reverse DNS for any of it... usually a good sign that whoever is routing the block right now -does not- have legit rights to do so. (If they did, then they would have presented their LOAs or whatever to Afrinic and thus gotten the reverse DNS properly delegated to their own name servers.) I've seen this movie before. You all have. This gives every indication of being just another sad chapter in the ongoing mass pillaging of unused Afrinic legacy IPv4 space, by various actors with evil intent. I've already documented this hightly unfortunate fad right here on multiple occasions: https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html This incident is a bit different from the others however, in that it -does not- appear that the 196.16.0.0/14 block has been filed to the brim with snowshoe spammers. Well, not yet anyway. But if in fact the stories are correct, and if AS29073 does indeed have a history of hosting outbound hacking activities, then the mind reels when thinking about how much mischief such bad actors could get into if given an entire /14 to play with. (And by the way, this is a new world's record I think, for largest single-route deliberate hijack. I've seen plenty of /16s go walkabout before, and even a whole /15. But an entire /14?!?! That is uniquely brazen.) In addition to the above, and the points raised within the Bad Packets blog (see links above) I found, via passive DNS, a number of other causes for concern about AS29073, to wit: Shady FQDNs (incl possible child porn ones) on AS29073 moved here: https://pastebin.com/raw/f4M09UKL (In addition to the above, I've also found plenty more domain names associated with AS29073 which incorporate the names "Apple" "AirBnB", "Facebook", and "Groupon", as well as dozens of other legitimate companies and organizations.) I confess that I have not had the time to look at any of the web sites that may or may not be associated with any of the above FQDNs, but the domain names themselves are certainly strongly suggestive of (a) the possible hosting of child porn and also and separately (b) the possible hosting of phishing sites. So, given the history of this network (as is well documented on the Bad Packets blog) and given all of the above, and given what would appear to be the unauthorized "liberation" of the entire 196.16.0.0/14 block by AS29073, one cannot help but wonder: Why does anybody still even peer with these jerks? The always helpful and informative web site bgp.he.net indicates that very nearly 50% of the connectivity currently enjoyed by AS29073 is being provided to them by Level3. I would thus like to ask Level3 to reconsider that peering arrangement in light of the above facts, and especially in light of what would appear to be the unauthorized routing of the 196.16.0.0/14 block by AS29073. Surprisingly, given its history, AS29073 apparently has a total of 99 different peers, at present, and I would likewise ask all of them to reconsider their current peering arrangements with this network. I am listing all 99 peers below. Before I get to that however, I'd like to also note that there currently exists, within the RIPE Routing Registry, the following route object: route: 196.16.0.0/14 origin: AS29073 mnt-by: QUASINETWORKS-MNT mnt-by: EC42500-MNT mnt-routes: EC42500-MNT mnt-routes: M247-EU-MNT created: 2017-03-28T21:47:03Z last-modified: 2017-08-11T19:58:39Z source: RIPE I confess that I am not 100% sure of the exact semantics of the "mnt-routes" tag, but it would appear from the above that the UK's M247 network (AS9009)... which itself is not even peering with AS29073... appears to have, in effect countersigned the above RIPE route object, vouching for its correctness and authenticity as they did so. Why they would have done that, especially given that they themselves are not even peering with AS29073, is, I confess, beyond me. But I would love to have them explain it, or even try to explain it. It's enigmatic, to say the least. Anyway, the "created" date in the above record seems to be consistant with that actual start of the announcement of 196.16.0.0/14 by AS29073, which the RIPE Routing History tool says occured sometime in March of this year. One additional (and rather bizzare) footnote to this whole story about the 196.16.0.0/14 block has to do with the entity that allegedly -is- the current rightful owner of the block (as far as Afrinic is concerned). That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that handle is as follows: ------------------------------------------------------- person: Network and Information Technology Administrator address: Unit 117, Orion Mall, Palm Street address: Victoria, Mahe address: Seychelles (SC) phone: +972-54-2203545 e-mail: info(a)networkandinformationtechnology.com nic-hdl: NAIT1-AFRINIC mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY changed: info(a)networkandinformationtechnology.com 20150725 source: AFRINIC ------------------------------------------------------- Upon fetching the current WHOIS record for networkandinformationtechnology.com I found it more than passing strange that all of the contact details therein are associated *not* with anything in Africa, nor even anything in the home country of AS29073 (Netherlands) but rather, the address and phone numbers therein all appear to be ones associated with a relatively well known Internet attorney in Santa Monica, Califiornia by the name of Bennet Kelly. As it happens, in the distant past (about 10 years ago) I personally crossed swords with this particular fellow. He may be a lot of things, but it never seemed to me that stupid was one of them. And indeed the domain name networkandinformationtechnology.com and all of its connections to the 196.16.0.0/14 block appear to date from 2015... long before AS29073 started routing this block (which only started in March of this year). So, my best guess about this whole confusing mess is that the -original- legitimate owners of the 196.16.0.0/14 block most probably sold it on, in a legitimate transaction, to some other party in 2015, where that other party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that neither he nor the new owners, who he represents, even know that their expensive /14 has gone walkabout, as of March of this year. I will be trying to make contact with Mr. Kelley today to discuss this with him and will post a follow-up if any new and interesting information arises from that conversation. Regards, rfg Peers of AS29073: ================================================================================ 1 Level 3 Communications, Inc. United States AS3356 2 REBA Communications BV Netherlands AS56611 3 Hurricane Electric, Inc. United States AS6939 4 Core-Backbone GmbH Germany AS33891 5 Init7 (Switzerland) Ltd. Switzerland AS13030 6 RETN Limited Ukraine AS9002 7 COLT Technology Services Group Limited United Kingdom AS8220 8 State Institute of Information Technologies and Telecommunications (SIIT&T "Informika") Russian Federation AS3267 9 GlobeNet Cabos Submarinos Colombia, S.A.S. Colombia AS52320 10 Digital Telecommunication Services S.r.l. Italy AS49605 11 IT.Gate S.p.A. Italy AS12779 12 green.ch AG Switzerland AS1836 13 UNIDATA S.p.A. Italy AS5394 14 GEANT Limited European Union AS20965 15 IP-Max SA Switzerland AS25091 16 Lost Oasis SARL France AS29075 17 nexellent ag Switzerland AS31424 18 SEACOM Limited Mauritius AS37100 19 Angola Cables Angola AS37468 20 ENTANET International Limited United Kingdom AS8468 21 Blix Solutions AS Norway AS50304 22 POST Luxembourg Luxembourg AS6661 23 Zayo France SAS France AS8218 24 Wind Telecomunicazioni SpA Italy AS1267 25 Swisscom (Switzerland) Ltd Switzerland AS3303 26 Pacnet Global Ltd Hong Kong AS10026 27 SURFnet bv Netherlands AS1103 28 SEEWEB s.r.l. Italy AS12637 29 BIT BV Netherlands AS12859 30 euNetworks Managed Services GmbH Germany AS13237 31 CAIW Diensten B.V. Netherlands AS15435 32 netplus.ch SA Switzerland AS15547 33 DOKOM Gesellschaft fuer Telekommunikation mbH Germany AS15763 34 ADISTA SAS France AS16347 35 Viewqwest Pte Ltd Singapore AS18106 36 Digital Ocean, Inc. European Union AS200130 37 Digital Ocean, Inc. Netherlands AS202018 38 Open Peering B.V. Netherlands AS20562 39 Services Industriels de Geneve Switzerland AS20932 40 Cemig Telecomunicaes SA Brazil AS23106 41 SG.GS Singapore AS24482 42 Vorboss Limited United Kingdom AS25160 43 equada network GmbH Germany AS25220 44 Avantel, Close Joint Stock Company Russian Federation AS25227 45 Gyron Internet Ltd United Kingdom AS29017 46 IPROUTE SRL Italy AS49289 47 LLC "TRC FIORD" Russian Federation AS28917 48 Hostserver GmbH Germany AS29140 49 Telekommunikation Mittleres Ruhrgebiet GmbH Germany AS12329 50 Internet Systems Consortium, Inc. United States AS30132 51 Liquid Telecommunications Ltd United Kingdom AS30844 52 Paulus M. Hoogsteder trading as Meanie Netherlands AS31019 53 Digiweb ltd Ireland AS31122 54 Fiberax Networking&Cloud Ltd. United Kingdom AS3252 55 Hivane France AS34019 56 CELESTE SAS France AS34177 57 Kantonsschule Zug Switzerland AS34288 58 Citycable Switzerland AS34781 59 SoftLayer Technologies Inc. United States AS36351 60 Network Platforms (PTY) LTD South Africa AS37497 61 Micron21 Datacentre Pty Ltd Australia AS38880 62 Convergenze S.p.A. Italy AS39120 63 Fiberby ApS Denmark AS42541 64 IP ServerOne Solutions Sdn Bhd, Malaysia AS45352 65 Easynet Global Services European Union AS4589 66 IP-Only Networks AB Sweden AS12552 67 Tango S.A. Luxembourg AS48526 68 Les Nouveaux Constructeurs SA France AS49463 69 CustodianDC Limited United Kingdom AS50300 70 MCKAYCOM LTD United Kingdom AS50763 71 Daisy Communications Ltd United Kingdom AS5413 72 MC-IX Matrix Internet Exchange RS-1 Indonesia AS55818 73 NetIX Communications Ltd. Bulgaria AS57463 74 Anycast Global Backbone Australia AS58511 75 LUXNETWORK S.A. Luxembourg AS29467 76 oja.at GmbH Austria AS39912 77 Elisa Oyj Finland AS6667 78 A1 Telekom Austria AG Austria AS8447 79 Fusix Networks B.V. Netherlands AS57866 80 ClaraNET LTD United Kingdom AS8426 81 "OBIT" Ltd. Russian Federation AS8492 82 Console Network Solutions Ltd United Kingdom AS43531 83 NetCologne GmbH Germany AS8422 84 Tesonet Ltd Lithuania AS201341 85 Linx Telecommunications B.V. Estonia AS3327 86 Strato AG Germany AS6724 87 CJSC RASCOM Russian Federation AS20764 88 Sunrise Communications AG Switzerland AS6730 89 KPN B.V. Netherlands AS1136 90 MTN SA South Africa AS16637 91 Portlane AB Sweden AS42708 92 TM Net, Internet Service Provider Malaysia AS4788 93 Network Dedicated SAS Switzerland AS62355 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH Austria AS1764 95 Telkom SA Ltd. South Africa AS5713 96 ShockSRV Internet Services Private Limited Netherlands AS60115 97 JUPITER 25 LIMITED Netherlands AS64484 98 M-net Telekommunikations GmbH Germany AS8767 99 Neterra Ltd. Bulgaria AS34224

6 5

How can I obtain the abuse e-mail address for IPs from Japan?
by Kurt Kraut 25 Aug '17

25 Aug '17

Hello, I'm having a hard time to figure out the abuse e-mail address for IPs from Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus system I get the same e-mail addresses: abuse(a)apnic.net hm-changed(a)apnic.net ip-apnic(a)nic.ad.jp hostmaster(a)nic.ad.jp These e-mail addresses belong to JPNIC, not the autonomous system itself. So any messages sent to these e-mail addresses will not reach the offending NOC/SOC so I can report vulnerabilities and DDoS attacks. What am I missing and how should I report security issues to autonomous systems from this region? Has anyone here any experience on this? Thanks in advance, Kurt Kraut

8 9

Creating a Circuit ID Format
by Colton Conor 24 Aug '17

24 Aug '17

We are building a new fiber network, and need help creating a circuit ID format to for new fiber circuits. Is there a guide or standard for fiber circuit formats? Does the circuit ID change when say a customer upgrades for 100Mbps to 1Gbps port? What do the larger carriers do? Any advice on creating a circuit ID format for a brand new fiber network? Originally we ran a CLEC using a LECs copper, and our circuit ID was historically a telephone number for DSL circuits. The ILEC had a complex method for assigning circuit IDs. I am sure anything will work as long as you keep track of it, but any advice would be great!

13 14

Last Week's Canadian Fiber Cut
by Rod Beck 24 Aug '17

24 Aug '17

Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-b… Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com<http://www.unitedcablecompany.com> 85 Király utca, 1077 Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

11 17

Cogent Chicago
by Mike Hammett 24 Aug '17

24 Aug '17

I'm looking for someone knowledgeable as to how some of their datacenter POPs interconnect. Trying to determine what level of diversity other than POP location there are between two datacenters. Cogent staff is fine, maybe even preferred. Unsurprisingly, the sales person I talked to wasn't incredibly useful. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

1 0

Contact at Charter Communications?
by Chris Rhode 24 Aug '17

24 Aug '17

Hello, I apologize if this is not the appropriate place to ask, however we have been trying to get in touch with someone at Charter Communications to see if they are blocking part of our IP range and have been unsuccessful in getting in touch with anybody. I've contacted both the email address and called the phone number listed under the tech contact for brighthouse.com (which is the domain in question) listed on whois.icann.org and have not received any response. Would someone please contact me off-list with someone who I might be able to reach out to in order to check on this? Thank you! -- *Chris Rhode *Network Engineer University of South Florida – Information Technology crhode(a)usf.edu <mailto:crhode@usf.edu>

2 1

Re: AT&T NOC contact?
by Sahil Ganguly 24 Aug '17

24 Aug '17

Hello, Thank you for checking, the issue was resolved. On Thu, Aug 24, 2017 at 7:52 AM, Nimrod Levy <nimrodl(a)gmail.com> wrote: > There was a message to the outages list over the weekend on this, has this > issue not been resolved? > > On Thu, Aug 24, 2017 at 10:38 AM Sahil Ganguly via NANOG <nanog(a)nanog.org> > wrote: > >> Hello, >> >> Is there someone at AT&T on the mailing list I can talk to regarding a >> possible routing loop getting from AT&T to Box? >> >> Thanks! >> >> -- >> Sahil Ganguly >> Senior Network Operations Engineer >> >> >> M: 303.250.8893 <(303)%20250-8893> >> 900 Jefferson Ave >> Redwood City, CA 94063 >> > -- > > -- > Nimrod > -- Sahil Ganguly Senior Network Operations Engineer M: 303.250.8893 900 Jefferson Ave Redwood City, CA 94063

1 0

AT&T NOC contact?
by Sahil Ganguly 24 Aug '17

24 Aug '17

Hello, Is there someone at AT&T on the mailing list I can talk to regarding a possible routing loop getting from AT&T to Box? Thanks! -- Sahil Ganguly Senior Network Operations Engineer M: 303.250.8893 900 Jefferson Ave Redwood City, CA 94063

2 1

DevOps workflow for networking
by Kasper Adel 24 Aug '17

24 Aug '17

We are pretty new to those new-age network orchestrators and automation, I am curious to ask what everyone is the community is doing? sorry for such a long and broad question. What is your workflow? What tools are your teams using? What is working what is not? What do you really like and what do you need to improve? How mature do you think your process is? etc etc Wanted to ask and see what approaches the many different teams here are taking! We are going to start working from a GitLab based workflow. Projects are created, issues entered and developed with a gitflow branching strategy. GitLab CI pipelines run package loadings and run tests inside a lab. Tests are usually python unit tests that are run to do both functional and service creation, modification and removal tests. For unit testing we typically use python libraries to open transactions to do the service modifications (along with functional tests) against physical lab devices. For our prod deployment we leverage 'push on green' and gating to push package changes to prod devices. Thanks

11 11

Google DNS --- Figuring out which DNS Cluster you are using
by Erik Sundberg 24 Aug '17

24 Aug '17

I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share the information on nanog as well. A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on how to determine which DNS Cluster you are going to. Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed multiple DNS clusters across the world and each DNS Cluster has multiple servers. So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York. How to get a list of google DNS Cluster’s. dig -t TXT +short locations.publicdns.goog. @8.8.8.8 How to print this list in a table format. Script from: https://developers.google.com/speed/public-dns/faq --------------- #!/bin/bash IFS="\"$IFS" for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) do case $LOC in '') : ;; *.*|*:*) printf '%s ' ${LOC} ;; *) printf '%s\n' ${LOC} ;; esac done --------------- Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and their associated locations. 74.125.18.0/26 iad 74.125.18.64/26 iad 74.125.18.128/26 syd 74.125.18.192/26 lhr 74.125.19.0/24 mrn 74.125.41.0/24 tpe 74.125.42.0/24 atl 74.125.44.0/24 mrn 74.125.45.0/24 tul 74.125.46.0/24 lpp 74.125.47.0/24 bru 74.125.72.0/24 cbf 74.125.73.0/24 bru 74.125.74.0/24 lpp 74.125.75.0/24 chs 74.125.76.0/24 cbf 74.125.77.0/24 chs 74.125.79.0/24 lpp 74.125.80.0/24 dls 74.125.81.0/24 dub 74.125.92.0/24 mrn 74.125.93.0/24 cbf 74.125.112.0/24 lpp 74.125.113.0/24 cbf 74.125.115.0/24 tul 74.125.176.0/24 mrn 74.125.177.0/24 atl 74.125.179.0/24 cbf 74.125.181.0/24 bru 74.125.182.0/24 cbf 74.125.183.0/24 cbf 74.125.184.0/24 chs 74.125.186.0/24 dls 74.125.187.0/24 dls 74.125.190.0/24 sin 74.125.191.0/24 tul 172.217.32.0/26 lhr 172.217.32.64/26 lhr 172.217.32.128/26 sin 172.217.33.0/26 syd 172.217.33.64/26 syd 172.217.33.128/26 fra 172.217.33.192/26 fra 172.217.34.0/26 fra 172.217.34.64/26 bom 172.217.34.192/26 bom 172.217.35.0/24 gru 172.217.36.0/24 atl 172.217.37.0/24 gru 173.194.90.0/24 cbf 173.194.91.0/24 scl 173.194.93.0/24 tpe 173.194.94.0/24 cbf 173.194.95.0/24 tul 173.194.97.0/24 chs 173.194.98.0/24 lpp 173.194.99.0/24 tul 173.194.100.0/24 mrn 173.194.101.0/24 tul 173.194.102.0/24 atl 173.194.103.0/24 cbf 173.194.168.0/26 nrt 173.194.168.64/26 nrt 173.194.168.128/26 nrt 173.194.168.192/26 iad 173.194.169.0/24 grq 173.194.170.0/24 grq 173.194.171.0/24 tpe 2404:6800:4000::/48 bom 2404:6800:4003::/48 sin 2404:6800:4006::/48 syd 2404:6800:4008::/48 tpe 2404:6800:400b::/48 nrt 2607:f8b0:4001::/48 cbf 2607:f8b0:4002::/48 atl 2607:f8b0:4003::/48 tul 2607:f8b0:4004::/48 iad 2607:f8b0:400c::/48 chs 2607:f8b0:400d::/48 mrn 2607:f8b0:400e::/48 dls 2800:3f0:4001::/48 gru 2800:3f0:4003::/48 scl 2a00:1450:4001::/48 fra 2a00:1450:4009::/48 lhr 2a00:1450:400b::/48 dub 2a00:1450:400c::/48 bru 2a00:1450:4010::/48 lpp 2a00:1450:4013::/48 grq There are IPv4 Networks: 68 IPv6 Networks: 20 DNS Cluster’s Identified by POP Code’s: 20 DNS Clusters identified by POP Code to City, State, or Country. Not all of these are Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). https://peering.google.com/#/infrastructure and https://www.google.com/about/datacenters/inside/locations/ Most of these are airport codes, it did my best to get the location correct. iad Washington, DC syd Sydney, Australia lhr London, UK mrn Lenoir, NC tpe Taiwan atl Altanta, GA tul Tulsa, OK lpp Findland bru Brussels, Belgium cbf Council Bluffs, IA chs Charleston, SC dls The Dalles, Oregon dub Dublin, Ireland sin Singapore fra Frankfort, Germany bom Mumbai, India gru Sao Paulo, Brazil scl Santiago, Chile nrt Tokyo, Japan grq Groningen, Netherlans Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "173.194.94.135" <<<<<<DNS Server IP, reference the list above to get the cluster, Council Bluffs, IA "edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block Side note, the google dns servers will not respond to DNS queries to the Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 and 8.8.4.4. So the following will not work. dig google.com @173.194.94.135 Now to see the DNS Cluster load balancing in action. I am doing a dig query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with google at this location. I dig a dig query about 10 times and received the following unique dns cluster member ip’s as responses. dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71" "74.125.177.4" Which all are Google DNS Networks in Atlanta. 74.125.42.0/24 atl 74.125.177.0/24 atl 172.217.36.0/24 atl 173.194.102.0/24 atl 2607:f8b0:4002::/48 atl Just thought it would be helpful when troubleshooting google DNS issues. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

9 11