<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 4, 2015, at 2:44 AM, Alexander Neilson <<a href="mailto:alexander@neilson.net.nz">alexander@neilson.net.nz</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div 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></div></div></blockquote><div><br></div>Awesome</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></div></blockquote><div><br></div>Excellent… On a side note you may want to read: <a href="https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf">https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf</a></div><div><br></div><div>Which deals with email but also rDNS.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></div></blockquote><div><br></div>You may find some useful documentation here if you worry about your network and not DNS only: <a href="https://www.m3aawg.org/published-documents">https://www.m3aawg.org/published-documents</a></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></div></blockquote><div><br></div><div>I would have expected from NZ, the I and F root server would be the fastest… </div><div><br></div><div><a href="http://www.apnic.net/community/support/root-servers/root-server-map">http://www.apnic.net/community/support/root-servers/root-server-map</a></div><div><a href="https://www.google.com/maps/d/u/0/viewer?ll=11.424429,26.178063&ie=UTF8&om=1&msa=0&spn=142.883537,288.632813&z=2&hl=en&mid=zlG9ajNou0XE.kueIslroMXZQ">https://www.google.com/maps/d/u/0/viewer?ll=11.424429,26.178063&ie=UTF8&om=1&msa=0&spn=142.883537,288.632813&z=2&hl=en&mid=zlG9ajNou0XE.kueIslroMXZQ</a></div><div><br></div></div>You may want to get an atlas probe, so you can participate in global DNS measurements: <a href="https://atlas.ripe.net/">https://atlas.ripe.net/</a><div><br></div><div>See results there: <a href="https://atlas.ripe.net/results/maps/">https://atlas.ripe.net/results/maps/</a></div><div>and how it matches your view of the Internet.</div></body></html>