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 $
- Checking Domain Delegation Setup
- Improving DNS Performance
- DNSSEC Issues
- 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
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
These graphs from NZ help illustrate some of the round trip times when
all DNS comes from overseas.
DNSSEC Issues [Top]
One of the problems DNSSEC helps with is a DNS Cache Poisoning
attack. The following video helps explain the issue.
You can read more about the problem on the IANA site at
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:
What result do you get on the Track2 machines? Try this when you go
home as well!
"184.108.40.206 is POOR: 26 queries in 3.9 seconds from 1 ports with std dev 0"
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
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
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
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.
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.
DNSExercises1.html,v 1.8 2010/07/02 05:41:32 root Exp $