1 - 2 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - Z
DNS
Click on the red underlined text to get to the source
...
This document describes extensions of the Domain Name System (DNS)
protocol to support DNS security and public key ...
... Domain Name System (DNS)
protocol to support DNS security and public key distribution. It
assumes that the reader is familiar with the Domain Name System ...
... Section 3 discusses the KEY resource record, its structure, use in
DNS responses, and file representation. These resource records
represent the public keys ...
... resource records
represent the public keys of entities named in the DNS and are used
for key distribution.
...
... digital signature resource record, its
structure, use in DNS responses, and file representation. These
resource records are used to authenticate ...
... authenticate other resource records in
the DNS and optionally to authenticate DNS transactions ...
... Section 5 discusses the NXT resource record and its use in DNS
responses. The NXT RR permits authenticated denial in the DNS ...
... DNS
responses. The NXT RR permits authenticated denial in the DNS of the
existence of a name or of a particular type for an existing name.
...
... Section 6 discusses how a resolver can be configured with a starting
key or keys and proceed to securely resolve DNS requests.
Interactions between resolvers and servers are discussed for all
combinations of security ...
... Overview of the DNS Extensions ...
...
It is part of the design philosophy of the DNS that the data in it is
public and that the DNS gives the same answers to all inquirers.
...
... It is part of the design philosophy of the DNS that the data in it is
public and that the DNS gives the same answers to all inquirers.
...
... Resource records (RRs) are defined to associate keys with DNS names.
This permits the DNS to be used as a public key ...
... RRs) are defined to associate keys with DNS names.
This permits the DNS to be used as a public key distribution
mechanism in support of the DNS data ...
... DNS to be used as a public key distribution
mechanism in support of the DNS data origin authentication and other
security services ...
...
Under conditions described in Section 3.7, security aware DNS servers
will automatically attempt to return KEY resources as additional
information, along with those resource records ...
... Authentication is provided by associating with resource records in
the DNS cryptographically generated digital signatures. Commonly,
there will be a single private key ...
... A resolver can learn the public key of a zone either by reading it
from DNS or by having it staticly configured. To reliably learn the
public key by reading it from DNS ...
... DNS or by having it staticly configured. To reliably learn the
public key by reading it from DNS, the key itself must be signed.
Thus, to provide a reasonable degree of security, the resolver must
...
... signatures. From there, it can securely read the
public keys of other zones, if the intervening zones in the DNS tree
are secure and their signed keys accessible. (It is in principle
...
... data origin authentication and integrity requires no change to
the "on-the-wire" DNS protocol beyond the addition of the signature
resource type and, as a practical matter, the key resource type
...
... supporting the performance enhanced version of the DNS protocol
security extensions will attempt to return, with RRs retrieved, the
...
...
DNS security would like to view each zone as a unit of data
completely under the control of the zone owner and signed by the
zone's key. But the operational DNS ...
... DNS security would like to view each zone as a unit of data
completely under the control of the zone owner and signed by the
zone's key. But the operational DNS views the leaf nodes in a zone,
which are also the apex nodes ...
... security aware servers MUST be used to securely CNAME in
DNS. Security aware servers must (1) allow KEY, SIG, and NXT ...
... encountered in resolving a query. This is a change from the previous
DNS standard which prohibited any other RR type at a node where a
...
... The public key of the entity must be present in the DNS and be
appropriately signed but the other RR(s) may be signed with the
...
... service described above protects
retrieved resource records but provides no protection for DNS
requests or for message headers.
...
... RR at
the end of the request. Authenticating requests serves no function
in the current DNS and requests with a non-empty additional
information section are ignored by almost all current DNS servers.
...
... in the current DNS and requests with a non-empty additional
information section are ignored by almost all current DNS servers.
However, this syntax for signing requests is defined in connection ...
... involved. The corresponding public key is normally stored in and
retrieved from the DNS.
...
... RR) is used to document a key that is
associated with a Domain Name System (DNS) name. It will be a public
key as only public keys are stored in the DNS ...
... DNS) name. It will be a public
key as only public keys are stored in the DNS. This can be the
public key of a zone, a host ...
... RR. Security aware
DNS implementations MUST be designed to handle at least two
simultaneously valid keys of the same type associated with a name.
...
... Object Types, DNS Names, and Keys ...
...
This DNS name may refer to up to three different categories of
things. For example, dee.cybercash.com could be (1) a zone, (2) a
host ...
... host or other end entity , and (3) the mapping into a DNS name of the
user or account dee@cybercash.com. Thus, there are flags, as
described below, in the KEY RR ...
... authentication and/or
confidentiality is permitted. Note that DNS security makes use of
keys for authentication only. Confidentiality ...
... RR owner name. This will commonly be
a host but could, in some parts of the DNS tree, be some other type
of entity such as a telephone number ...
... RFC1530]. This is the public
key used in connection with the optional DNS transaction
authentication service ...
... transaction
authentication service if the owner name is a DNS server host. It
could also be used in an IP ...
... for the zone whose name is the KEY RR owner name. This is the public
key used for DNS data origin authentication.
...
... differences in their meaning are reserved for definition in
connection with DNS dynamic update or other new DNS commands. Zone
keys ...
... connection with DNS dynamic update or other new DNS commands. Zone
keys always have authority to sign any RRs ...
...
It is anticipated that some keys stored in DNS will be used in
conjunction with Internet protocols ...
... conjunction with Internet protocols other than DNS (keys with zone
bit or signatory field non-zero ...
...
It is intended that new uses of DNS stored keys would initially be
implemented, and operational experience gained, using the
experimental ...
... algorithm will only
be used in connection with some modes of DNS dynamic update. For
number 253, the public key ...
... flag bit
being on or the signatory field being non-zero is effectively a DNS
protocol flag on.) The meaning of these combinations is indicated
below:
...
...
Security aware DNS servers MUST include KEY RRs as additional
information in responses where appropriate including the following:
...
... that data is authenticated in the secure Domain Name System (DNS). As
such it is the heart of the security provided.
...
... algorithm
could have a major impact on the interoperability of the global DNS
system and requires an IETF standards action. Number 254 is reserved
for private use ...
... algorithm will only be
used in connection with some modes of DNS dynamic update. For number
253, the signature ...
... SIG RR must be considered corrupt and ignored. The
maximum number of labels allowed in the current DNS is 127 but the
entire octet is reserved and would be required should DNS names ever
...
... maximum number of labels allowed in the current DNS is 127 but the
entire octet is reserved and would be required should DNS names ever
be expanded to 255 labels. The following table gives some examples.
The value of "labels" is at the top, the retrieved owner name on the
...
... authenticated. The signer's name may be compressed
with standard DNS name compression when being transmitted over the
network ...
... encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem, the original plain text can be
easily recovered. This weakness is not significant for DNS because
we seek only authentication, not confidentiality ...
... RR
type. It is calculated by using a "data" (see Section 4.1.2) of the
entire preceding DNS reply message, including DNS header but not the
...
... entire preceding DNS reply message, including DNS header but not the
IP header, concatenated with the entire DNS query ...
... DNS header but not the
IP header, concatenated with the entire DNS query message that
produced this response, including the query's DNS header ...
... DNS query message that
produced this response, including the query's DNS header but not its
IP header. That is
...
...
A DNS request may be optionally signed by including one or more SIGs
at the end of the query. Such SIGs are identified by having a "type
...
... at the end of the query. Such SIGs are identified by having a "type
covered" field of zero. They sign the preceding DNS request message
including DNS header ...
... DNS request message
including DNS header but not including the IP header or at the
begining or any preceding request SIGs at the end. Such request SIGs
...
... WARNING: Request SIGs are unnecessary for currently defined queries
and will cause almost all existing DNS servers to completely ignore a
query. However, such SIGs may be needed to authenticate ...
... query. However, such SIGs may be needed to authenticate future DNS
secure dynamic update or other requests.
...
... (Section 4.1.4). Such SIG RRs are signed by the DNS server
originating the response. Although the signer field MUST be the
...
... signatures have expired. Within that
constraint, servers should continue to follow DNS TTL aging. Thus
authoritative servers should continue to follow the zone refresh and
...
...
The domain name may be compressed with standard DNS name compression
when being transmitted over the network ...
... Retrieving or resolving authentic data from the Domain Name System
(DNS) involves starting with one or more trusted public keys for one
...
... or more zones. With trusted keys, a resolver willing to perform
cryptography can progress securely through the secure DNS zone
structure to the zone of interest as described in Section 6.3. Such
trusted public keys ...
...
Two previously unused bits are allocated out of the DNS
query/response format header. The AD ...
... AD bit unless they trust the server they are talking to and
either have a secure path to it or use DNS transaction security.
...
... the root zone, this has problems. The logistics of updating every
DNS resolver in the world when the root key changes would be
excessive. It may be some time before there even is a root ...
... root key.
Furthermore, many organizations will explicitly wish their "interior"
DNS implementations to completely trust only their own zone. Such
interior resolvers can then go through the organization's zone
...
... servers to access data outsize the organization's domain and should
only be configured with the key forthe organization's DNS apex.
...
...
If legitimate non-secure zones are encountered in traversing the DNS
tree, then no zone can be trusted as secure that can be reached only
via information from such non-secure zones. Since the non-secure ...
... via such zones could be set to 512 or more as this exceeds the
largest possible distance through secure zones in the DNS.
Nevertheless, continuing to apply secure checks within "secure" zones
reached via non-secure ...
... that reasonably consistent time be available to the hosts
implementing the DNS security extensions.
...
... This section discusses a variety of considerations in secure
operation of the Domain Name System (DNS) using these protocol
extensions.
...
... There are a number of factors that effect public key size choice for
use in the DNS security extension. Unfortunately, these factors
usually do not all point in the same direction. Choice of zone key
...
... SIG RRs. This
increases the chance of DNS UDP packet overflow and the possible
necessity for using higher overhead ...
... believed by the authors to be secure at this time but high level
zones in the DNS tree may wish to set a higher minimum, perhaps 1000
bits, for security ...
... host or user keys, generally have to
be kept on line to be used for real-time purposes such as DNS
transaction security ...
...
This document describes technical details of extensions to the Domain
Name System (DNS) protocol to provide data integrity and origin
authentication ...
... resource records, including KEY resource records,
retrieved from the DNS. They do not magically solve other security
problems. For example, using secure DNS you can have high confidence
...
... retrieved from the DNS. They do not magically solve other security
problems. For example, using secure DNS you can have high confidence
in the IP address you retrieve for a host name ...