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/>
     >>>
     >>

Reply via email to