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

Ralf Weber dns at fl1ger.de
Wed Dec 31 14:24:52 UTC 2014


Moin!

> On 31 Dec 2014, at 14:05, Alexander Neilson <alexander at neilson.net.nz> 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: dns at fl1ger.de







More information about the dns-operations mailing list