[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Yet another Quadruple DNS?

Hi,

Maybe this links will help :

https://blog.cloudflare.com/dns-resolver-1-1-1-1/

https://blog.cloudflare.com/announcing-1111/

Best regards.



> Le 1 avr. 2018 à 19:05, Mike Hammett <nanog at ics-il.net> a écrit :
> 
> Unless you want optimum CDN performance, then your recursive servers belong pushed back in your network until there are no more diverse upstream\peer paths to choose from. 
> 
> Yes, I know there's an extension to DNS to help remove this need, but until that's universally supported, you can't abandon the old way. 
> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> ----- Original Message -----
> 
> From: "Stephen Satchell" <list at satchell.net> 
> To: nanog at nanog.org 
> Sent: Sunday, April 1, 2018 11:22:10 AM 
> Subject: Re: Yet another Quadruple DNS? 
> 
>> On 04/01/2018 08:18 AM, Matt Hoppes wrote: 
>> Why not just implement recursive cache severs on end user routers? 
>> Why does an end user CPE need to query one or two specific DNS 
>> servers? 
> Recursive lookups take bandwidth and wall time. The closer you can get 
> your recursive DNS server to the core of the internet, the faster the 
> lookups. This is particularly true of mobile and satellite. 
> 
> Implementing large caches in that close-to-the-core DNS server can add 
> another benefit: lookups to common and popular endpoints, such as 
> Google, would require far less real time to resolve. As the traffic 
> tides change, the cache would change with it, so flash-in-the-pan sites 
> would be served from cache, and forgotten in time when said sites drift 
> back to obscurity. 
> 
> (I wonder if the Internet Systems Consortium has considered adding a 
> cache-hit counter, or even a very coarse heat map (say, four 16-bit 
> counters cycled every five minutes), to DNS entries, to figure out the 
> best ones to drop? It would increase the complexity of BIND, but the 
> benefit for a BIND server serving a largish customer population could be 
> significant. If I were younger, I might try to model such a change. 
> Sort by hits, then by time-to-die. Drop the oldest 250 or so entries 
> when the cache is full. That way, the oldest least-used cache entries 
> get dropped.) 
> 
> ISPs provide to their customers DNS addresses to servers that, 
> allegedly, are closer to the core than the customers are. (Pipe dream, 
> I know; which is why so many ISPs have decided to specify 8.8.8.8 and 
> 8.8.4.4, because Google is closer to the core than the ISP is.) 
> 
> I've not personally measured the number of times a look-up could be 
> satisfied from a cache in a production environment; it's been 15 years 
> since I worked in such a job. It would be interesting to see if someone 
> has taken the time to gather those statistics and published them. 
> 
> The main reason for *not* implementing recursion exclusively in CPE is 
> that a recursive lookup is a complex operation, and I have my doubts if 
> BIND or equivalent could be maintained properly in, say, a wireless 
> access point (router) -- how would you update a hints table? 
>