<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 1/01/2015, at 5:34 am, Rubens Kuhl <<a href="mailto:rubensk@nic.br" class="">rubensk@nic.br</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2014, at 11:05 AM, Alexander Neilson <<a href="mailto:alexander@neilson.net.nz" class="">alexander@neilson.net.nz</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">I am a relatively new operator of DNS servers and have inherited a rather messy existing system.<br class=""><br class="">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.<br class=""><br class="">Some of the changes implemented in the last year:<br class="">* Recursive resolvers now verify DNSSEC<br class=""></div></blockquote><div class=""><br class=""></div>Are recursives also restricting queries to the IP address space they should serve ? The line below could be it or something else:</div></div></div></blockquote><div><br class=""></div><div>Yes, strict ACL on the server allowing recursive resolution only to our allocated IP Space.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">* Improved ACL configuration to protect from attacks<br class=""></div></blockquote><br class=""><blockquote type="cite" class=""><div class="">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.<br class=""></div></blockquote><div class=""><br class=""></div>Keep doing that. Running the same server for both, even if the software allows it, showed to be not a best practice over time. </div></div></div></blockquote><div><br class=""></div><div>Building new servers over shutdown, take the duty to get improvements done while everything is quiet.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class="">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.<br class=""></div></blockquote><div class=""><br class=""></div>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. <br class=""></div></div></div></blockquote><div><br class=""></div><div>I will have to look at this as the next stage of development</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="">* prioritisation of root servers (my analysis of my server queries shows a high proportion of queries to <a href="http://a.root-servers.net/" class="">a.root-servers.net</a> 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)<br class=""><br class="">* 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)<br class=""></div></blockquote><div class=""><br class=""></div>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. </div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class="">* 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,</div></blockquote><div class=""><br class=""></div>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</div><div class=""><a href="http://registro.br/dnsshim" class="">http://registro.br/dnsshim</a> (recommended if you use BIND or NSD)</div></div></div></blockquote><div><br class=""></div><div>I haven’t reviewed this yet but I will look at building this later on.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><a href="http://atomiadns.com/" class="">http://atomiadns.com/</a> (recommended if you use Power DNS)</div><div class=""><br class=""></div><div class="">That can offload some management effort. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""> 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)<br class=""></div></blockquote><div class=""><br class=""></div>DNS views are a good thing, just be sure that they are the child of actual existing SLDs. Using <something>.<a href="http://internal.company.com/" class="">internal.company.com</a> (where <a href="http://company.com/" class="">company.com</a> is registered to you) is a good thing; using <something>.internal is a bad thing. </div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">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.<br class=""></div></blockquote><div class=""><br class=""></div>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. </div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Rubens</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class="">Regards</div><div class="">Alexander</div><div class=""><br class=""></div><div class="">Alexander Neilson</div><div class="">Neilson Productions Limited</div><div class=""><br class=""></div><div class=""><a href="mailto:alexander@neilson.net.nz" class="">alexander@neilson.net.nz</a></div><div class="">+64 21 329 681</div><div class="">+64 22 456 2326</div><div class=""><br class=""></div></div></div></body></html>