Internet Security Group: Secure DNS

A large number of networked computers use the Internet Protocol (IP) for
communicating with one another. Computers on such networks can be addressed in
one of two ways: (a) using their domain name and (b) using their IP address. The
Domain Name System (DNS)(1) is a distributed database structure that underlies
IP networks. It provides a mapping from the IP address to the corresponding
domain name and from the domain name to the IP address. This information, also
referred to as DNS data is contained in classes of Resource Records (RRs) that
are maintained in Zone files by the DNS system.

The Secure Domain Name System (SDNS) protocol, currently in an
Internet-Draft, augments the DNS system by providing the following capabilities:

- Data Origin Authentication and Integrity for DNS data

- Transaction and Request Authentication

SDNS provides these new services by supporting the use of digital signatures
on DNS data. In particular, SDNS introduces two new resource records (RRs), KEY
and SIG, to support the signing and verification of the data. This gives SDNS
the added benefit of being a public key distribution mechanism for DNS keys.
While these keys are primarily used for authentication of DNS data, they can
also be used for other protocols such as IPSEC and email. KEY RRs support
several key algorithms including RSA, Diffie-Hellman and DSS.

There are several other key/certificate distribution services in use today.
One of the more popular ones is the X.500 system for distributing X.509
certificates. X.509 certificates contain public keys. Programs that need to use
X.500 for key/certificate retrieval require additional software for the
retrieval and verification of the X.509 certificates. This is to be contrasted
with DNS. Since DNS is ubiquitous, all machines connected to an IP network
already have the software necessary to retrieve information from a DNS server.

Two Internet-Drafts have been proposed for supporting external (non DNS)
certificates or keys within DNS. One proposal is to create a new Resource Record
to be called the CERT RR(4). This would allow a DNS administrator to place a non
DNS certificate in the DNS infrastructure as a new CERT RR. The advantages of
this proposal are:

- Clients can use domain names to retrieve certificates,

- Clients don't need additional software to retrieve certificates from
different sources.

- Clients can take advantage of DNS caching.

In this approach, client software would still have to retrieve the relevant
certificates for verification. These certificates may or may not be stored
within the Secure DNS infrastructure. In case they are not, additional software
is needed to retrieve these certificates. Note that this would involve the
ability to understand new certificate formats and to verify these certificates.

The other proposal is called the Indirect Key. This proposal allows for the
storage of pointers in the KEY RR to other key services. This pointer could
either be a URL, a pointer to a set of keys or a pointer to certificates inside
DNS or outside the DNS infrastructure. While this scheme allows for the use of
domain names to retrieve pointers to certificates/keys, it requires the client
to have special software to retrieve these certificates/keys and have additional
software to understand the certificate formats and verify them.

We have implemented a scheme which takes advantage of the Secure DNS
infrastructure by using Secure DNS to distribute verified public keys from other
distribution services. This goal is achieved by adding the following procedure
to the startup structure of any Domain Name Server in the Secure DNS
infrastructure.

- Include pointers to external Directory Servers that are authoritative for
the foreign keys.

- Have additional software to: (a) retrieve these keys and verify them and
(b) convert these verified keys into KEY RRs and write them into DNS zone files.

For client cryptographic applications that might have a security policy that
would require the knowledge of the origin of the key, we propose that there be a
modification to the KEY RR to indicate origin (such as X.509, PGP and DNS) of
the public key that is stored in the KEY RR.

The processing be performed offline and in batch mode every night so that
there would not be an impact on performance and the DNS database is kept current
with verified public keys.

This scheme offers the following advantages to the client code over the CERT
RR proposal:

- No need to understand the different types of certificate/key formats

- No need to verify the retrieved public keys

and the following advantages over the Indirect Key Proposal:

- No need to retrieve different public keys from different key distribution
services, requiring special software.

- No need to understand the different types of certificate/key formats

- No need to verify the retrieved public keys