upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-03-02 13:30:44 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

new revs

Browse source
This commit is contained in:
Mark Andrews 2001-11-28 14:26:10 +00:00
parent 5c898d95dc
commit bbc985b36e
4 changed files with 1193 additions and 957 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

618
doc/draft/draft-ietf-dnsext-delegation-signer-01.txt
View file

@ -1,618 +0,0 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT July 2001
<draft-ietf-dnsext-delegation-signer-01.txt>
Updates: RFC 1035, RFC 2535, RFC 3008.
Delegation Signer record in parent.
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on January 15, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
One of the biggest problems in DNS occur when records of the same type
can appear on both sides of an delegation. If the contents of these
sets differs clients can get confused. RFC2535 KEY records follows
the same model as for NS records, parent is responsible for the
records but the child is responsible for the contents. This document
Gudmundsson Expires January 2002 [Page 1]
INTERNET-DRAFT Delegation Signer Record July 2001
proposes to store a different record in the parent that specifies
which one of the child's keys are authorized to sign the child's KEY
set. This change is not backwards compatible with RFC2535 but
simplifies DNSSEC operation.
1 - Introduction
Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535] and DNSSEC terminology [RFC3090] is important.
When the same data can reside in two administratively different DNS
zones sources it is common that the data gets out of sync. NS record
in a zone indicates that there is a delegation at this name and the NS
record lists the authorative servers for the real zone. Based on
actual measurements 10-30% of all delegations in the Internet have
differing NS sets at parent and child. There are number of reasons for
this, including lack of communication between parent and child and
bogus name-servers being listed to meet registrar requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its
KEY set signed by the parent to create a verifiable chain of KEYs.
There is some debate, where the signed KEY set should reside,
parent[Parent] or child[RFC2535]. If the KEY set resides at the child,
frequent communication is needed between the two parties, to transmit
key sets up to parent and then the signed set or signatures down to
child. If the KEY set resides at the parent[Parent] the communication
is reduced having only child send updated key sets to parent.
DNSSEC[RFC2535] requires that the parent store NULL key set for
unsecure children, this complicates resolution process as in many
cases as servers for both parent and child need to be queried for KEY
set the [Parent] proposal simplifies this.
Further complication of the DNSSEC KEY model is that KEY record is
used to store DNS zone keys and public keys for other protocols. This
can lead to large key sets at delegation points. There are number of
potential problems with this including:
1. KEY set may become quite large if many applications/protocols store
their keys at the zone apex. Example of protocols are IPSEC, HTTP,
SMTP, SSH etc.
2. Key set may require frequent updates.
3. Probability of compromised/lost keys increases and triggers
emergency key rollover.
4. Parent may refuse sign key sets with NON DNS zone keys.
5. Parent may not have QoS on key changes that meets child's
expectations.
Gudmundsson Expires January 2002 [Page 2]
INTERNET-DRAFT Delegation Signer Record July 2001
Given these and other reasons there is good reason to explore
alternatives to using only KEY records to create chain of trust.
Some of these problems can be reduced or eliminated by operational
rules or protocol changes. To reduce the number of keys at apex, rule
to require applications to store their KEY records at the SRV name for
that application is one possibility. Another is to restrict KEY record
to DNS keys only and create a new type for all non DNS keys. Third
possible solution is to ban the storage of non DNS related keys at
zone apex. There are other possible solutions but they are outside the
scope of this document.
1.1 - Delegation Signer Record model
This document proposes an alternative to the KEY record chain of
trust, that uses a special record that can only reside at the parent.
This record will identify the key(s) that child will use to self sign
its own KEY set.
The chain of trust is now established by verifying the parent KEY set,
the DS set from the parent and then the KEY set at the child. This is
cryptographically equivalent to just using KEY records.
Communication between the parent and child is reduced as the parent
only needs to know of changes in DNS zone KEY(s) used to sign the apex
KEY set. If other KEY records are stored at the zone apex, the parent
does not need to be aware of them.
This approach has the advantage that it minimizes the communication
between the parent and child and the child is the authority for the
KEY set with full control over the contents. This enables each to
operate and maintain each zone independent of each other. Thus if
child wants to have frequent key rollover for its DNS keys parent does
not need to be aware of it as the child can use one key to only sign
its apex KEY set and other keys to sign the other record sets in the
zone. The child can just as well use the same key to sign all records
in its zone.
Another advantage is that this model fits well with slow rollout of
DNSSEC and islands of security model. In the islands of security model
someone that trusts "good.example." preconfigures a key from
"good.example." as a trusted keys and from then on trusts any data
that is signed by that key or has a chain of trust to that key. If
"example." starts advertising DS records "good.example." does not have
to change operations, by suspending self-signing. If DS records can
also be used to identify trusted keys instead of KEY records.
Gudmundsson Expires January 2002 [Page 3]
INTERNET-DRAFT Delegation Signer Record July 2001
The main disadvantage of this approach is double the number of
signatures that need to be verified for the each delegation KEY set.
There is no impact on verifying other record sets.
1.2 - Reserved words
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document
are to be interpreted as described in RFC2119.
2 - DS (Delegation KEY signer) record:
2.1 Protocol change
DS record MUST only appear at secure delegations in the parent zone.
The record lists the child's keys that SHOULD sign the child's key
set. Insecure delegation MUST NOT have a DS record, the presence of
DS record SHOULD be considered a hint that the child might be secure.
Resolver MUST only trust KEY records that match a DS record.
NOTE: It has been suggested that NULL DS record for insecure children
is better than no record. The advantage is to have authenticated
denial of child's security status, the drawback is for large
delegating zones there will be many NULL DS records. If parent uses
NXT records adding NXT record to the authority section in the cases
when no DS record exists at delegation will give the same result as
NULL DS record.
WG please comment on which approach is better.
Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section
2.7: Delegating zones MUST NOT store KEY records for delegations. The
only records that can appear at delegation in parent are NS, SIG, NXT
and DS.
Zone MUST self sign its apex KEY set, it SHOULD sign it with a key
that corresponds to a DS record in the parent. The KEY used to sign
the apex KEY RRset CAN sign other RRsets in the zone.
If child apex KEY RRset is not signed with one of the keys specified
in the DS record the child is locally secure[RFC3090] and SHOULD only
be considered secure the resolver has been instructed to trust the key
used, via preconfiguration.
Authorative server answering a query, that has the OK bit set[OKbit],
MUST include the DS set in the additional section if the answer is a
referral and there is space. Caching servers SHOULD return the DS
record in the additional section under the same condition.
Gudmundsson Expires January 2002 [Page 4]
INTERNET-DRAFT Delegation Signer Record July 2001
2.1.1 - Comments on protocol change
Over the years there has been various discussions on that the
delegation model in DNS is broken as there is no real good way to
assert if delegation exists. In RFC2535 version of DNSSEC the
authentication of a delegation is the NS bit in the NXT bitmap at the
delegation point. Something more explicit is needed and the DS record
addresses this for secure delegations.
DS record is the first DNS record to be only stored at the upper side
of a delegation. NS records appear at both sides as do SIG and NXT.
All other records can only appear at the lower side. This will cause
some problems as servers authorative for parent may reject DS record
even if the server understands unknown types, or not hand them out
unless explicitly asked. Similarly a nameserver acting as a
authorative for child and as a caching recursive server may never
return the DS record. A caching server does not care from which side
DS record comes from and thus should not have to be changed if it
supports unknown types. Different TTL values on the childs NS set and
parents DS set may cause the DS set to expire before the NS set. In
this case an non-DS aware server would ask the child server for the DS
set and get NXDOMAIN answer. DS aware server will know to ask the
parent for the DS record.
Secure resolvers need to know about the DS record and how to interpret
it. In the worst case, introducing the DS record, doubles the
signatures that need to be checked to validate a KEY set.
Note: The working group must determine if the tradeoff between more
work in resolvers is justified by the operational simplification of
this model. The author think this is a small price to pay to have a
cleaner delegations structure. One argument put forward is that DNS
should be optimized for read when ever possible, and on the face of it
adding the DS record makes reading data from DNS more expensive. The
operational complexities and legal hurdles that KEY records in parents
or children make prevent DNSSEC to ever get deployed.
Gudmundsson Expires January 2002 [Page 5]
INTERNET-DRAFT Delegation Signer Record July 2001
2.2 Wire format of DS record
The DS record consists of algorithm, size, key tag and SHA-1 digest of
the public key KEY record allowed to sign the child's delegation.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | SHA-1 digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535, the size is the
size of the public key in bits as specified in the document specifying
the algorithm. Algorithm MUST be an algorithm number assigned in the
range 1..251. The SHA-1 digest is calculated over the canonical name
of the delegation followed by the RDATA of the KEY record.
The size of the DS RDATA is 25 bytes, regardless of the key size.
NOTE: if 160 bits is to large the SHA-1 digest can be shortened but
that weakens the overall security of the system.
2.2.1 Justifications for fields
The algorithm and size fields are here to allow resolvers to quickly
identify the candidate KEY records to examine. Key Tag is to allow
quick check if this is a good candidate. The key tag is redundant but
provides some greater assurance than SHA-1 digest on its own. SHA-1 is
a strong cryptographic checksum, it is hard for attacker to generate a
KEY record that has the same SHA-1 digest. Making sure that the KEY
record is a valid public key is much harder. Combining the name of the
key and the key data as input to the digest provides stronger
assurance of the binding. Combining the SHA-1 with the other fields
makes the task of the attacker is as hard breaking the public key.
Even if someone creates a database of all SHA-1 key hashes seen so
far, the addition of the name renders that database useless for
attacks against random zones.
Gudmundsson Expires January 2002 [Page 6]
INTERNET-DRAFT Delegation Signer Record July 2001
2.3 Presentation format of DS record
The presentation format of DS record consists of 2 numbers, followed
by either the name of the signature algorithm or the algorithm number.
The digest is to be presented in hex.
2.4 Justifications for compact format
This format allows concise representation of the keys that child will
use, thus keeping down the size of the answer for the delegation,
reducing the probability of packet overflow. The SHA-1 hash is strong
enough to uniquely identify the key. This is similar to the PGP
footprint.
Each DS record has RDATA size of 25, regardless of the size of the
keys, keeping the answers from the parent smaller than if public key
was used. The smallest currently defined KEY record RDATA is 70 bytes.
Compact DS format is also better suited to list trusted keys for
islands of security in configuration files.
2.5 Transition issues for installed base
RFC2535 compliant resolver will assume that all DS secured delegations
are locally secure. This is a bad thing, thus it might be necessary
for a transition period to support both DS and SIG@Child. The cost is
one more signatures in the answer and that early adopters have to
cumbersome communications that DS is supposed to solve.
Resolvers will not get confused as they will select signatures with
the KEY they trust and ignore the other one.
3 Resolver Example
To create a chain of trust resolver goes from trusted KEY to DS to
KEY.
Assume the key for domain example. is trusted. In zone "example." we
have
example. KEY <stuff>
secure.example. DS tag=12345 size=1024 alg=dsa <foofoo>
secure.example. NS ns1.secure.example.
NS ns1.secure.example. s
secure.example. NXT NS SIG NXT DS tail.example.
secure.example. SIG(NXT)
secure.example. SIG(DS)
Gudmundsson Expires January 2002 [Page 7]
INTERNET-DRAFT Delegation Signer Record July 2001
In zone "secure.example." we have
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
NS ns1.secure.example.
secure.example. KEY <tag=12345 size=1024 alg=dsa>
KEY <tag=54321 size=512 alg=rsa/sha1>
KEY <tag=32145 size=1024 alg=dsa>
secure.example. SIG(KEY) <key-tag=12345 size=1024 alg=dsa>
secure.example. SIG(SOA) <key-tag=54321 size=512 alg=rsa/sha1>
secure.example. SIG(NS) <key-tag=54321 size=512 alg=rsa/sha1>
In this example the trusted key for example signs the DS record for
"secure.example.", making that a trusted record. The DS record states
what key is supposed to sign the KEY record at secure.example. In
this example "secure.example." has three different KEY records and the
one corresponding to the KEY identified in the DS record signs the KEY
set, thus the key set is validated and trusted. Note that one of the
other keys in the keyset actually signs the zone data, and resolvers
will trust the signatures as the key appears in the KEY set.
This example has only one DS record for the child but there no reason
to outlaw multiple DS records. More than one DS record is needed
during signing key rollover. It is strongly recommended that the DS
set be kept small.
3.1 Resolver cost estimates for DS records
From a RFC2535 resolver point of view for each delegation followed to
chase down an answer one KEY record has to be verified and possibly
some other records based on policy, for example the contents of the NS
set. Once the resolver gets to the appropriate delegation validating
the answer may require verifying one or more signatures. For a simple
A record lookup requires at least N delegations to be verified and 1
RRset. For a DS enabled resolver the cost is 2N+1. For MX record the
cost where the target of the MX record is in the same zone as the MX
record the costs are N+2 and 2N+2. In the case of negative answer the
same holds ratios hold true.
Resolver may require an extra query to get the DS record but and this
may add to the overall cost of the query, but this is never worse than
chasing down NULL KEY records from the parent in RFC2535 DNSSEC.
DS adds processing overhead on resolvers, increases the size of
delegation answers. DS requires much less storage in large delegation
zones than SIG@Parent.
Gudmundsson Expires January 2002 [Page 8]
INTERNET-DRAFT Delegation Signer Record July 2001
4 Acknowledgments
Number of people have over the last few years contributed number of
ideas that are captured in this document. The core idea of using one
key to that has only the role of signing a key set, comes from
discussions with Bill Manning and Perry Metzger on how to put in a
single root key in all resolver that lives for a long time. Brian
Wellington, Dan Massey, Edward Lewis, Havard Eidnes, Jakob Schlyter,
Mark Kosters, Miek Gieben, Roy Arens, Scott Rosen have provided
usefull comments.
4 - Security Considerations:
This document proposes a change to the validation chain of KEY records
in DNS. The change in is not believed to reduce security in the
overall system, in RFC2535 DNSSEC child must communicate keys to
parent and prudent parents will require some authentication on that
handshake. The modified protocol will require same authentication but
allows the child to exert more local control over its own KEY set.
In the representation of DS record, there is a possibility that an
attacker can generate an valid KEY that matches all the checks thus
starting to forge data from the child. This is considered impractical
as on average more than 2**80 keys must be generated before one is
found that will match.
DS record is a change to DNSSEC protocol and there is some installed
base of implementations, as well as text books on how to set up
secured delegations. Implementations that do not understand DS record
will not be able to follow the KEY to DS to KEY chain and consider all
zone secured that way insecure.
5 - IANA Considerations:
IANA needs to allocate RR type code for DS from the standard RR type
space.
Gudmundsson Expires January 2002 [Page 9]
INTERNET-DRAFT Delegation Signer Record July 2001
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
Authority'', RFC 3008, November 2000.
[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
Status'', RFC 3090, March 2001.
[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in
progress <draft-ietf-dnsext-dnssec-okbit-02.txt>, April 2001.
[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone
KEYs'', work in progress <draft-ietf-dnsext-parent-stores-
zones-keys-01.txt>, May 2001.
Author Address
Olafur Gudmundsson
3826 Legation Street, NW
Washington, DC, 20015
USA
<ogud@ogud.com>
Appendix A: Changes from Prior versions
Changes from version 00
Changed name from DK to DS based on working group comments.
Dropped verbose format based on WG comments.
Added text about TTL issue/problem in caching servers.
Added text about islands of security and clarified the cost impact.
Major editing of arguments and some reordering of text for clarity.
Added section on transition issues.
Gudmundsson Expires January 2002 [Page 10]
INTERNET-DRAFT Delegation Signer Record July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Gudmundsson Expires January 2002 [Page 11]

674
doc/draft/draft-ietf-dnsext-delegation-signer-04.txt Normal file
View file

@ -0,0 +1,674 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT November 2001
<draft-ietf-dnsext-delegation-signer-04.txt>
Updates: RFC 1035, RFC 2535, RFC 3008.
Delegation Signer record in parent.
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on May 20, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
The Delegation Signer (DS) RR set is stored in a delegating (parent)
zone at each delegation point, and indicates the keys used in the
delegated (child) zone. The main design goal of the DS RR simplify the
operation of secure delegations by eliminating the need to store the
same RR in parent and child, as is done with the NS RR set and the KEY
Gudmundsson Expires May 2002 [Page 1]
INTERNET-DRAFT Delegation Signer Record November 2001
set in RFC2535.
Secure resolvers need to take an additional step with DS to verify a
child's KEY RR set. Operationally this schema is much simpler as
operation of the two zones at delegation is now decoupled to great
extent.
This document updates RFC1035, RFC2535 and RFC3008.
1 - Introduction
Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535] and DNSSEC terminology [RFC3090] is important.
When the same data can reside in two administratively different DNS
zones, the data frequently gets out of sync. NS record in a zone
indicates that this name is a delegation and the NS record lists the
authorative servers for the real zone. Based on actual measurements
10-30% of all delegations in the Internet have differing NS sets at
parent and child. There are number of reasons for this, including lack
of communication between parent and child and bogus name-servers being
listed to meet registrar requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its
KEY set signed by the parent to create a verifiable chain of KEYs.
There is some debate, where the signed KEY set should reside,
parent[Parent] or child[RFC2535]. If the KEY set resides at the child,
frequent two way communication is needed between the two parties.
First the child needs to transmit the key set to parent and then the
parent sends the signed set or signatures to child. If the KEY set
resides at the parent the communication is reduced as the child only
sends changed key sets to parent.
DNSSEC[RFC2535] requires that the parent store NULL key set for
unsecure children, this complicates resolution process in many cases
as servers for both parent and child need to be queried for KEY set if
the child server does not return a KEY set. Storing the KEY record
only in the parent zone simplifies this and allows the elimination of
the NULL key set.
Another complication of the DNSSEC KEY model is that KEY record is
used to store DNS zone keys and public keys for other protocols.
There are number of potential problems with this including:
1. KEY set can become quite large if many applications/protocols
store their keys at the zone apex. Possible protocols are IPSEC,
HTTP, SMTP, SSH and others that use public key cryptography.
2. Key set may require frequent updates.
3. Probability of compromised/lost keys increases and triggers
emergency key rollover procedures.
Gudmundsson Expires May 2002 [Page 2]
INTERNET-DRAFT Delegation Signer Record November 2001
4. Parent may refuse sign key sets with NON DNS zone keys.
5. Parent may not meet the child's expectations in turnaround time
in resigning the key set.
Given these and other reasons there is good reason to explore
alternatives to using only KEY records to create chain of trust.
Some of these problems can be reduced or eliminated by operational
rules or protocol changes. To reduce the number of keys at apex, a
rule to require applications to store their KEY records at the SRV
name for that application is one possibility. Another is to restrict
KEY record to DNS keys only and create a new type for all non DNS
keys. Third possible solution is to ban the storage of non DNS related
keys at zone apex. There are other possible solutions but they are
outside the scope of this document.
1.2 - Reserved words
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119.
2 - DS (Delegation KEY Signer)
2.1 - Delegation Signer Record model
This document proposes an alternative to the KEY record chain of
trust, that uses a special record that can only reside at the parent.
This record will identify the key(s) that child are allowed to self
sign its own KEY set.
The chain of trust is now established by verifying the parent KEY set,
the DS set from the parent and the KEY set at the child. This is
cryptographically equivalent to just using KEY records.
Communication between the parent and child is greatly reduced, since
the child only needs to notify parent about changes in keys that sign
its apex KEY RRset. Parent is ignorant of all other keys in the
child's apex KEY RRset, and the child maintains full control over the
apex KEY set and its content. Child can maintain any policies over
its DNS and other KEY usage with minimal impact on parent. Thus if
child wants to have frequent key rollover for its DNS keys parent does
not need to be aware of it as the child can use one key to only sign
its apex KEY set and other keys to sign the other record sets in the
zone.
Gudmundsson Expires May 2002 [Page 3]
INTERNET-DRAFT Delegation Signer Record November 2001
This model fits well with slow roll out of DNSSEC and islands of
security model. In the islands of security model someone that trusts
"good.example." can preconfigure a key from "good.example." as a
trusted keys and from then on trusts any data that is signed by that
key or has a chain of trust to that key. If "example." starts
advertising DS records, "good.example." does not have to change
operations, by suspending self-signing. DS records can also be used to
identify trusted keys instead of KEY records. One further advantage
is the information stored in the parent is minimized, as only records
for secure delegations are needed.
The main disadvantage of this approach that verifying delegations KEY
set requires twice as many signature verification operations. There
is no impact on the number of signatures verified for other RR sets.
2.2 Protocol change
Each secure delegation in a secure zone MUST contain a DS RR set. If
a DS RR set accompanies the NS RR set, the intent is to state that the
child zone is secured. If an NS RR set exists without a DS RR set the
intent is to state that the child zone is unsecure. DS sets MUST NOT
appear at non delegations or at zone APEX.
In a zone that uses DS, insecure delegations MUST have the NODS[TBD]
bit set in the NXT record. This is required to differenciate this
delegation from Secure RFC2535 delegation.
Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section
2.7:
Delegating zones MUST NOT store KEY records for delegations. The only
records that can appear at delegation in parent are NS, SIG, NXT and
DS.
Zone MUST self sign its apex KEY set, it SHOULD sign it with a key
that corresponds to a DS record in the parent. The KEY used to sign
the apex KEY RRset MAY sign other RRsets in the zone.
If child apex KEY RRset is not signed with one of the keys specified
in the DS record the child is locally secure[RFC3090] and SHOULD only
be considered secure if the resolver has been configured to trust the
key used.
Authorative server answering a query with the OK bit[OKbit] set, MUST
include the DS records and NXT record along with signatures in answers
for a delegation and space is available. DS and NXT records SHOULD
have lower priority than address records but higher priority than KEY.
Caching servers SHOULD return the DS and parent NXT record(s) in the
additional section under the same condition.
Gudmundsson Expires May 2002 [Page 4]
INTERNET-DRAFT Delegation Signer Record November 2001
2.2.1 - Comments on protocol change
Over the years there has been various discussions on that the
delegation model in DNS is broken as there is no real good way to
assert if delegation exists. In RFC2535 version of DNSSEC the
authentication of a delegation is the NS bit in the NXT bitmap at the
delegation point. Something more explicit is needed and the DS record
addresses this for secure delegations.
DS record is the first DNS record that can only appear on the upper
side of a delegation. NS records appear at both sides as do SIG and
NXT. All other records can only appear at the lower side. This will
cause some problems as servers authorative for parent, reject DS
record even if the server understands unknown types, or will not hand
them out unless explicitly asked. Similarly a nameserver acting as a
authorative for child and as a caching recursive server may never
return the DS record.
A caching server that supports unkown types, does not care from which
side DS record comes from and thus does not have to be changed.
Different TTL values on the child's NS set and parents DS set can
cause the DS set to expire before the NS set.
Secure resolvers need to know about the DS record and how to interpret
it. In the worst case, introducing the DS record, doubles the
signatures that need to be checked to validate a KEY set.
2.3 Wire format of DS record
The DS (type=TDB) record consists of algorithm, key tag and SHA-1
digest of the public key KEY record allowed to sign the child's
delegation.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHA-1 digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gudmundsson Expires May 2002 [Page 5]
INTERNET-DRAFT Delegation Signer Record November 2001
The key tag is calculated as specified in RFC2535, Algorithm MUST be
an algorithm number assigned in the range 1..251 and the algorithm
MUST be allowed to sign DNS data. The SHA-1 digest is calculated over
the canonical name of the delegation followed by the RDATA of the KEY
record.
DS records MUST NOT point to a null KEY record, and the KEY records
pointed to by DS records MUST have protocol value 3 (DNSSEC).
DS records MUST NOT point to KEY records where flag field has folowing
bit settings, bit 0 (no authentication) is set, bit 6 MUST be set to 0
and bit 7 MUST be set to 1 (zone key). Settings of other bits are not
important.
The size of the DS RDATA is 23 bytes, regardless of key size.
2.3.1 Justifications for fields
The algorithm and key tag fields are here to allow resolvers to
quickly identify the candidate KEY records to examine. The key tag
adds some greater assurance than SHA-1 digest on its own. SHA-1 is a
strong cryptographic checksum, it is real hard for attacker to
generate a KEY record that has the same SHA-1 digest. Combining the
name of the key and the key data as input to the digest provides
stronger assurance of the binding.
This format allows concise representation of the keys that child will
use, thus keeping down the size of the answer for the delegation,
reducing the probability of packet overflow. The SHA-1 hash is strong
enough to uniquely identify the key. This is similar to the PGP
footprint.
DS record is also well suited to lists trusted keys for islands of
security in configuration files.
2.4 Presentation format of DS record
The presentation format of DS record consists of 2 numbers followed by
digest presented in hex.
foo.example DS 12345 3 123456789abcdef67890
Gudmundsson Expires May 2002 [Page 6]
INTERNET-DRAFT Delegation Signer Record November 2001
2.5 Transition issues for installed base
RFC2535 compliant resolver will assume that all DS secured delegations
are locally secure. This is a bad thing, thus it might be necessary
for a transition period to support both DS and SIG@Child. The cost is
one or more signatures in the answer for KEY records and that early
adopters have to use cumbersome communications that DS solves. #.bp
2.6 Backwards compatibilty with RFC2535 SIG@child and RFC1035
This section documents how a resolver determines the type of
delegation.
RFC1035 delegation has:
RFC1035 NS
RFC2535 adds the following two cases:
Secure RFC2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Insecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
NXT bit map contains: NS SIG KEY NXT
KEY must be null-key.
DS adds the following two states:
Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT DS
Insecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG KEY NXT NODS
If the NODS bit is not used, a resover can not determine if this is a
DS delegation zone. Thus is not able to determine if this delegtion is
a secure RFC2535 or a insecure DS.
2.6.1 NODS support in servers
NODS is a virtual type, servers MUST refuse to store any record of
this type. No special processing is required on answers.
Gudmundsson Expires May 2002 [Page 7]
INTERNET-DRAFT Delegation Signer Record November 2001
3 Resolver Example
To create a chain of trust resolver goes from trusted KEY to DS to
KEY.
Assume the key for domain "example." is trusted. In zone "example."
we have
example. KEY <stuff>
secure.example. DS tag=10243 alg=3 <foofoo>
secure.example. NS ns1.secure.example.
NS ns2.secure.example.
secure.example. NXT NS SIG NXT DS unsecure.example.
secure.example. SIG(NXT)
secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example.
unsecure.example NS ns2.unsecure.example.
unsecure.example. NXT NS SIG NXT NODS .example.
unsecure.example. SIG(NXT)
In zone "secure.example." we have
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
NS ns1.secure.example.
secure.example. KEY <tag=12345 size=1024 alg=3>
KEY <tag=54321 size=512 alg=5>
KEY <tag=32145 size=1024 alg=3>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
In this example the trusted key for "example." signs the DS record for
"secure.example.", making that a trusted record. The DS record states
what key is expected to sign the KEY RRset at "secure.example". Here
"secure.example." has three different KEY records and the KEY
identified in the DS record signs the KEY set, thus the KEY set is
validated and trusted. Note that one of the other keys in the keyset
actually signs the zone data, and resolvers will trust the signatures
as the key appears in the KEY set.
This example has only one DS record for the child but there no reason
to outlaw multiple DS records. More than one DS record is needed
during signing key rollover. It is strongly recommended that the DS
set be kept small.
Resolver determines the security status of "unsecure.example." by
examining the parent size NXT for this name.
Gudmundsson Expires May 2002 [Page 8]
INTERNET-DRAFT Delegation Signer Record November 2001
3.1 Resolver cost estimates for DS records
From a RFC2535 resolver point of view for each delegation followed to
chase down an answer one KEY record has to be verified and possibly
some other records based on policy, for example the contents of the NS
set. Once the resolver gets to the appropriate delegation validating
the answer may require verifying one or more signatures. A simple A
record lookup requires at least N delegations to be verified and 1
RRset. For a DS enabled resolver the cost is 2N+1. For MX record the
cost where the target of the MX record is in the same zone as the MX
record the costs are N+2 and 2N+2. In the case of negative answer the
same ratios hold true.
Resolver may require an extra query to get the DS record and this may
add to the overall cost of the query, but this is never worse than
chasing down NULL KEY records from the parent in RFC2535 DNSSEC.
DS adds processing overhead on resolvers, increases the size of
delegation answers but much less than SIG@Parent.
4 Acknowledgments
Number of people have over the last few years contributed number of
ideas that are captured in this document. The core idea of using one
key to only sign key set, comes from discussions with Bill Manning and
Perry Metzger on how to put in a single root key in all resolvers.
Alexis Yushin, Brian Wellington, Jakob Schlyter, Scott Rosen, Edward
Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf Kolman, Miek
Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka,
Rob Austein, Derek Atkins, Roy Arends, and others have provided useful
comments.
4 - Security Considerations:
This document proposes a change to the validation chain of KEY records
in DNS. The change in is not believed to reduce security in the
overall system, in RFC2535 DNSSEC child must communicate keys to
parent and prudent parents will require some authentication on that
handshake. The modified protocol will require same authentication but
allows the child to exert more local control over its own KEY set.
There is a possibility that an attacker can generate an valid KEY that
matches all the DS fields thus starting to forge data from the child.
This is considered impractical as on average more than 2^80 keys must
be generated before one is found that will match.
DS record is a change to DNSSEC protocol and there is some installed
base of implementations, as well as text books on how to set up
Gudmundsson Expires May 2002 [Page 9]
INTERNET-DRAFT Delegation Signer Record November 2001
secured delegations. Implementations that do not understand DS record
will not be able to follow the KEY to DS to KEY chain and consider all
zone secured that way insecure.
5 - IANA Considerations:
IANA needs to allocate RR type code for DS from the standard RR type
space.
IANA needs to allocate RR type code for the virtual NODS record from
the standard RR type space. Note: SINK (40) was never implemented and
that type code can be reused for NODS.
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
Authority'', RFC 3008, November 2000.
[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
Status'', RFC 3090, March 2001.
[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in
progress <draft-ietf-dnsext-dnssec-okbit-02.txt>, April 2001.
[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone
KEYs'', work in progress <draft-ietf-dnsext-parent-stores-
zones-keys-01.txt>, May 2001.
Author Address
Olafur Gudmundsson
3826 Legation Street, NW
Washington, DC, 20015
USA
<ogud@ogud.com>
Gudmundsson Expires May 2002 [Page 10]
INTERNET-DRAFT Delegation Signer Record November 2001
Appendix A: Changes from Prior versions
Changes from version 03
Added strict rules on what KEY records can be pointed to by DS.
Changes from version 02
Added text outlawing DS at non delegations.
Added table showing the contents of DS, SIG@child, and RFC1034
delegations.
Added the NODS type/bit definition to distiguish insecure DS
delegation from secure SIG@child one.
Added the requirement that NXT be returned with referal answers.
Minor text edits.
Changes from version 01
Deleted KEY size field as it did not contribute anything but
complexity.
Number of wordsmith changes to make document more readable.
The word CAN was used when SHOULD was intended.
Deleted section 2.4 "Justifications for compact format" moved relevant
text to section 2.2.
Reverse alphabetized the acknowledgments section.
Reorganized sections 1 and 2 for readability.
Changes from version 00
Changed name from DK to DS based on working group comments.
Dropped verbose format based on WG comments.
Added text about TTL issue/problem in caching servers.
Added text about islands of security and clarified the cost impact.
Major editing of arguments and some reordering of text for clarity.
Added section on transition issues.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
Gudmundsson Expires May 2002 [Page 11]
INTERNET-DRAFT Delegation Signer Record November 2001
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Gudmundsson Expires May 2002 [Page 12]

166
doc/draft/draft-ietf-dnsext-gss-tsig-03.txt → doc/draft/draft-ietf-dnsext-gss-tsig-04.txt
View file

@ -1,8 +1,8 @@
INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-03.txt> Praerit Garg
September 20, 2001 James Gilroy
Expires March 20, 2002 Levon Esibov
<draft-ietf-dnsext-gss-tsig-04.txt> Praerit Garg
November 19, 2001 James Gilroy
Expires May 19, 2002 Levon Esibov
Jeff Westhead
Microsoft Corp.
Randy Hall
@ -54,9 +54,9 @@ Application Program Interface (GSS-API) (RFC2743).
Expires March 20, 2002 [Page 1]
Expires May 19, 2002 [Page 1]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
Table of Contents
@ -91,12 +91,12 @@ Table of Contents
1. Introduction
The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
was developed to provide a lightweight end to end authentication and
integrity of messages between two DNS entities, such as client and
server or server and server. TSIG can be used to protect dynamic update
messages, authenticate regular message or to off-load complicated
DNSSEC [RFC2535] processing from a client to a server and still allow
the client to be assured of the integrity off the answers.
was developed to provide a lightweight authentication and integrity of
messages between two DNS entities, such as client and server or server
and server. TSIG can be used to protect dynamic update messages,
authenticate regular message or to off-load complicated DNSSEC
[RFC2535] processing from a client to a server and still allow the
client to be assured of the integrity off the answers.
The TSIG protocol [RFC2845] is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic
@ -108,13 +108,13 @@ include authentication, integrity, and confidentiality.
The GSS-API framework has several benefits:
* Mechanism and protocol independence. The underlying mechanisms that
realize the security services can be negotiated on the fly and varied
over time. For example, a client and server may use Kerberos [RFC1964]
for one transaction, whereas that same server may use SPKM [RFC2025]
over time. For example, a client and server MAY use Kerberos [RFC1964]
for one transaction, whereas that same server MAY use SPKM [RFC2025]
with a different client.
Expires March 20, 2002 [Page 2]
Expires May 19, 2002 [Page 2]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
@ -130,9 +130,9 @@ of [RFC2743] before examining this protocol in detail. It is also
assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
and [RFC1035].
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in RFC 2119 [RFC2119].
2. Algorithm Overview
@ -170,9 +170,9 @@ states of a context associated with a connection:
| |
+----------+
Expires March 20, 2002 [Page 3]
Expires May 19, 2002 [Page 3]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
Every connection begins in the uninitialized state.
@ -211,6 +211,13 @@ the owner name of the TKEY and TSIG records sent between a client and a
server to indicate to each other which context MUST be used to process
the current request.
DNS client and server MAY use various underlying security mechanisms to
establish security context as described in sections 3 and 4. At the
same time, in order to guarantee interoperability between DNS clients
and servers that support GSS-TSIG it is required that security
mechanism used by client enables use of Kerberos v5 (see Section 9
for more information).
3.1 Negotiating Context
@ -220,6 +227,11 @@ initial token and sends it to the server. The server processes the
token and if necessary, returns a subsequent token to the client. The
client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens
Expires May 19, 2002 [Page 4]
INTERNET-DRAFT GSS-TSIG November 19, 2001
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
@ -228,11 +240,6 @@ tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [RFC2930].
Expires March 20, 2002 [Page 4]
INTERNET-DRAFT GSS-TSIG September 20, 2001
3.1.1 Call GSS_Init_sec_context
@ -278,19 +285,17 @@ indicated with the output values below. Consult Sections 2.2.1
BOOLEAN deleg_state
BOOLEAN sequence_state
BOOLEAN anon_state
Expires May 19, 2002 [Page 5]
INTERNET-DRAFT GSS-TSIG November 19, 2001
BOOLEAN trans_state
BOOLEAN prot_ready_state
BOOLEAN conf_avail
BOOLEAN integ_avail
INTEGER lifetime_rec
Expires March 20, 2002 [Page 5]
INTERNET-DRAFT GSS-TSIG September 20, 2001
The client MUST abandon the algorithm if returned major_status is set to
one of the following errors:
@ -339,14 +344,9 @@ context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [RFC2930]. To achieve
global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
Expires May 19, 2002 [Page 6]
Expires March 20, 2002 [Page 6]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
TKEY Record
@ -394,17 +394,17 @@ signature in the TSIG record MUST be verified using the procedure
detailed in section 5, Sending and Verifying Signed Messages. If the
response is not signed, OR if the response is signed but signature is
invalid, then an attacker has tampered with the message in transit or
has attempted to send the client a false response. The client MUST
has attempted to send the client a false response. The client MAY
continue waiting for a response to its last TKEY query until the time
period since the client sent last TKEY query expires. Such a time period
is specified by the policy local to the client.
is specified by the policy local to the client. This is a new option
that allows DNS client to accept multiple answers for one query ID and
select one (not necessarily the first one) based on some criteria.
Expires May 19, 2002 [Page 7]
Expires March 20, 2002 [Page 7]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
If the signature is verified the context state is advanced to Context
@ -423,7 +423,7 @@ context by calling GSS_Delete_sec_context providing the associated
context_handle. The client MAY repeat the negotiation sequence starting
with the uninitialized state as described in section 3.1. To prevent
infinite looping the number of attempts to establish a security context
must be limited.
MUST be limited to ten or less.
If the DNS message error is NO_ERROR and error filed in the TKEY record
is 0 (i.e. no error), then the client MUST pass a token specified in the
@ -460,9 +460,9 @@ If OUTPUT major_status is set to one of the following values
GSS_S_BAD_MECH
GSS_S_FAILURE
Expires March 20, 2002 [Page 8]
Expires May 19, 2002 [Page 8]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
the client MUST abandon this negotiation sequence. The client MUST
@ -470,7 +470,7 @@ delete an active context by calling GSS_Delete_sec_context providing
the associated context_handle. The client MAY repeat the negotiation
sequence starting with the uninitialized state as described in section
3.1. To prevent infinite looping the number of attempts to establish a
security context must be limited.
security context MUST be limited to ten or less.
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
client MUST act as described below.
@ -483,8 +483,8 @@ negotiation sequence. The client MUST delete an active context by
calling GSS_Delete_sec_context providing the associated context_handle.
The client MAY repeat the negotiation sequence starting with the
uninitialized state as described in section 3.1. To prevent infinite
looping the number of attempts to establish a security context must be
limited.
looping the number of attempts to establish a security context MUST be
limited to ten or less.
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
finished. The token output_token MUST be passed to the server in a TKEY
@ -518,9 +518,9 @@ in section 5, Sending and Verifying Signed Messages.
Expires March 20, 2002 [Page 9]
Expires May 19, 2002 [Page 9]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
3.2.1 Terminating a Context
@ -576,9 +576,9 @@ context negotiation.
Expires March 20, 2002 [Page 10]
Expires May 19, 2002 [Page 10]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
4.1.2 Call GSS_Accept_sec_context
@ -634,9 +634,9 @@ RCODE = NOERROR, that contains a TKEY record in the answer section.
Expires March 20, 2002 [Page 11]
Expires May 19, 2002 [Page 11]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
If OUTPUT major_status is one of the following errors the error field
in the TKEY record set to BADKEY.
@ -692,9 +692,9 @@ Error, Other Size and Data Fields, MUST be set according to [RFC2930].
Expires March 20, 2002 [Page 12]
Expires May 19, 2002 [Page 12]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
@ -750,9 +750,9 @@ call" of the RFC 2743[RFC2743] for syntax definitions.
Expires March 20, 2002 [Page 13]
Expires May 19, 2002 [Page 13]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
@ -808,9 +808,9 @@ For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
INTEGER minor_status
INTEGER qop_state
Expires March 20, 2002 [Page 14]
Expires May 19, 2002 [Page 14]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [RFC2845], the timer values of the
@ -866,9 +866,9 @@ to the algorithm described above.
Expires March 20, 2002 [Page 15]
Expires May 19, 2002 [Page 15]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
Client verifies that replay_det_state and mutual_state values are
TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
@ -924,9 +924,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001
Expires March 20, 2002 [Page 16]
Expires May 19, 2002 [Page 16]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
V. Server responds to the TKEY query
Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
@ -982,9 +982,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001
Expires March 20, 2002 [Page 17]
Expires May 19, 2002 [Page 17]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
VIII. Server receives a TKEY query
When the server receives a TKEY query, the server verifies that Mode
@ -1040,9 +1040,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001
Signature field in the TSIG record is set to per_msg_token.
Expires March 20, 2002 [Page 18]
Expires May 19, 2002 [Page 18]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
XI. Client processes token returned by server
@ -1074,6 +1074,9 @@ This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
All the security considerations from RFC2845, RFC2930 and RFC 2743
apply to the protocol described in this document.
8. IANA Considerations
@ -1095,12 +1098,9 @@ mech_type in their GSS API calls. At the same time, in order to
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
Expires May 19, 2002 [Page 19]
Expires March 20, 2002 [Page 19]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
- DNS servers specify SPNEGO mech_type
@ -1156,9 +1156,9 @@ Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
Expires March 20, 2002 [Page 20]
Expires May 19, 2002 [Page 20]
INTERNET-DRAFT GSS-TSIG September 20, 2001
INTERNET-DRAFT GSS-TSIG November 19, 2001
[ISO11578]"Information technology", "Open Systems
@ -1175,14 +1175,14 @@ Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
skwan@microsoft.com
skwan@microsoft.com praeritg@microsoft.com
James Gilroy Levon Esibov
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
levone@microsoft.com
jamesg@microsoft.com levone@microsoft.com
Randy Hall Jeff Westhead
@ -1190,8 +1190,8 @@ Lucent Technologies Microsoft Corporation
400 Lapp Road One Microsoft Way
Malvern PA 19355 Redmond, WA 98052
USA USA
randyhall@lucent.com
randyhall@lucent.com jwesth@microsoft.com
Expires March 20, 2002 [Page 21]
Expires May 19, 2002 [Page 21]

692
doc/draft/draft-ietf-dnsext-mdns-01.txt → doc/draft/draft-ietf-dnsext-mdns-07.txt
View file

@ -7,14 +7,14 @@
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-01.txt> Microsoft
6 July 2001
<draft-ietf-dnsext-mdns-07.txt> Microsoft
15 November 2001
Multicast DNS
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
@ -61,28 +61,28 @@ Esibov, Aboba & Thaler Standards Track [Page 1]
INTERNET-DRAFT Multicast DNS 6 July 2001
INTERNET-DRAFT Multicast DNS 15 November 2001
Table of Contents
1. Introduction .......................................... 3
2. Name resolution using multicast DNS ................... 3
2.1 Behavior of the sender and responder ............ 3
3. Usage model ........................................... 4
4. Sequence of events .................................... 8
5. Conflict resolution ................................... 8
5.1 Considerations for multiple interfaces .......... 10
6. IANA considerations ................................... 11
7. ARPA domain considerations ............................ 11
8. References ............................................ 12
9. Security considerations ............................... 13
ACKNOWLEDGMENTS .............................................. 13
AUTHORS' ADDRESSES ........................................... 14
Intellectual Property Statement .............................. 14
Full Copyright Statement ..................................... 15
2.1 Behavior of the sender and responder ............ 4
3. Usage model ........................................... 7
3.1 mDNS configuration .............................. 8
4. Sequence of events .................................... 9
5. Conflict resolution ................................... 9
5.1 Considerations for multiple interfaces .......... 11
5.2 API issues ...................................... 12
6. IANA considerations ................................... 13
7. ARPA domain considerations ............................ 13
8. References ............................................ 14
9. Security considerations ............................... 15
Acknowledgments .............................................. 16
Authors' Addresses ........................................... 16
Intellectual Property Statement .............................. 16
Full Copyright Statement ..................................... 17
@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2]
INTERNET-DRAFT Multicast DNS 6 July 2001
INTERNET-DRAFT Multicast DNS 15 November 2001
1. Introduction
@ -145,33 +145,33 @@ Service discovery in general as well as discovery of DNS servers using
mDNS in particular is outside of the scope of this document, as is name
resolution over non-multicast capable media.
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in RFC 2119 [1].
2. Name resolution using Multicast DNS
This extension to the DNS protocol consists of a single change to the
method of use, and no change to the current format of DNS packets.
Namely, this extension allows multicast DNS queries to be sent to and
received on port 53.
method of use, and no change to the current format of DNS packets, It
allows multicast DNS queries to be sent to and received on port 53 using
a LINKLOCAL address as specified in "Administratively Scoped IP
Multicast" [2] for IPv4 and the "solicited name" LINKLOCAL multicast
addresses for IPv6. The mDNS LINKLOCAL address to be used for IPv4 is
<TBD>. LINKLOCAL addresses are used to prevent propagation of multicast
DNS traffic across routers, potentially flooding the network.
The messages are sent using the LINKLOCAL addresses [2] for IPv4 and
IPv6 (below referred as the LINKLOCAL address), which are yet to be
assigned by IANA. LINKLOCAL addresses are used to prevent propagation of
multicast DNS traffic across routers, potentially flooding the network.
Propagation of multicast DNS packets on the local link is considered
sufficient to enable DNS name resolution in small adhoc networks. The
assumption is that if a network has a router, then the network either
has a DNS server or the router can function as a DNS proxy.
By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers
can provide name resolution for the names of IPv4 hosts on the local
network. Where all IPv6 hosts also support IPv4, and the DNS proxy
supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on
the local network can also be provided using this mechanism.
Propagation of multicast DNS packets within the local subnet is
considered sufficient to enable DNS name resolution in small adhoc
networks. The assumption is that if a network has a router, then the
network either has a DNS server or the router can function as a DNS
proxy, possibly implementing dynamic DNS.
In the future, mDNS may be defined to support greater than LINKLOCAL
multicast scope. This would occur if LINKLOCAL mDNS deployment is
successful, the assumption that mDNS is not needed in multiple subnets
proves incorrect, and multicast routing becomes ubiquitous. For
example, it is not clear that this assumption will be valid in large
@ -181,9 +181,24 @@ Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT Multicast DNS 6 July 2001
INTERNET-DRAFT Multicast DNS 15 November 2001
Within small adhoc IPv6 networks, stateful autoconfiguration is the most
likely configuration mechanism. If DHCPv6 is not present, then in order
to support resolution of names of IPv6-only hosts on the local network,
the DNS proxy will need to support dynamic client update as well as DNS
over IPv6.
Given the above mechanisms enabling DNS name resolution in small
networks with a router, it is assumed that multicast DNS need not be
enabled by default.
In the future, mDNS may be defined to support greater than LINKLOCAL
multicast scope. This would occur if LINKLOCAL mDNS deployment is
successful, the assumption that mDNS is not needed on multiple links
proves incorrect, and multicast routing becomes ubiquitous. For
example, it is not clear that this assumption will be valid in large
adhoc networking scenarios.
Once we have experience in mDNS deployment in terms of administrative
@ -206,6 +221,31 @@ LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit.
The IPv6 LINKLOCAL address a given responder listens to, and to which a
sender sends, is a link-local multicast address formed as follows: The
name of the resource record in question is expressed in its canonical
form (see RFC 2535 [15], section 8.1), which is uncompressed with all
alphabetic characters in lower case. The first label of the resource
record name is then hashed using the MD5 algorithm (see RFC 1321 [16]).
The first 32 bits of the resultant 128-bit hash is then appended to the
prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name
multicast address". (Note: this procedure is intended to be the same as
that specified in section 3 of "IPv6 Node Information Queries" [14]). A
responder that listens for queries for multiple names will necessarily
Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT Multicast DNS 15 November 2001
listen to multiple of these solicited name multicast addresses.
If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a
@ -214,14 +254,14 @@ a host capable of responding to the query.
Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
repeated more often than once per second to reduce unnecessary network
traffic. The delay between attempts should be randomised so as to avoid
synchronisation effects.
traffic. The delay between attempts should be randomized so as to avoid
synchronization effects.
2.1.2. Behavior of responders
A responder listens on port 53 on the LINKLOCAL address. Responders MUST
respond to multicast queries to those and only those names for which
they are authoritative. As an example, computer
A responder listens on port 53 on the LINKLOCAL address. Responders
MUST respond to multicast queries to those and only those names for
which they are authoritative. As an example, computer
"host.example.com.local.arpa." is authoritative for the domain
"host.example.com.local.arpa.". On receiving a multicast DNS A record
query for the name "host.example.com.local.arpa." such a host responds
@ -232,18 +272,6 @@ authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. For
example the host "host.example.com.local.arpa." is not authoritative for
Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT Multicast DNS 6 July 2001
the name "child.host.example.com.local.arpa." unless the host is
configured with multiple names, including "host.example.com.local.arpa."
and "child.host.example.com.local.arpa.". The purpose of limiting the
@ -265,12 +293,24 @@ for the NS and glue A record to "host.example.com.local.arpa.", but this
approach significantly complicates implementation of multicast DNS and
would not be acceptable for lightweight hosts.
Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT Multicast DNS 15 November 2001
A response to a multicast query is composed in exactly the same manner
as a response to the unicast DNS query as specified in [4]. Responders
MUST never respond using cached data, and the AA (Authoritative Answer)
bit MUST be set. The response is sent to the sender via unicast. A
response to an mDNS query MUST have RCODE set to zero, since mDNS
responders MUST NOT send error replies in response to mDNS queries.
as a response to the unicast DNS query as specified in RFC 1035 [4].
Responders MUST never respond using cached data, and the AA
(Authoritative Answer) bit MUST be set. The response is sent to the
sender via unicast. A response to an mDNS query MUST have RCODE set to
zero. mDNS responders may respond only to queries which they can resolve
positively.
If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY
@ -282,28 +322,17 @@ it.
2.1.3. mDNS addressing
For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules
with respect to source address selection, TTL settings, and acceptable
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [18] lays out the rules with respect to
source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 LINKLOCAL addressing is
described in [9]. mDNS queries and responses MUST obey the rules laid
out in these documents.
described in RFC 2373 [9]. mDNS queries and responses MUST obey the
rules laid out in these documents.
In composing an mDNS response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the
multicast DNS response to 255. The sender MUST verify that the Hop Limit
field in IPv6 header and TTL field in IPv4 header of each response to
Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT Multicast DNS 6 July 2001
the multicast DNS query is set to 255. If it is not, then sender MUST
ignore the response.
@ -313,16 +342,28 @@ ignore the response.
options are used to specify the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms
to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292
specifies similar options for specifying and receiving the IPv6 Hop
Limit.
[20] specifies similar options for specifying and receiving the IPv6
Hop Limit.
2.1.4. Use of DNS TTL
The responder should use a pre-configured TTL [5] value in the records
The responder should use a pre-configured TTL value in the records
returned in the multicast DNS query response. Due to the TTL
minimalization necessary when caching an RRset, all TTLs in an RRset
MUST be set to the same value. In the additional and authority section
of the response the responder includes the same records as a DNS server
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT Multicast DNS 15 November 2001
would insert in the response to the unicast DNS query.
2.1.5. No/multiple responses
@ -348,29 +389,12 @@ ordinarily.
A host configured to be an mDNS "responder" MUST also be configured as a
"sender". A host not configured as a "responder" MUST NOT be a "sender".
Multicast DNS usage is determined by the domain search configuration as
well as by special treatment of the ".local.arpa." namespace. Any host
whose domain search configuration contains the ".local.arpa." domain is
configured to behave as "responder". The sender treats queries for
Multicast DNS usage is determined by special treatment of the
".local.arpa." namespace. The sender treats queries for ".local.arpa."
as a special case. A sender MUST NOT send a unicast query for names
ending with the ".local.arpa." suffix except when:
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT Multicast DNS 6 July 2001
".local.arpa." as a special case. The domain search list can be
configured manually or automatically via a DHCP option [3].
A sender MUST NOT send a unicast query for names ending with the
".local.arpa." suffix except when:
a. A sender repeats a query over TCP after it received a response
a. A sender repeats a query after it received a response
to the previous multicast query with the TC bit set, or
b. The sender's cache contains an NS resource record that enables
@ -387,30 +411,6 @@ when a responder with the name "host.example.com." receives an A type
query for the name "host.example.com.local.arpa." it authoritatively
responds to the query.
If ".local.arpa" is not in the domain search list, then multicast DNS
MUST NOT be used. This implies that the host will neither listen on the
DNS LINKLOCAL multicast address, nor will it send queries to that
address. An auto-configured host will typically have ".local.arpa" first
in its search list so that it will be enabled to use multicast DNS.
Typically an enterprise host will not have ".local.arpa" in its search
list at all so that it will not use multicast DNS.
The same host MAY use multicast DNS queries for the resolution of names
ending with ".local.arpa.", and unicast DNS queries for resolution of
all other names. When a user or application requests a DNS client to
resolve a dot-terminated name that contains a ".local.arpa" suffix, the
query for such a name MUST be multicast and the name SHOULD NOT be
concatenated with any suffix.
If a DNS server is running on a host, the host MUST NOT listen for
multicast DNS queries, to prevent the host from listening on port 53 and
intercepting DNS queries directed to a DNS server. By default, a DNS
server MUST NOT listen to multicast DNS queries. For a DNS server, the
presence of ".local.arpa." in the domain search list MUST NOT enable
multicast DNS.
@ -421,9 +421,81 @@ Esibov, Aboba & Thaler Standards Track [Page 7]
INTERNET-DRAFT Multicast DNS 6 July 2001
INTERNET-DRAFT Multicast DNS 15 November 2001
The same host MAY use multicast DNS queries for the resolution of names
ending with ".local.arpa.", and unicast DNS queries for resolution of
all other names. When a user or application requests a DNS client to
resolve a dot-terminated name that contains a ".local.arpa" suffix, the
query for such a name MUST be multicast and the name SHOULD NOT be
concatenated with any suffix.
If a DNS server is running on a host, then responder MUST NOT listen for
the multicast DNS queries on the same IP addresses on which the DNS
server listens, since otherwise they would intercept DNS queries
directed to a DNS server. The DNS server MUST respond to the multicast
DNS queries only for the RRSets owned by the host on which the server is
running, but MUST NOT respond for the records for which the server is
authoritative.
3.1. mDNS configuration
Multicast DNS usage can be configured manually or automatically. On
interfaces where no manual or automatic configuration has been performed
for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by
default for that protocol.
For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [19] can be used to discover whether multicast
DNS should be enabled or disabled on a per-interface basis.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure multicast DNS on an interface. The mDNS Enable Option,
described in [6], can be used to explicitly enable or disable use of
multicast DNS on an interface for a given protocol, as well as to
specify the order in which DNS and multicast DNS is used on that
interface.
The mDNS Enable Option affects only DNS resolver behavior, that is, how
DNS resolution is performed, and whether multicast DNS is used. The
mDNS Enable Option does not determine whether or in which order DNS
itself is used for name resolution. This can be specified, for example,
using the Name Service Search Option for DHCP, RFC 2937 [3], which can
be used to globally determine where DNS is used within the name service
search order.
If an interface has been configured for a given protocol via any
automatic configuration mechanism which is able to supply DNS
configuration information, then multicast DNS SHOULD NOT be used on that
interface for that protocol unless it has been explicitly enabled,
whether via that mechanism or any other. This ensures that upgraded
hosts do not change their default behavior, without requiring the source
of the configuration information to be simultaneously updated. This
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT Multicast DNS 15 November 2001
implies that on the interface, the host will neither listen on the DNS
LINKLOCAL multicast address, nor will it send queries to that address.
Note that it is possible for mDNS to be enabled for use with IPv6 at the
same time it is disabled for IPv4, and vice versa. For example, where a
home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 or DNS
autoconfiguration, there may be no mechanism for allowing IPv6 hosts to
resolve the names of other IPv6 hosts on the home network. In this
situation, mDNS is useful for resolution of dynamic names, and it will
be enabled for use with IPv6, even though it is disabled for use with
IPv4.
4. Sequence of events
The sequence of events for multicast DNS usage is as follows:
@ -438,11 +510,12 @@ The sequence of events for multicast DNS usage is as follows:
3. Upon the reception of the response, the sender verifies that the Hop
Limit field in IPv6 header or TTL field in IPv4 header (depending on
the protocol used) of the response is set to 255. If the destination
address is a LINKLOCAL address, then the sender verifies use of a
LINKLOCAL source address. If these conditions are met, then the sender
uses and caches the returned response. If not, then the sender ignores
the response and continues waiting for the response.
the protocol used) of the response is set to 255. The sender then
verifies compliance with the addressing requirements for IPv4,
described in [18], and IPv6, described in RFC 2373 [9]. If these
conditions are met, then the sender uses and caches the returned
response. If not, then the sender ignores the response and continues
waiting for the response.
5. Conflict resolution
@ -459,6 +532,18 @@ query and type of the query. For example it is expected that:
- only a single host may respond to a query for an A type record for
a hostname.
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT Multicast DNS 15 November 2001
Every responder that responds to a multicast DNS query and/or dynamic
update request AND includes a UNIQUE record in the response:
@ -472,18 +557,6 @@ Where a host is configured to respond to multicast DNS queries on more
than one interface, the host MUST verify resource record uniqueness on
each interface for each UNIQUE resource record that could be used on
that interface. To accomplish this, the host MUST multicast a dynamic
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT Multicast DNS 6 July 2001
DNS update request as specified in RFC 2136 [11] for each new UNIQUE
resource record. Uniqueness verification is carried out when the host:
@ -497,7 +570,7 @@ Below we describe the data to be specified in the dynamic update
request:
Header section
contains values according to [RFC 2136].
contains values according to RFC 2136 [11].
Zone section
The zone name in the zone section MUST be set to the name of the
@ -519,31 +592,34 @@ Additional section
When a host that owns a UNIQUE record receives a dynamic update request
that requests that the UNIQUE resource record set does not exist, the
Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT Multicast DNS 15 November 2001
host MUST respond via unicast with the YXRRSET error, according to the
rules described in Section 3 of RFC 2136 [11].
After client receives an YXRRSET response to its dynamic update request
that a UNIQUE resource record does not exist, the host MUST not use the
UNIQUE resource record in responses to multicast queries and dynamic
update requests.
that a UNIQUE resource record does not exist, the host MUST check
whether the response arrived on another interface. If this is the case,
then the client can use the UNIQUE resource record in response to
multicast queries and dynamic update requests. If not, then it MUST NOT
use the UNIQUE resource record in response to multicast queries and
dynamic update requests.
Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a
bridge. In such a situation, name conflicts are detected when a sender
receives more than one response to its multicast DNS query. In this
case, the sender sends the first response that it received to all
Esibov, Aboba & Thaler Standards Track [Page 9]
INTERNET-DRAFT Multicast DNS 6 July 2001
responders that responded to this query except the first one, using
unicast. A host that receives a query response containing a UNIQUE
resource record that it owns, even if it didn't send such a query, MUST
@ -564,9 +640,7 @@ take. Implementers who are not planning to support multicast DNS on
multiple interfaces simultaneously may skip this section.
A multi-homed host checks the uniqueness of UNIQUE records as described
in Section 5.
The situation is illustrated in figure 1 below:
in Section 5. The situation is illustrated in figure 1 below:
---------- ----------
| | | |
@ -576,8 +650,22 @@ The situation is illustrated in figure 1 below:
In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other, and as a result, the multi-homed myhost
will not be able to respond with a host RR for "myhost".
interface, but not the other. The multi-homed myhost will not be able to
respond with a host RR for "myhost" on the interface on the right (see
Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT Multicast DNS 15 November 2001
Figure 1). The multi-homed host may, however, be configured to use the
"myhost" name on the interface on the left.
Since names are only unique per-link, hosts on different links could be
using the same name. If an mDNS client sends requests over multiple
@ -592,35 +680,70 @@ illustrated in figure 2 below.
Figure 2. Off-segment name conflict
Esibov, Aboba & Thaler Standards Track [Page 10]
INTERNET-DRAFT Multicast DNS 6 July 2001
If host myhost is configured to use mDNS on both interfaces, it will
send mDNS queries on both interfaces. When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces. Host myhost will then forward a response from the
first responder to the second responder, who will attempt to verify the
uniqueness of host RR for its name, but will not discover a conflict,
since the conflicting host resides on a different subnet. Therefore it
will continue using its name. This illustrates that the proposed name
conflict resolution mechanism does not support resolution of conflicts
between hosts on different subnets. This problem can also occur with
unicast DNS when a multi-homed host is connected to two different
networks with separated name spaces. It is not the intent of this
document to address the issue of uniqueness of names within DNS.
since the conflicting host resides on a different link. Therefore it
will continue using its name.
Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists:
[A]
| |
----- -----
| |
[myhost]
Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on
different links. This problem can also occur with unicast DNS when a
multi-homed host is connected to two different networks with separated
name spaces. It is not the intent of this document to address the issue
of uniqueness of names within DNS.
5.2. API issues
RFC 2553 [13] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the
Esibov, Aboba & Thaler Standards Track [Page 12]
INTERNET-DRAFT Multicast DNS 15 November 2001
sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues the
request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. mDNS requests will be sent from both
interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses of
both hosts responding to the name 'A'. Link-local addresses will have a
sin6_scope_id value that disambiguates which interface is used to reach
the address. Of course, to the application, Figures 2 and 3 are still
indistinguishable, but this API allows the application to communicate
successfully with any address in the list.
6. IANA Considerations
Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses.
This specification requires allocation of a link scope IPv4 multicast
addresses for use by multicast DNS.
7. ARPA domain considerations
@ -637,10 +760,10 @@ namespace differs from others in the following respects:
scope of authority, not extending to sub-domains of
domain they are authoritative for.
- DNS servers SHOULD NOT forward queries for domain names
in the local.arpa domain - if the server cannot answer
the query from its own database, it should reply with a
non-authoritative NXDOMAIN.
- DNS servers SHOULD NOT forward or recursively resolve
queries for domain names in the local.arpa domain - if the
server cannot answer the query from its own database,
it MUST NOT reply.
- Hosts may derive their own names in this namespace,
independent of centralized authorization and registration
@ -649,21 +772,21 @@ namespace differs from others in the following respects:
- There is no delegation or administrative structure to
sub-domains of '.local.arpa'.
Esibov, Aboba & Thaler Standards Track [Page 13]
INTERNET-DRAFT Multicast DNS 15 November 2001
How protocol objects are mapped into lookup keys:
Names are associated with resources which can be requested
Esibov, Aboba & Thaler Standards Track [Page 11]
INTERNET-DRAFT Multicast DNS 6 July 2001
according to the DNS protocol. However, recursive lookup
is impossible. Further, mDNS specifies only the use of
multicast to transmit these requests.
@ -676,8 +799,8 @@ INTERNET-DRAFT Multicast DNS 6 July 2001
[2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[3] Aboba, B., "DHCP Domain Search Option", Internet draft (work in
progress), draft-aboba-dhc-domsearch-02.txt, June 2001.
[3] Smith, C., "The Name Service Search Option for DHCP", RFC 2937,
September 2000.
[4] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987.
@ -685,9 +808,8 @@ INTERNET-DRAFT Multicast DNS 6 July 2001
[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
1034, November, 1987.
[6] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local
Addresses", Internet draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-03.txt, June 2001.
[6] Guttman, E., "DHCP mDNS Enable Option", Internet draft (work in
progress), draft-guttman-mdns-enable-01.txt, July 2001.
[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
@ -709,20 +831,45 @@ INTERNET-DRAFT Multicast DNS 6 July 2001
[12] Huston, G., "Management Guidelines & Operational Requirements for
the Internet Infrastructure Domain ("ARPA")", Internet draft (work
in progress), draft-iab-arpa-02.txt, May 2001.
in progress), draft-iab-arpa-03.txt, July 2001.
Esibov, Aboba & Thaler Standards Track [Page 14]
Esibov, Aboba & Thaler Standards Track [Page 12]
INTERNET-DRAFT Multicast DNS 15 November 2001
[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999.
[14] Crawford, Matt, "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt,
August 2000.
[15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
March 1999.
INTERNET-DRAFT Multicast DNS 6 July 2001
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in
progress), draft-aboba-dhc-domsearch-08.txt, November 2001.
[18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local
Addresses", Internet draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-05.txt, November 2001.
[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet
draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt,
July 2001.
[20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292,
February 1998.
9. Security Considerations
@ -739,51 +886,46 @@ In all received responses, the Hop Limit field in IPv6 and the TTL field
in IPv4 are verified to contain 255, the maximum legal value. Since
routers decrement the Hop Limit on all packets they forward, received
packets containing a Hop Limit of 255 must have originated from a
neighbor. Packets destined for a LINKLOCAL address are verified to have
been sent from a LINKLOCAL source address.
neighbor.
These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home.
Link-layer security will serve to secure mDNS against the above threats
Esibov, Aboba & Thaler Standards Track [Page 15]
INTERNET-DRAFT Multicast DNS 15 November 2001
if it is available. For example, where 802.11 "Wired Equivalency
Privacy" (WEP) [10] is implemented, a casual attacker is likely to be
deterred from gaining access to the home network.
The mechanism specified in this draft does not require use of the
DNSSEC, which means that the responses to the multicast DNS queries may
not be authenticated. If a network contains a "signed key distribution
center" for all (or at least some) of the DNS zones that the responders
are authoritative for, then hosts on such a network are configured with
the key for the top zone, "local.arpa." (hosted by "signed keys
distribution center") and may use DNSSEC for authentication of the
responders using DNSSEC.
The mechanism specified in this draft does not require use of DNSSEC.
As a result, responses to multicast DNS queries MAY NOT be
authenticated. If a network contains a "signed key distribution center"
for some of the DNS zones that the responders are authoritative for, and
senders on that network are configured with the key for the top zone
"local.arpa." (hosted by "signed keys distribution center"), then
senders MAY authenticate the responses using DNSSEC.
Acknowledgments
This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. The authors gratefully acknowledge their
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification. Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Robert Elz, James
Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten,
Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima.
Esibov, Aboba & Thaler Standards Track [Page 13]
INTERNET-DRAFT Multicast DNS 6 July 2001
Authors' Addresses
Levon Esibov
@ -798,7 +940,7 @@ Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 936-6605
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Dave Thaler
@ -806,9 +948,22 @@ Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 703-8835
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Esibov, Aboba & Thaler Standards Track [Page 16]
INTERNET-DRAFT Multicast DNS 15 November 2001
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
@ -831,19 +986,6 @@ which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
Esibov, Aboba & Thaler Standards Track [Page 14]
INTERNET-DRAFT Multicast DNS 6 July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
@ -869,8 +1011,21 @@ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-01.txt>, and expires
January 15, 2002.
Esibov, Aboba & Thaler Standards Track [Page 17]
INTERNET-DRAFT Multicast DNS 15 November 2001
This memo is filed as <draft-ietf-dnsext-mdns-07.txt>, and expires May
22, 2002.
@ -895,6 +1050,31 @@ January 15, 2002.
Esibov, Aboba & Thaler Standards Track [Page 15]
Esibov, Aboba & Thaler Standards Track [Page 18]