<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=""><div apple-content-edited="true" class=""><br class="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 1/01/2015, at 3:24 am, Ralf Weber <<a href="mailto:dns@fl1ger.de" class="">dns@fl1ger.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Moin!<br class=""><br class=""><blockquote type="cite" class="">On 31 Dec 2014, at 14:05, Alexander Neilson <<a href="mailto:alexander@neilson.net.nz" class="">alexander@neilson.net.nz</a>> wrote:<br class="">Some of the changes implemented in the last year:<br class="">* Recursive resolvers now verify DNSSEC<br class=""></blockquote>Good! :-).<br class=""></div></blockquote><div><br class=""></div>Attending NZNOG and AUSNOG has really helped with real world advice / best practice at the high levels (I like deep dives into the technologies and sometimes we get that too here)</div><div><br class=""></div><div>Talks by Geoff Huston and others and developments discussed at these conferences really helped me work on priorities for customer experience and being a good citizen on the internet</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">* Improved ACL configuration to protect from attacks<br class=""></blockquote>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.<br class=""></div></blockquote><div><br class=""></div><div>I fixed up the ACL’s to only allow recursion for our IP Space.</div><div><br class=""></div><div>But I also implemented upstream border filtering to drop any outbound packets trying to leave my network with a source not within our IP Space.</div><div><br class=""></div><div>Its not full customer edge filtering (so we can’t match customers faking other customers) but its our first steps into it.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">* IPv6 access to resolving and authoritative servers<br class=""></blockquote>Even Better :-)<br class=""></div></blockquote><div><br class=""></div><div>Next step is a full IPv6 rollout to customers</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">* Resolved Fragmentation issues to allow full 4096 EDNS resolution<br class=""></blockquote>The best ;-). It seems like you already learned a lot and have taken the right decisions.<br class=""></div></blockquote><div><br class=""></div><div>I am doing my best to try improve all aspects of our network. However the learning is what I really value out of it all as every change I make helps me to understand how it all works in the plumbing.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">[..]<br class=""><blockquote type="cite" class="">To give an idea of the current top questions I have (however not limiting myself to learning about these):<br 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=""></blockquote>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.<br class=""></div></blockquote><div><br class=""></div><div>I did some actual resolution checks from the system and saw the following response times for a DNS queries for the com TLD NS</div><div><br class=""></div><div>a: Query time: 199 msec</div><div>b: Query time: 137 msec</div><div>c: Query time: 144 msec</div><div>d: Query time: 9 msec</div><div>e: Query time: 8 msec</div><div>f: Query time: 129 msec</div><div>g: Query time: 172 msec</div><div>h: Query time: 201 msec</div><div>i: Query time: 79 msec</div><div>j: Query time: 134 msec</div><div>k: Query time: 206 msec</div><div>l: Query time: 8 msec</div><div>m: Query time: 243 msec</div><div><br class=""></div><div>Now it may be something inside the network that specifically asks for a resolution of or against <a href="http://a.root-servers.net" class="">a.root-servers.net</a> but I am seeing 11% of queries for a. and nothing in the top lists for any other root server.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" 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=""></blockquote>There currently is a lot of discussion on exactly that topic in the IETF at the moment. The draft in question for that is <a href="https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-00" class="">https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-00</a> . Feel free to join the discussion. IMHO it is a good idea.<br class=""><br class=""></div></blockquote><div><br class=""></div><div>I will be giving this draft a trial on my system to see how it works in practice inside my network. I am joining IETF mailing lists to read some of the discussions and maybe join in discussions myself</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" 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, 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=""></blockquote>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. <br class=""></div></blockquote><div><br class=""></div><div>Thanks, I will investigate</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" 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=""></blockquote>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: <a href="http://blog.nominet.org.uk/tech/2010/05/24/436/" class="">http://blog.nominet.org.uk/tech/2010/05/24/436/</a> 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.<br class=""></div></blockquote><div><br class=""></div><div>I will start working through the RFC’s when I get a moment</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">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. <br class=""></blockquote>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.<br class=""><br class="">So long<br class="">-Ralf<br class="">---<br class="">Ralf Weber (Internet Citizen)<br class="">e: <a href="mailto:dns@fl1ger.de" class="">dns@fl1ger.de</a><br class=""><br class=""><br class=""><br class=""></div></blockquote></div><br class=""><div class=""><br class=""></div><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></body></html>