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

www.mtin.net
www.midwest-ix.com

> On Apr 3, 2018, at 6:34 AM, Paul Stewart <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> on behalf of "Forrest Christian (List 
> Account)" <li...@packetflux.com>
> Reply-To: <af@afmug.com>
> Date: Tuesday, April 3, 2018 at 4:33 AM
> To: af <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>> wrote:
>> Someone remind me again why I have my own recursive DNS.
>>  
>>  
>> ------ Original Message ------
>> From: "Josh Reynolds" <j...@kyneticwifi.com <mailto:j...@kyneticwifi.com>>
>> To: 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>> wrote:
>>>> https://gizmodo.com/how-to-speed-up-your-internet-and-protect-your-privacy-1824256587
>>>>  
>>>> <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> | http://www.packetflux.com 
> <http://www.packetflux.com/>

Reply via email to