DNS Future - The Future of the DNS Infrastructure at Carnegie Mellon



Background

The Domain Name System (DNS) is one of the largest services we provide. We offer the same DNS services we've offered for years, and at this time, this level of service is exactly what we need. However, over the next few years, some major changes will be taking place with the DNS world-wide, and we need to keep as up-to-date as possible.

One of the major changes that will take place over the next few years is the introduction of DNS Security Extentions (DNSSEC). Once DNSSEC is in place, a user will not only be able to lookup the IP address for a host, but also be sure that the received response was actually given out by the appropriate server. Among other things, this will stop malicious attempts to redirect user requests to hosts other than where they were expected to go. With this type of security, online services will be vulnerable to fewer attacks.

The IETF has had a working group discussing DNS IXFR, Notification, and Dynamic Updates. The working group (DNSIND) has just about finished up all of these services, and once they are, the services will be made available. The first service, DNS Incremental Transfer (IXFR), will allow zone updates to be done faster, with less network overhead. In the existing DNS, when a zone is updated, secondary servers pick up the entire zone from the primary server. With IXFR, only the changes are sent to the secondary.

This group has also worked on DNS Dynamic Updates (UPDATE). Dynamic updates will allow a site to provide dynamic IP addresses to machines, while allowing those machines to keep the exact same hostname. UPDATE specifies how processes outside of the DNS (DHCP Server, DHCP Client, etc) update the A and PTR Resource Records (RRs) in the DNS. This has the effect of updating the Hostname -> IP and IP -> Hostname mappings.

The IETF also has a proposal on how to do Dynamic Updates securely (DNS Secure Updates).

DNS performance is a large issue, and a number of changes have been proposed for how to improve performance, as well as reduce network traffic and load. At this time, an RFC has been submitted that describes how to cache and forward Negative DNS hits as well as Successful hits. Right now, when you lookup a host, the DNS server you contact fetches the hostname from a remote DNS server, places this host in it's cache, and forwards the response to you. The next time you lookup this host, if the cache entry is still valid, it's sent to you, and the remote DNS server is not touched. The DNS Negative Cache (NCACHE) RFC describes how DNS servers may cache "Unknown Host" responses, reducing the amount of network traffic for hosts that are truly unknown.

Once all of these proposals are made standards, network services will begin to rely on them, and users will want to use them. For example, Microsoft is using Dynamic Updates in NT5, and DNSSec will make all online services a little more secure. With this in mind, we need to be ready to put these services in place if and when we decide they are mature enough, and reasonable in our environment.

Where do we go from here

Our current DNS infrastructure is using the ISC's BIND distribution, version 4.9.5. In the summer of 1997, the ISC released an entirely new DNS server, which they referred to as version 8. Over the past year, this server has been updated a few times, to patch security and robustness holes. At this time, the server itself is pretty stable, and also supports the UPDATE and NOTIFY RFCs.

During the next year, the ISC plans on integrating DNSSEC and IXFR into the BIND 8 distribution. They have also announced that they will not do any more development on the BIND 4 distribution.

Due to these changes, we will be upgrading our DNS infrastructure to the BIND 8.x distribution. In order to do this, we need to modify our existing load balancing mechanism (BIND 8.x breaks it), as well as incorporate our SNMP Agent into the distribution.

Services

Once we have a BIND 8.x infrastructure in place, as long as we keep up to date with the BIND releases, our Domain Name Service should be able to provide all services the campus community requires. The next big question will be: "What services should we provide?"

DNS Security, when released, will be implemented. There is no reason not to do this. Resolvers that do not know about the security extensions should not have a problem talking to security-enabled servers.

DNS IXFR and NCACHE, when released, will also be implemented. These do not directly affect resolvers, and should be completely invisible to the user.

DNS Dynamic Updates will require some thoughts on whether or not we will be providing dynamic DNS services to our users; who will be performing the dynamic updates (users or DHCP servers); and to what extent we will be providing these services. Will they only affect certain areas (dorms), or the whole campus? How does NT5 affect this? This service will be looked into when we have a better idea for what using these dynamic services will actually mean.

And then what

This does not mark the end of our development work with respect to the DNS. We currently have a tiny SNMP agent that we add to the DNS Servers, which allow us to gather some DNS statistics remotely. This server was written a long time ago, and provided the information that we believed was necessary at that time. Since then, an RFC has been released that defines a MIB for DNS Servers. If we modify our DNS SNMP Agent to use this MIB, the ISC would probably incorporate it into their distribution, and the draft standard may be able to move on to a full standard.

Another area of development is the migration of the SNMP Agent from a standalone agent to an AgentX subagent.

Related Information


Ryan Troll ryan+@andrew.cmu.edu
May 1998

Home | Webmaster | Copyright | Carnegie Mellon Home