One document matched: draft-ohta-simple-dns-00.txt
INTERNET DRAFT M. Ohta
draft-ohta-simple-dns-00.txt Tokyo Institute of Technology
August 1994
Simple Secure DNS
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
An extension to DNS is proposed to make answers from it
authenticated.
The extension is designed to be minimal, which will be useful as a
framework to make applications provide required level of
authentication and/or confidentiality.
The changes to the existing architecture of DNS is also minimized.
1. Introduction
The purpose of the secure DNS protocol extension is to make data from
DNS authenticated. In general, security has two aspects,
authentication to make data unforgable and confidentiality to make
data secret. As the fundamental role of DNS is to make its database
available all around the world, no confidentiality is considered in
this document. IQUERY, an optional feature of DNS, is inherently
insecure, and not considered in this document.
This document is written with the assumption that readers thoroughly
understand the existing DNS described in RFC 1034 and RFC 1035. On
the other hand, little knowledge on cryptography is assumed.
M. Ohta Expires on Feb. 8, 1995 [Page 1]
INTERNET DRAFT Simple Secure DNS August 1994
To make DNS secure, two cryptographic mechanisms: digesting and
signature, are combined. Digesting is the mechanism to compute a
short digest of a byte stream. The mechanism should be complex
enough so that, given a digest value of some byte stream, it should
be practically impossible to forge a different byte stream which has
the same digest value. The other is the mechanism to give signature
to a byte stream with some secret information. The mechanism should
be complex enough so that, given a signature value of some data and
the original data itself, it should be practically impossible to
guess the secret information. The signature can be verified by
sharing secret information between related parties or by using
private/public key technology.
This document does not specify the actual mechanisms to generate
digests and signatures.
As long as the above two basic authentication mechanisms are
reliable, secure DNS is designed to be reliable against all forms of
attacks save the denial of service attacks of the most basic form,
which is least harmful. That is, the secure DNS may report a
temporal failure against some form of denial of service attacks. But
all the answers other than the temporal failure is reliable to the
extent that the basic authentication mechanisms up to the root or
other locally reliable zones are reliable. For example, if a
resolver can communicate with no name servers because of some attack
such as unplugging of cables, the only thing the resolver can do is
to report the temporal failure, which is one of the most basic form
of a denial of service attack. On the other hand, secure DNS can
securely report negative answers that a node does not exists or that
an RR type does not exist for a given node.
Authentication is provided zone wise. A secure zone is a zone whose
authentication is provided by the protocol whereas a secure node is a
node authoritatively belongs to a secure zone. A secure zone has its
own secret information to generate signatures for secure nodes in the
zone. For the maximum security, both the secret information and the
signature generation mechanism of a zone should be kept off-line. In
this case, even if on-line name servers of the zone is compromised,
security on the DNS information of the zone is not compromised. In
cases where frequent and/or automatic update of a zone is desired, it
is necessary to make signature generation mechanism of the zone
accessible on-line. Still, it is worthwhile to keep the secret
information and secure time stamping mechanism of the zone off-line.
To make it easier, the protocol is designed to let signed information
have the consistent format about time stamping and signature
generation. Then, after the security of the signature generation
mechanism is restored, signatures using the same secret information
become reliable again.
M. Ohta Expires on Feb. 8, 1995 [Page 2]
INTERNET DRAFT Simple Secure DNS August 1994
Though the secure DNS can be a authenticated source of information to
establish secure communication between hosts, it is out of the scope
of this document and a separate document should be provided.
A security aware name server is a name server which can perform
authenticated communication between security aware name servers and
resolvers in a way specified in this document.
A security aware resolver is a resolver which can retrieve
authenticated DNS data in secure zones. A security aware resolver is
configured with a list of security aware name servers which is
considered to be reliable. The actual mechanism for the
communication between a security aware resolver and relied name
server should be identical or parallel to secure IP and its detail is
not discussed in this document. The problem is that security aware
resolver can not rely on secure DNS. So, if secure IP relies on
secure DNS, the security aware resolver should use statically
configured information, instead.
The protocol in this document is carefully designed so that existing
name servers can cooperate with security aware resolvers and name
servers.
2. Changes to the Existing Mechanism
Important changes to the existing DNS architecture described in RFC
1034 and RFC 1035 are:
A new OPCODE, NCQUERY, is added to retrieve authentication
information of a node containing CNAME. As authentication
information on a node of CNAME is added as other records of the
node, it is necessary to have an opcode to suppress CNAME
processing. As a side effect, it is now possible to have a zone
which consists of a single CNAME node, which also have SOA and NS
records. [Note: Though it is possible to add new query types
which matches CNAME and other RRs in the node, it is not so clean.
Moreover, as authentication data is usually large, it may cause
UDP packetsize overflow].
SD (Security Desired) bit is added to DNS packets for query.
Though a name server is free to ignore the bit, the secure
resolvers expects their reliable name servers return secure
answer. The bit may also affect additional section processing.
SA (Security Assured) bit is added to DNS packets for answer,
which means that a name server who answers the question assures
that all the data in the answer section is secure.
M. Ohta Expires on Feb. 8, 1995 [Page 3]
INTERNET DRAFT Simple Secure DNS August 1994
MINTTL fields of SOA RRs no longer mean the actual minimal TTLs
nor negative caching periods. They, instead, mean default TTLs.
Cases are canonicalized to use only upper case characters. Lower
case characters are converted to upper case in primary servers.
The canonicalization is necessary to compute a consistent
signature or digest value.
3. New Data Types
New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG
and ZL are added to secure zones. Actual RR type names or values for
the data and their syntax may vary according to specific
authentication algorithm. Detailed explanation, including the actual
RR type values for new data types, are not given in this document.
Square bracketed notation "[RR]" is used to designate a instance of a
new data type "RR".
In general, data size for authentication is often as large as of 100
bytes or more. So, it is a bad idea to share a single RR type value
between different authentication mechanisms, because querying them
all will often break 512 byte limit of UDP query. So, authentication
algorithms are distinguished by RR type values, not by something like
an algorithm type field.
RRD (RR Digest)
Digest value of all the data with a certain RR type in a secure
node.
[RRD] RRs have the following syntax (<class> and <ttl> are omitted
throughout the document):
<node> [RRD] <type> <ottl> <digest>
where [RRD] is the RR name of RRD, <digest> is the digest of all
the resource records of type <type> of node <node>. <ottl> is the
original TTL value of the records.
<type> is a 16 bit quantity, <ottl> is a 32 bit quantity, <digest>
is of variable length.
When computing <digest>, records are represented in binary form in
DNS packet without domain name compression. If there are multiple
records of the same <type>, they are sorted with dictionary order,
comparing the first bytes first with unsigned arithmetic. When
verifying the digest of received data in resolvers and name
servers, TTL field of the records, which should be decreased
M. Ohta Expires on Feb. 8, 1995 [Page 4]
INTERNET DRAFT Simple Secure DNS August 1994
already, should be replaced with <ottl> (original TTL). When
caching authenticated data, name servers and resolvers should
confirm that the TTL in the answer packet does not exceed the
<ottl> value in RRD data.
A node, in general, has multiple [RRD] record for each RR type the
node has. But, it is impossible and unnecessary to cover <type>s
of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD]
of such <type>s as protection against denial service attacks, that
is, to authenticate negative response of non existing RR types.
An [RRD] record for [NSIG] or [ZSIG] RR has the <digest> field of
length zero. To compute <digest> of [RRD] RR type itself, the
<digest> field of the record itself is first considered to have
zero length (including length field of the record) and later
replaced with the actual digest length and value.
NSIG (Node SIGnature)
Signature on RRD computed using secret information of the zone,
added to secure nodes.
[NSIG] RRs have the following syntax:
<domain> [NSIG] <timestamp> <expire> <signature>
where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or
KERBEROS), <timestamp> is the time when the signature is computed.
<expire> is the number of seconds the signature will be valid
after <timestamp>.
<timestamp> and <expire> are 32 bit quantities. <signature> is of
variable length. Throughout the document, time is a 32 bit
quantity, unless otherwise specified. Absolute time is counted by
the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and
wraps around after 2^32 seconds (about 136 years). As the 32 bit
time value circulates, zone's secret information should be changed
at least once per 50 years. Otherwise, stale data signed 136 years
ago may be distributed with a valid signature.
When computing <signature>; <timestamp>, <expire> and <digest> of
[RRD] are serialized with the byte order used in DNS packets and
the resulting byte stream is signed by the zone's signature
mechanism(s).
No NSIG records are provided for non-authoritative data for a zone
such as referral information. Thus, if a name server is
compromised or its IP address is used by an attacker, it is
possible to implant false referral information to a resolver.
M. Ohta Expires on Feb. 8, 1995 [Page 5]
INTERNET DRAFT Simple Secure DNS August 1994
Still, as child zones have its own information, ZSIG (Zone
SIGnature) described later, to authenticate themselves, the
attacked resolver can detect that the referral information is
bogus. The result is no worse than a simple denial of service
attack by compromising name servers of the parent zone. That is,
it is not necessary nor meaningful to try to authenticate referral
NSes or glue A records for child zones.
ZA (Zone Authenticator)
Data added to a secure zone to specify how to verify NSIGs of
nodes within the zone.
[ZA] RRs have the following syntax:
<domain> [ZA] <valid from> <authenticator>
where [ZA] is the RR name of ZA, <valid from> is the time from
when the <authenticator> is used. <valid from> is 32 bit absolute
time. <authenticator> is of variable length. The actual content
of <authenticator> varies by the authentication algorithm. It may
be a public key of the zone or IP addresses of authentication
centers of the zone which maintains secret information of related
parties.
<valid from> field is useful to smoothly change zone's secret
information. Usually, a zone has only one record of [ZA] type.
But, a zone may have two such records when zone's secret
information is being changed. Otherwise, authentication of RRs
signed before the change fails with a new <authenticator>. If
multiple [ZA]s exist during the transition, <timestamp> field of
NSIG is compared to the <valid from> fields in [ZA]s to select the
[ZA] actually used for the signature. Older [ZA] should disappear
after all the signature signed with it is assured to have expired.
ZSIG (Zone SIGnature)
Data added to a secure zone to specify how to verify ZA of the
zone.
ZSIG data contains a signature of digest of the zone's ZA signed
by other secure zones, typically its parent zone.
[ZSIG] RRs have the following syntax.
<node> [ZSIG] <signer> <[NSIG]> <timestamp> <expire>
<signature>
M. Ohta Expires on Feb. 8, 1995 [Page 6]
INTERNET DRAFT Simple Secure DNS August 1994
where [ZSIG] is the RR name of ZSIG data, <signer> is a domain
name of a zone who signs [ZA], <[NSIG]> is the methods used for
signature (represented in RR type) used by the <signer>.
<timestamp>, <expire> and <signature> are the same as that of
[NSIG] except that the signature covers the sequence of
<timestamp> <expire> <digest>, where <digest> is the <digest>
field of [RRD] of [ZA] a signed zone.
In general, only a <signer> who is a parent or ancestor of the
signed zone or the root zone should be considered to be secure,
though local administrator may add or remove reliable <signer>s
according to their local security policy. For the root zone or
locally reliable zones, name servers should be statically
configured with information to authenticate [ZSIG].
ZL (Zone List)
data used to store sorted list of all the nodes in a zone. The
information is necessary for protection against denial of service
attacks, that is, if a node does not appear in certain ZLs, a
negative response that a queried node does not exist is
authenticated. The simplest way to authenticate negative answer
that some data does not exist is to have an authenticated list of
all the existing data. But, unless the number of existing data is
expected to be small, as in the case with [RRD], listing up is
inefficient. Especially, for a very large zone such as "com.",
the size of the list is impractically large. So, existing data
are sorted in a certain order and segmented appropriately into
multiple ZL records. To authenticate the non-existence of a node,
only a ZL RR containing the node (according to the sorting order)
needs to be returned. To not to cause UDP size overflow, ZL RRs
are intended to be returned as a partial RR in the additional
section of a negative answer with truncation bit set. To
authenticate a partial ZL RR, it is necessary to attach
authentication signatures to individual ZL RRs. With wildcarding,
actual authentication is a little more complicated and is
discussed in section 5.3: "Resolver Algorithm".
ZL will have the following syntax.
<zone> [ZL] <nttl> <first> <last> <n> <domain name #1> ...
<domain name #n> <timestamp> <expire>
<signature>
where [ZL] is the RR name of ZL data, <nttl> is the number of
seconds appropriate for negative caching, <n> is the number of
domains covered by the record. The record contains all the domain
M. Ohta Expires on Feb. 8, 1995 [Page 7]
INTERNET DRAFT Simple Secure DNS August 1994
names of the zone (including the top level nodes of child zones
but excluding the zone name itself) after (or including) <first>
and before <last> sorted with dictionary order. <first> and
<last> is merely a separator and should not be interpreted that
such a node exists unless explicitly listed as <domain name #1>.
Comparison is performed first label by label. Top level labels
are compared first and the leaf labels are compared last, which
makes domain name compression work quite well. Within labels,
first bytes are compared first. Thus, the name of the zone is
ordered before all the other names in the domain. For the
comparison purpose, when the name of the zone itself appears as
<last>, it is considered to be ordered after all the other names
in the domain. For example,
<zone> [ZL] <nttl> <zone> <zone> 0 <timestamp> <expire>
<signature>
represents a zone consisting of only a single node.
<nttl> and <n> are two byte integers. <first>, <last>, <domain
name #1>, ..., <domain name #n> have the syntax of domain names.
To make an authenticated response of non existent node resides
within 512 byte UDP packet, it is recommeded that the length of a
single [ZL] record be shorter than 400 bytes, after limited domain
name compression (those information available within the record
itself only, may be shared for compression).
<timestamp>, <expire> and <signature> are the same as that of
[NSIG] except that the signature covers the byte stream of the
sequence of <timestamp> <expire> <nttl> <first> <last> <n> <domain
name #1> ... <domain name #n> contained in the [ZL] record
itself.
4. Name Server Operation
Changes to the operation of name servers is minimal.
A primary name server of a zone has access to signature mechanisms of
the zone and derives authenticated data from them.
A secondary name server is configured with IP addresses of other name
servers from which zone information is transferred. It also have
digest of ZA to authenticate zone transfers. So, if the primary
server is compromised, secondary servers can detect it and reject
bogus zone transfers and can continue operation with older
information.
M. Ohta Expires on Feb. 8, 1995 [Page 8]
INTERNET DRAFT Simple Secure DNS August 1994
The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the
following description:
The actual algorithm used by the secure name server will depend on
the local OS and data structures used to store RRs. The following
algorithm assumes that the RRs are organized in several tree
structures, one for each zone, and another for the cache:
0. If SD bit is not set, use the original algorithm in RFC
1034. Otherwise, set SA bit.
1. Set or clear the value of recursion available in the
response depending on whether the name server is willing to
provide recursive service. If recursive service is
available and requested via the RD bit in the query, go to
step 5, otherwise step 2.
2. Search the available secure zones for the zone which is the
nearest ancestor to QNAME. If such a zone is found, go to
step 3, otherwise step 4.
3. Start matching down, label by label, in the zone. The
matching process can terminate several ways:
a. If the whole of QNAME is matched, we have found the
node.
If the data at the node contains a CNAME, and QTYPE
doesn't match CNAME and OPCODE is not NCQUERY, copy
the CNAME RR into the answer section of the response,
change QNAME to the canonical name in the CNAME RR,
and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
b. If a match would take us out of the authoritative
data, we have a referral. This happens when we
encounter a node with NS RRs marking cuts along the
bottom of a zone.
Copy the NS RRs for the subzone into the authority
section of the reply. Put authenticated addresses
available from authoritative data or the cache. If
they are unavailable, use glue RRs, if they exists.
Go to step 4.
c. If at some label, a match is impossible (i.e., the
M. Ohta Expires on Feb. 8, 1995 [Page 9]
INTERNET DRAFT Simple Secure DNS August 1994
corresponding label does not exist), look to see if a
"*" label exists.
If the "*" label does not exist, check whether the
name we are looking for is the original QNAME in the
query or a name we have followed due to a CNAME. If
the name is original, set an authoritative name error
in the response. Put at least one RR of ZL data
containing the name being looked for in the additional
section. If there are a lot of ZL data, truncation is
expected. Exit.
If the "*" label does exist, match RRs at that node
against QTYPE. If any match, copy them into the
answer section, but set the owner of the RR to be
QNAME, and not the node with the "*" label unless the
query type is of [RRD]. Go to step 6.
4. Start matching down in the cache. If authenticated QNAME is
found in the cache, copy all authenticated RRs attached to
it that match QTYPE into the answer section. If there was
no delegation from authoritative data, look for the best one
from the cache, and put it in the authority section. Go to
step 6.
5. Using the local resolver or a copy of its algorithm (see
resolver section of this document) answer the query and set
or reset SA bit appropriately. Store the results, including
any intermediate CNAMEs, in the answer section of the
response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
For secure zone transfer, new query types [SXFR] are added. The
actual name and value of [SXFER] depends on the authentication
mechanism used. It is assumed that each secondary server is
statically configured with digest of ZA of a zone it serves. A
secure zone transfer is a byte stream with the following structure.
+------------------+ ^
| length | |d
+------------------+ |i
| | |g
| | |e
| zone data | |s
| | |t
| | |e
M. Ohta Expires on Feb. 8, 1995 [Page 10]
INTERNET DRAFT Simple Secure DNS August 1994
+------------------+ vd ^
| timestamp | |s
+------------------+ |i
| expire | |g
+------------------+ |n
| digest | |e
+------------------+ vd
| signature |
+------------------+
The secondary server extract [ZA] records which is just transferred,
verify it with statically configured digest, and authenticate the
signature of the transferred zone. Unlike AXFER, [SXFER] uses four
bytes for zone data length to transfer large zones such as "com.".
5. Resolver
5.1 Client-Resolver Interface
Client programs tells security requirements to the resolver. The
requirement includes whether they need security or not and which
digesting or signature mechanism they consider reliable.
5.2. Data Structures
The resolver algorithm in the next subsection assumes that all
functions have been converted to a general lookup function, and uses
the following data structures to represent the state of a request in
progress in the resolver:
SNAME the domain name we are searching for.
STYPE the QTYPE of the search request.
SCLASS the QCLASS of the search request.
SLIST a structure which describes the name servers and the
zone which the resolver is currently trying to query.
This structure keeps track of the resolver's current
best guess about which name servers hold the desired
information; it is updated when arriving information
changes the guess. This structure includes the
equivalent of a zone name, the known name servers for
the zone, the known addresses for the name servers,
[ZA] and [ZSIG] of the zone if the zone is secure,
and history information which can be used to suggest
which server is likely to be the best one to try
next. The zone name equivalent is a match count of
M. Ohta Expires on Feb. 8, 1995 [Page 11]
INTERNET DRAFT Simple Secure DNS August 1994
the number of labels from the root down which SNAME
has in common with the zone being queried; this is
used as a measure of how "close" the resolver is to
SNAME.
SBELT a "safety belt" structure of the same form as SLIST,
which is initialized from a configuration file, and
lists servers which should be used when the resolver
doesn't have any local information to guide name
server selection. The resolver thinks those name
servers reliable. The configuration file also
contains information, such as shared secret or digest
of public key, for authenticated communication to the
reliable name servers. The match count will be -1 to
indicate that no labels are known to match.
CACHE A structure which stores the results from previous
responses. Since resolvers are responsible for
discarding old RRs whose TTL has expired, most
implementations convert the interval specified in
arriving RRs to some sort of absolute time when the
RR is stored in the cache. Instead of counting the
TTLs down individually, the resolver just ignores or
discards old RRs when it runs across them in the
course of a search, or discards them during periodic
sweeps to reclaim the memory consumed by old RRs.
The cache also contains information whether the RR is
considered to be authenticated by the resolver. In
the CACHE, authenticated RR has precedence over
unauthenticated RR.
5.3 Resolver Algorithm
The four step algorithm in the section "5.3.3. Algorithm" of RFC 1034
must be replaced with the following:
The top level algorithm has four steps:
1. See if the answer is in local secure information, and if so
return it to the client.
2. Find the best servers to ask.
3. Send them queries with SD bit set until one returns a
response.
4. Analyze the response, either:
M. Ohta Expires on Feb. 8, 1995 [Page 12]
INTERNET DRAFT Simple Secure DNS August 1994
a. if the response answers the question or contains a
name error, try to authenticate it, cache the data and
other authentication information as well as returning
the answer back to the client.
b. if the response contains a better delegation to other
servers, try to retrieve and authenticate ZSIG and ZA
of the delegated zone. If the delegation information
is authenticated, put it to local cache and go to step
2.
c. if the response shows a CNAME and that is not the
answer itself, try to authenticate the CNAME, cache
the CNAME and other authentication information, change
the SNAME to the canonical name in the CNAME RR and go
to step 1.
d. if the response shows a servers failure, an
authentication failure or other bizarre contents,
delete the server from the SLIST and go back to step
3.
Authentication by resolvers are done as follows:
1. If the answer is obtained from one of the trusted name
servers through authenticated communication channel and SA
bit is set, or if the answer is in the authoritative data of
the name server co-located with the resolver, no
authentication is necessary.
2. For NSIG or ZSIG, no authentication check is necessary,
though authentication failure with cached NSIG or ZSIG
should invalidate the cached information.
3. To authenticate RRD, use NSIG and authenticated ZA.
4. To authenticate ZL, use authenticated ZA.
5. To authenticate ZA, use RRD of ZA and ZSIG.
6. To authenticate other data types, use authenticated RRD. If
the query for RRD returns wildcard, it should also be
confirmed that there is no nodes exists to make the wildcard
matching impossible. For example, if "a.b.c.d." matches
"*.c.d." it should be confirmed that nodes "a.b.c.d." nor
"b.c.d." does not exit but a wild card "*.c.d." exists. ZL
which exists in the additional section should give the
required authentication for non-existent nodes.
M. Ohta Expires on Feb. 8, 1995 [Page 13]
INTERNET DRAFT Simple Secure DNS August 1994
7. if the response is a name error, that is, a node which
matches query does not exist, confirm it by authenticating
ZL data in the additional section of the response. For
example, to authenticate that data matching "a.b.c.d." dose
not exist in a zone "c.d.", it should be confirmed that
nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d."
does exist. Depending on the zone's structure (whether
"b.c.d." exists or not), the same thing may be confirmed by
the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and
"*.c.d" do not exist.
8. if the response is a data not found error, that is, the
query does not match any RR type of the node, retrieve all
the authenticated RRD type records of the node and confirm
that they don't contain RR types which matches the query.
Authentication chains between zones have the following structure:
digest
ZA of well known signer zone------>digest value statically
| configured in name
| servers
|
signature
ZSIG<---------RRD of ZA of signer zone
|
|
|
signature
ZSIG<---------RRD of ZA of signer zone
|
|
|
signature
ZSIG<----------RRD of ZA
Figure 1. Authentication Chains of Zone Data
Authentication chains within a zone have the following structure:
ZA of the Node's Zone
|
|
|
signature
M. Ohta Expires on Feb. 8, 1995 [Page 14]
INTERNET DRAFT Simple Secure DNS August 1994
NSIG<---------RRD of RR type RRD
^
|digest
|
RRD of RR type <type>
^
|digest
|
RR with RR type <type>
other than RRD nor NSIG
Figure 2. Authentication Chain of Node Data
5. Secure Time and Secure DNS
DNS is designed to be highly fault tolerant. That is, if a secondary
server can't communicate with other servers, the secondary server can
behave as authoritative until SOA <expire> period is reached. Thus,
until a resolver securely knows that <expire> period has passed, a
name server may give old but authenticated answer to a query whose
node does not exist.
Thus, <expire> period should be minimized. Moreover, clocks of
signers and resolvers should be accurate enough. It is recommended
that signers clock should have maximum allowable error of
<expire>/20. When resolvers caching information, it should be
confirmed that cached period is shorter than <ottl> and
<expire>*19/20 fractions rounded down minus the expected maximum
error of the resolvers' clocks.
Due to clock skew, a resolver may receive a <timestamp> dated in the
future. The data should be relied if the error is below <expire>/10
fractions rounded down plus the expected maximum error of the
resolver's clocks.
To have an Internet wide upper bound on the life time of stale data,
<expire> longer than a week should be shortened to a week.
6. Secure DNS and Additional Section Processing
To authenticate DNS reply on a certain node, a lot of information
about the node is necessary. Such information may be provided in the
additional section.
On the other hand, though the existing DNS suggests to add various
information in the additional section, data on nodes which is not
queried needs, such as additional As for MX, are not so useful if
M. Ohta Expires on Feb. 8, 1995 [Page 15]
INTERNET DRAFT Simple Secure DNS August 1994
they can't be authenticated.
Thus, for secure DNS, it is recommended to add additional information
with the following preference as long as the addition won't make the
reply longer than 512 bytes.
[ZL] data for protection against denial of service attacks.
glue A records for referral.
additional information on the queried node.
other additional information.
7. Specification of a Secure DNS Architecture
To specify secure DNS, a standard track RFC(s) must be provided which
specify
a mechanism for digesting
a mechanism for signature
RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG]
and [SXFR]
Ranges of 256 RR type values are reserved by IANA for the actual
values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows:
[RRD] X
[NSIG] X+256
[ZA] X+512
[ZSIG] X+768
[ZL] X+1024
[SXFR] X+1280
where X is between Y and Y+255 (Y is to be determined by IANA).
[RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value
of X form a single set of specification.
Even if two specifications share the same digesting or signature
mechanism, they have different [RRD] or [NSIG] values.
8. References
[RFC1034]
M. Ohta Expires on Feb. 8, 1995 [Page 16]
INTERNET DRAFT Simple Secure DNS August 1994
[RFC1035]
Security Considerations
The entire document is devoted on a security issue to make answers
from DNS authenticated over unreliable transport mechanisms.
No confidentiality is considered.
Author's Address
Masataka Ohta
Computer Center
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo 152, JAPAN
Phone: +81-3-5499-7084
Fax: +81-3-3729-1940
EMail: mohta@cc.titech.ac.jp
M. Ohta Expires on Feb. 8, 1995 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 13:06:36 |