Moin! > On 31 Dec 2014, at 14:05, Alexander Neilson <[email protected]> wrote: > Some of the changes implemented in the last year: > * Recursive resolvers now verify DNSSEC Good! :-).
> * Improved ACL configuration to protect from attacks If you mean not allowing the world to query your recursive servers that is a good idea. If you you use ACLs/iptables to protect against attacks from allowed clients that IMHO is a recipe for disaster as these attacks change quite frequently, but if you have a tightly controlled network you might not have these. > * IPv6 access to resolving and authoritative servers Even Better :-) > * Resolved Fragmentation issues to allow full 4096 EDNS resolution The best ;-). It seems like you already learned a lot and have taken the right decisions. [..] > To give an idea of the current top questions I have (however not limiting > myself to learning about these): > > * prioritisation of root servers (my analysis of my server queries shows a > high proportion of queries to 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) Normally your resolver software should do this. The only reason I have why it doesn't is that there is a difference between the round trip that ping gives you and the actual round trip of the dns message, which the resolver will use for it's decision which server to query. Some servers take some time to answer a query, although it shouldn't be in the hundreds of milliseconds range. > * 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) There currently is a lot of discussion on exactly that topic in the IETF at the moment. The draft in question for that is https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-00 . Feel free to join the discussion. IMHO it is a good idea. > * 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, 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) Hidden Masters are pretty common these days and I wouldn't expose the data master to the Internet these days, unless you need to allow updates. If you are concerned about the ability to update your zone data at all times you can consider a multi master architecture. > 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. The RFCs that discuss DNS are a lot. The colleagues from Nominet did some work some time ago to visualise that. Still worth a read: http://blog.nominet.org.uk/tech/2010/05/24/436/ Implementations do have differences, though I don't think this is documented in a common place, but this list will have a discussion when such a difference is find, so it is a good place to be. > Please feel free to let me know if this is too far off topic for this list I > apologise if so, I believe it would fall in under operational as a better > understanding on the real world impacts of decisions however I may be drawing > a bit of a long bow. If people feel its off topic please feel free to > directly provide me any of this feedback off list so I don’t clog up peoples > inboxes. This list is dns operations, which is what you do, so I think you used the right place and your questions were certainly on topic. So long -Ralf --- Ralf Weber (Internet Citizen) e: [email protected] _______________________________________________ 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
