> On 1/01/2015, at 5:34 am, Rubens Kuhl <[email protected]> wrote: > > >> On Dec 31, 2014, at 11:05 AM, Alexander Neilson <[email protected] >> <mailto:[email protected]>> 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 [email protected] +64 21 329 681 +64 22 456 2326
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
