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

[Franck Martin]

On Jan 4, 2015, at 2:44 AM, Alexander Neilson <alexander at neilson.net.nz> wrote:

> 
> 
>> On 1/01/2015, at 3:24 am, Ralf Weber <dns at fl1ger.de> wrote:
>> 
>> 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! :-).
> 
> 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)
> 
> 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
> 
>> 
>>> * 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.
> 
> I fixed up the ACL’s to only allow recursion for our IP Space.
> 
> 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.
> 
> Its not full customer edge filtering (so we can’t match customers faking other customers) but its our first steps into it.

Awesome

> 
>> 
>>> * IPv6 access to resolving and authoritative servers
>> Even Better :-)
> 
> Next step is a full IPv6 rollout to customers

Excellent… On a side note you may want to read: https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

Which deals with email but also rDNS.

> 
>> 
>>> * 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.
> 
> 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.

You may find some useful documentation here if you worry about your network and not DNS only: https://www.m3aawg.org/published-documents

> 
>> 
>> [..]
>>> 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.
> 
> I did some actual resolution checks from the system and saw the following response times for a DNS queries for the com TLD NS
> 
> a: Query time: 199 msec
> b: Query time: 137 msec
> c: Query time: 144 msec
> d: Query time: 9 msec
> e: Query time: 8 msec
> f: Query time: 129 msec
> g: Query time: 172 msec
> h: Query time: 201 msec
> i: Query time: 79 msec
> j: Query time: 134 msec
> k: Query time: 206 msec
> l: Query time: 8 msec
> m: Query time: 243 msec
> 
> Now it may be something inside the network that specifically asks for a resolution of or against a.root-servers.net but I am seeing 11% of queries for a. and nothing in the top lists for any other root server.

I would have expected from NZ, the I and F root server would be the fastest… 

http://www.apnic.net/community/support/root-servers/root-server-map
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

You may want to get an atlas probe, so you can participate in global DNS measurements: https://atlas.ripe.net/

See results there: https://atlas.ripe.net/results/maps/
and how it matches your view of the Internet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150105/477874fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150105/477874fc/attachment.sig>