Google is connected to what's important to Google. Cloudflares business model, like any cdn, means it needs to be connected everywhere.
On Tue, Apr 3, 2018, 9:14 AM Matt Hoppes <mattli...@rivervalleyinternet.net> wrote: > Naw... not a router ID. > > traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets > 1 172.16.0.1 (172.16.0.1) 3.317 ms 0.878 ms 0.847 ms > 2 10.200.90.85 (10.200.90.85) 1.016 ms 1.028 ms 0.986 ms > 3 10.200.90.25 (10.200.90.25) 10.454 ms 17.965 ms 24.062 ms > 4 10.200.90.33 (10.200.90.33) 21.325 ms 19.223 ms 20.039 ms > 5 10.200.90.89 (10.200.90.89) 27.758 ms 19.306 ms 20.584 ms > 6 173.246.229.73 (173.246.229.73) 32.198 ms 14.440 ms 17.491 ms > 7 er0-nycmny.zitomedia.net (74.81.98.227) 39.302 ms 51.617 ms > 38.379 ms > 8 de-cix-new-york.as13335.net (206.130.10.31) 26.231 ms 32.837 ms > 36.809 ms > 9 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 36.106 ms 27.082 ms > 28.810 ms > > matt-hoppess-macbook-2:~ matth$ traceroute 172.16.0.21 > traceroute to 172.16.0.21 (172.16.0.21), 64 hops max, 52 byte packets > 1 172.16.0.21 (172.16.0.21) 3.248 ms 0.806 ms 0.650 ms > > The entry just wasn't cached locally. > > That being said, I'm impressed they seem to be incredibly connected -- > more so than Google. > > On 4/3/18 10:09 AM, Josh Reynolds wrote: > > Traceroute that. Look at the route for it. You might have used it for an > > OSPF router ID. > > > > On Tue, Apr 3, 2018, 9:04 AM Matt Hoppes > > <mattli...@rivervalleyinternet.net > > <mailto:mattli...@rivervalleyinternet.net>> wrote: > > > > So..... > > > > 8.8.8.8 > > Query time: 40 msec > > > > 1.1.1.1 > > Query time: 2 msec > > > > 172.16.0.21 > > Query time: 30 msec > > > > > > Wait... what?!?! How is CLoudFlare faster than my own local caching > > resolver? > > > > On 4/3/18 10:03 AM, Adam Moffett wrote: > > > It's clearly not hard. It's obviously not expensive. I'm already > > doing > > > it and have been for years. But it's more than $0. > > > > > > I've seen the geolocation issue in the past. More recently I > > tried to > > > demonstrate it to someone and it turned out that Google DNS and > > our own > > > DNS gave us Netflix content from the same source. > > > > > > If I used someone else's DNS and that 3rd party went away, then > there > > > are apparently 10 other "3rd parties" to choose from. I > > recognize the > > > point that it's a 3rd party and we don't want to rely on 3rd > parties: > > > But can we honestly say that our DNS servers are more reliable > than > > > Google or Cloudflare? > > > > > > I'm not shutting down the DNS servers today, I'm just trying to > look > > > inward and analyze what we're doing and why. Are we doing it > > because it > > > actually makes sense or are we doing it because we've always done > > it and > > > we can't imagine another way? > > > > > > > > > > > > ------ Original Message ------ > > > From: "Justin Wilson" <li...@mtin.net <mailto:li...@mtin.net> > > <mailto:li...@mtin.net <mailto:li...@mtin.net>>> > > > To: af@afmug.com <mailto:af@afmug.com> <mailto:af@afmug.com > > <mailto:af@afmug.com>> > > > Sent: 4/3/2018 8:48:33 AM > > > Subject: Re: [AFMUG] new DNS > > > > > >> You have your own DNS for one huge reason. GeoLocation for when > it > > >> comes to Content Networks such as Netflix. One of the > > mechanisms they > > >> employ is using DNS Geolocation to serve you the closest > > content. Not > > >> only do they do a GeLocate on your IP, but some also do a check > to > > >> make sure your DNS servers are coming from the same place as your > > >> customers. This is especially true if you or one of your > > upstreams is > > >> peered with Netflix or someone on an exchange. Otherwise, if you > are > > >> using Google or other DNS you may be in Kansas, and you might be > > >> getting content from Netflix out of California, when you could be > > >> getting it literally next door. Makes the customer experience > much > > >> better. There are RFCs that address this, but if they are > > implemented > > >> is a crapshoot. > > >> > > >> Secondly, relying on a 3rd party for such a critical service > such as > > >> DNS can be troublesome. Would you rely on someone else to > > provide the > > >> wireless signal to your customers blindly? If so, then > > offloading DNS > > >> is okay for you. I want more control for such a critical > service. > > >> > > >> I hear folks worry about the bandwidth DNS takes up. It’s not a > > >> concern either way. If your network can’t support the bandwidth > of > > >> DNS queries then you have deeper issues. > > >> > > >> It’s hard. No it’s not. Tons of tutorials on Bind for every > flavor > > >> of linux. Just about any old machine laying around can run DNS. > > >> > > >> If anyone wants to know how easy, and how cheap it is to spin up > DNS > > >> (both recursive and authoritative) hit me up. I will gladly > > talk with > > >> you about some strategy. > > >> > > >> Justin Wilson > > >> j...@mtin.net <mailto:j...@mtin.net> <mailto:j...@mtin.net > > <mailto:j...@mtin.net>> > > >> > > >> www.mtin.net <http://www.mtin.net> <http://www.mtin.net> > > >> www.midwest-ix.com <http://www.midwest-ix.com> > > <http://www.midwest-ix.com> > > >> > > >>> On Apr 3, 2018, at 6:34 AM, Paul Stewart <p...@paulstewart.org > > <mailto:p...@paulstewart.org> > > >>> <mailto:p...@paulstewart.org <mailto:p...@paulstewart.org>>> > wrote: > > >>> > > >>> I know there is often debates on here about running any > > servers, some > > >>> servers, or doing everything in-house (mail, web, DNS etc). > > Even if > > >>> you outsource everything I would still run recursive caching > DNS …. > > >>> Performance and reliability the main reasons. Some CDN’s and > other > > >>> services determine the path to send you content based on where > the > > >>> DNS look up occurs and in our case that’s a significant factor … > > >>> We operate our own anycasted DNS …actually two of them. One > set of > > >>> servers for recursive caching and another set for authoritative > > DNS. > > >>> Paul > > >>> *From:*Af <af-boun...@afmug.com <mailto:af-boun...@afmug.com> > > <mailto:af-boun...@afmug.com <mailto:af-boun...@afmug.com>>> on > > >>> behalf of "Forrest Christian (List Account)" > > <li...@packetflux.com <mailto:li...@packetflux.com> > > >>> <mailto:li...@packetflux.com <mailto:li...@packetflux.com>>> > > >>> *Reply-To:*<af@afmug.com <mailto:af@afmug.com> > > <mailto:af@afmug.com <mailto:af@afmug.com>>> > > >>> *Date:*Tuesday, April 3, 2018 at 4:33 AM > > >>> *To:*af <af@afmug.com <mailto:af@afmug.com> > > <mailto:af@afmug.com <mailto:af@afmug.com>>> > > >>> *Subject:*Re: [AFMUG] new DNS > > >>> Because it's good for your customers, and it should take very > > little > > >>> time to set one up. > > >>> The main reason for this is so that websites serve data from the > > >>> closest server due to the way that DNS anycast works. > > >>> And, the biggest one - to have control over a critical piece of > > >>> infrastructure for your customers. What happens if one of these > > >>> public DNS services go down and you have hundreds of customers > > >>> pointing at it? > > >>> On Mon, Apr 2, 2018 at 11:33 PM, Adam Moffett > > >>> <dmmoff...@gmail.com > > <mailto:dmmoff...@gmail.com><mailto:dmmoff...@gmail.com > > <mailto:dmmoff...@gmail.com>>> wrote: > > >>>> Someone remind me again why I have my own recursive DNS. > > >>>> ------ Original Message ------ > > >>>> From: "Josh Reynolds" > > >>>> <j...@kyneticwifi.com > > <mailto:j...@kyneticwifi.com><mailto:j...@kyneticwifi.com > > <mailto:j...@kyneticwifi.com>>> > > >>>> To:af@afmug.com <mailto:to%3...@afmug.com><mailto:af@afmug.com > > <mailto:af@afmug.com>> > > >>>> Sent: 4/2/2018 3:22:57 PM > > >>>> Subject: Re: [AFMUG] new DNS > > >>>>> Yes, bunch of discussions over the past few days on NANOG and > > some > > >>>>> of the vendor mailing lists. > > >>>>> On Mon, Apr 2, 2018, 2:21 PM Travis Johnson > > >>>>> <t...@ida.net <mailto:t...@ida.net><mailto:t...@ida.net > > <mailto:t...@ida.net>>> wrote: > > >>>>>> > > >>>>>> > > > https://gizmodo.com/how-to-speed-up-your-internet-and-protect-your-privacy-1824256587 > > >>>>>> > > >>>>>> Faster and more private than Google or others. :) > > >>>>>> > > >>>>>> Travis > > >>>>>> > > >>> > > >>> > > >>> -- > > >>> *Forrest Christian*/CEO, PacketFlux Technologies, Inc./ > > >>> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT > > 59602 > > >>> forre...@imach.com > > <mailto:forre...@imach.com><mailto:forre...@imach.com > > <mailto:forre...@imach.com>>| > > >>> http://www.packetflux.com <http://www.packetflux.com/> > > >>> > > >> > > >
