DNS Exercises 1: Track 2 Workshop

PacNOG 7: American Samoa

$Name: DNSExercises1.html,v 1.2 2010/07/02 03:33:58 root Exp root $

Exercises

  1. Checking Domain Delegation Setup
  2. Improving DNS Performance
  3. DNSSEC Issues

Notes

  1. The "#" and "$" characters before commands represents your system prompt and is not part of the command itself. "#" indicates a command issued as root while "$" indicates a command issued as a normal user.

Checking Domain Delegation Setup [Top]

It's really important to check that our domain delegations are correctly delegated. This is especially true when the delegation is first carried out but it's also important to check periodically that things are still set up correctly. This is especially true if external agents are providing secondary service. They sometimes make changes which break things for you but have no direct impact on you.

The checking tool at http://dnscheck.se is useful as it displays a snapshot in time that can be compared with a later run using your domain name.

You should use this to check the domain you delegated yesterday to see how good a job you did. If you have errors you should try to understand what they are even if you don't have time to fix them.

Improving DNS Performance [Top]

Long delays in DNS lookup can have a major effect on browser performance on your network. If you can reduce the time taken to do DNS lookups your customers will start to download content much more snappily.

Local peering points with copies of the root name servers and your ccTLD name servers will make things perform faster and more reliably - especially in the event of a satellite failure or submarine fibre failure.

These graphs from NZ help illustrate some of the round trip times when all DNS comes from overseas.

http://erg.wand.net.nz/amp/matrix.php/latency/NZ/root+DNS
http://erg.wand.net.nz/amp/matrix.php/hops/NZ/root+DNS

DNSSEC Issues [Top]

One of the problems DNSSEC helps with is a DNS Cache Poisoning attack. The following video helps explain the issue.

http://www.youtube.com/watch?v=1d1tUefYn4Uz

You can read more about the problem on the IANA site at http://www.iana.org/reports/2008/cross-pollination-faq.html. There was a major effort to tidy the problem back in 2008 but not all DNS servers have been fixed.

We can test this using the dig tool:

$ dig +short porttest.dns-oarc.net txt
I tried it in my room on the hotel network and I got this: 
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"202.70.116.10 is POOR: 26 queries in 3.9 seconds from 1 ports with std dev 0"
What result do you get on the Track2 machines? Try this when you go home as well!

You can also use the webtool at /http://recursive.iana.org/ to test domain names. Try it with these:

and of course, try it with your own networks and perhaps your bank!

If your domain and your servers fail this test you need to upgrade your version of the nameserver software SOON - any recent version will have the fixes and you need to separate your caching and recursive servers. Restrict your recursive servers to your customers only.

The real answer is DNSSEC - this takes careful planning for the deployment.

BUT.....

Even if you don't deploy it DNSSEC is coming really soon - Thursday, July 15th 2010 - see http://www.root-dnssec.org/.

Why should you care? DNS response packets are set to get bigger either using EDNS0 over UDP or as TCP requests. The first option is better - less overhead.

Use the info at https://www.dns-oarc.net/oarc/services/replysizetest to see if your network can cope.

For example, look at these queries
dig any lpnz.org | more
dig any automagic.org | more

If your firewall blocks UDP packets bigger than 512 bytes or DNS over TCP then the second one will fail.
You can see a study of what happened when .org was signed recently at https://www.dns-oarc.net/node/199 - there's more of this on the way.


[Return to Top]

Andy Linton

$Id: DNSExercises1.html,v 1.8 2010/07/02 05:41:32 root Exp $