No abstract

No abstract

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions.

In traditional networks, a single malicious ("Byzantine") packet switch can cause global disruption; for instance, by giving incorrect routing information, flooding the network with traffic, or forwarding data incorrectly. Previous work (which we'll call NPBR for "Network Protocols with Byzantine Robustness") presented a network design resilient to Byzantine failures, that guaranteed that nodes A and B can communicate, with some fair share of bandwidth, provided that at least one honest path connects them. NPBR, for reasons described in this paper, only works in a fairly small, flat network. This paper presents a network design that not only provides the same guarantees as NPBR, in a large hierarchical network, but provides additional guarantees, which we will describe in the paper. Furthermore, our design does not require any router to keep state larger than necessary for its portion of the network hierarchy. In this paper we summarize NPBR, explain why it does not extend to a hierarchy, and then present a design suitable for a hierarchy.

No abstract