[dns-operations] Best Resources for Deep Dive Understanding of DNS

Alexander Neilson alexander at neilson.net.nz
Sun Jan 4 10:17:50 UTC 2015


> On 1/01/2015, at 5:34 am, Rubens Kuhl <rubensk at nic.br> wrote:
> 
> 
>> On Dec 31, 2014, at 11:05 AM, Alexander Neilson <alexander at neilson.net.nz <mailto:alexander at neilson.net.nz>> wrote:
>> 
>> I am a relatively new operator of DNS servers and have inherited a rather messy existing system.
>> 
>> In the past year I have been learning more about the operations of DNS servers and some of the aspects that hadn’t been addresses before in our system.
>> 
>> Some of the changes implemented in the last year:
>> * Recursive resolvers now verify DNSSEC
> 
> Are recursives also restricting queries to the IP address space they should serve ? The line below could be it or something else:

Yes, strict ACL on the server allowing recursive resolution only to our allocated IP Space.

> 
> 
>> * Improved ACL configuration to protect from attacks
> 
>> We operate several DNS servers, new ones are either Recursive or Authoritative however we also have an older server deployment that does both at once. We are working on splitting these roles apart by migrating the Authoritative zones off to the new authoritative group.
> 
> Keep doing that. Running the same server for both, even if the software allows it, showed to be not a best practice over time. 

Building new servers over shutdown, take the duty to get improvements done while everything is quiet.

> 
>> 
>> What I am looking at is peoples advice as to where I can next study up to understand the deeper aspects of DNS. Particularly looking at performance tuning and resilient architecture however any good resources that provide a good understanding of the deeper details of the operation of DNS.
> 
> Most DNS resiliency out there is achieved by stateless equal-cost multi-path distribution. Put the IP Address clients know in loopback interfaces, use a routing daemon to announce it to a router, it will automatically fail-over if a machine goes down. You can then further improve on it by each machine doing health check on its own service and killing the announcement. 

I will have to look at this as the next stage of development

>> 
>> * prioritisation of root servers (my analysis of my server queries shows a high proportion of queries to a.root-servers.net <http://a.root-servers.net/> however I have identified that this is one of the lowest response performance root server from where I am located), I would like to prefer the 6 root servers with the best response time (I have found 6 with RTT of less than 5ms and the rest show RTT ~180-200)
>> 
>> * Design considerations / advantages of pre loading the root zone (obviously I have root hints however what is the benefits of pre loading the root zone statically or just rely on resolving via the hints)
> 
> AXFR the root zone and the draft mentioned. Note that root hints and the root zone are different content; root hints are the address of the root servers, while the root zone contains the delegation information for the TLD servers. 

I had a read of that draft, it sounds like a great way to take one level of raw resolution off the long run. I will do some testing against my secondary servers and see how it works for me in practice.

> 
>> 
>> * Architecture advantages / disadvantages for building resilient systems (i.e. are there advantages to building a system with a “hidden” master with the public authoritative servers as slaves to this master,
> 
> Yes, hidden masters are good for your health. Besides using garden variety DNS software for hidden masters, there are hidden-master-only DNS software like
> http://registro.br/dnsshim <http://registro.br/dnsshim> (recommended if you use BIND or NSD)

I haven’t reviewed this yet but I will look at building this later on.

> http://atomiadns.com/ <http://atomiadns.com/> (recommended if you use Power DNS)
> 
> That can offload some management effort. 
> 
>> are DNS views recommended for resolving “internal” DNS results or is it just at risk of a fat finger errors to provide internal addresses to management teams)
> 
> DNS views are a good thing, just be sure that they are the child of actual existing SLDs. Using <something>.internal.company.com <http://internal.company.com/> (where company.com <http://company.com/> is registered to you) is a good thing; using <something>.internal is a bad thing. 

What I was wanting to do with the views was to use the net version of my domain properly, from our offices / internal routers I want to resolve to management interface addresses (for rancid, cacti, etc) and for remote management. But those names externally I want to use as forward and reverse domain entries for the same routers.

This way we can set up a naming convention that allows the engineers to look at any entries in a trace route and access the same device through the same name outsiders see but into management allowed interfaces.

> 
>> We use Bind as our server at the moment however I prefer to have a deep understanding of both the protocol and process defined in the RFC’s (and real world practice / interpretation) plus how individual implementations handle it.
> 
> For now keep the same software so you have less variables, but when you finish up splitting recursives and authoritatives and making other changes, consider other software options for your recursives like Unbound and Power DNS Recursor, and other options for your authoritatives like NSD, Power DNS, Yadifa, Knot. 

I am planning on retaining Bind while we have mixed role servers. I start to build a server with Unbound for a trial but then needed to use the machine to validate new bind config before I pushed it to customer facing servers.

> 
> 
> Rubens
> 
> 
>  
> 



Regards
Alexander

Alexander Neilson
Neilson Productions Limited

alexander at neilson.net.nz
+64 21 329 681
+64 22 456 2326

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150104/948e7a65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150104/948e7a65/attachment.bin>


More information about the dns-operations mailing list