Let's have a look at the DNS. So the DNS is the Domain Name System and without DNS there is effectively no network. All users and possibly background services are affected whether it's for authentication, email or other services. Of course, as we all know, end users will complain the internet's not working and it's usually when the DNS has stopped providing answers. There are two kinds of DNS servers. There's the caching server which is also called resolver and what this does is look up in other words fetch and return DNS information for clients. For example what's the IP address of www.nsrc.org ? The other kind of DNS server is the authoritative server. This one serves DNS data and it replies to queries from caching servers. For example, I have the answer to your question the IP address of www.nsrc.org is And we are going to focus on the caching DNS service. Let's look at the first set of recommendations. Campus networks must offer reliable and fast DNS servers and by fast we mean low latency. Having on-campus and fast caching resolvers is extremely important. You can run these on virtual machines as long as there's enough RAM and CPU to deal with the load. Avoid giving users resolvers which are tens or hundreds of milliseconds away. There are many public service resolvers and these are usually well intended but what they do is they harm the internet experience for users and result in large amounts of DNS traffic using external and transit links. Fast and reliable DNS caches give better response times if they're sitting on the local network. This reduces the amount of DNS traffic that must leave the campus, allows blocking access to undesirable domains by policy or other and lets the administrators use the DNS blacklist DNSBL type services to restrict access to some of these domains. It means also there is no need for HTTP proxies or deep packet inspection. It's also important to give DNS caches public IPv4 addresses. We all know that IPv4 address space is very scarce but it is quite important to ensure that DNS caches are able to use public v4 addresses because placing them behind NATs or firewalls will result in a vast consumption of the network address translation resources needed. It doesn't matter if clients are in private space as long as you make sure the caches are on the public side. If your campus runs authoritative DNS as well please don't ever use your authoritative DNS as a resolver. Use a separate system or separate virtual machine for the authoritative DNS. In these days of virtual machines it is very inexpensive to set up another container or virtual machine simply to handle the authoritative DNS and a separate one to handle the caching DNS. The functions of the authoritative and caching are completely different so keep them well apart. The authoritative DNS is queried by the whole world and gives out information about your domains and Europe v4 and v6 addresses namely the reverse DNS caching. DNS is for your end users and it keeps the cache of frequently used names and addresses if we look at the configuration of DNS software we recommend using either unbound or powerdns recursor as the caching resolver. Both of these are caching only and you can find more information at the two URLSs provided on the slide. It is simple for you to define which address ranges are allowed to use your cache so v4 and v6 but make sure it's only the hosts and devices on campus. No other configuration is needed which means that these resolvers are very quick and simple to set up. Redundancy is critical for the DNS so it's important to have two caches on campus. If you take one cache out of service, the other one will then provide the answers for all the queries. If you only have one cache, then if it disappears your end users basically think the internet has stopped working. So it's important to have two caches on campus on two separate systems so the virtual machines are sitting on separate hardware so any infrastructure outages can be minimized. Larger campuses may have two layers of DNS servers, core servers and client-facing servers. The IP addresses of the DNS resolvers are handed out using the DHCP service. DNS uses a very simple client-based failover if dns-1 doesn't answer then wait x seconds and try dns2. And it does this for every query. The value of x for seconds depends entirely on the client or basically the operating system used on the end user system so just be aware of problems that this may cause. There are ways to mitigate it of course. For monitoring DNS use a service monitoring tool like Nagios or Smokeping to monitor availability and latency for each cache check regularly that a given name can be looked up and that the answer is the expected one. Verify that the cache answers in a timely fashion, for example below 10 millisecond response time is what you would reasonably expect for cached data.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.