ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity
Files
48bf87ba83396aae2251646aed9a9cac183e5780
bind9/doc/draft/draft-yao-dnsext-bname-05.txt
Evan Hunt f2ea8c2f96 [master] updated published drafts
2014-02-14 08:53:06 -08:00

842 lines
31 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Standards Track CNNIC
Expires: February 20, 2011 P. Vixie
Internet Software Consortium
August 19, 2010
Bundled DNS Name Redirection
draft-yao-dnsext-bname-05.txt
Abstract
This document defines a new DNS Resource Record called "BNAME", which
provides the capability to map itself and its subtree of the DNS name
space to another domain. It differs from the CNAME record which only
maps a single node of the DNS name space, from the DNAME which only
maps the subtree of the DNS name space to another domain.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 20, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Yao, et al. Expires February 20, 2011 [Page 1]
Internet-Draft bname August 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The BNAME Resource Record . . . . . . . . . . . . . . . . . . 4
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4
3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4
3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5
4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8
5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9
5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10
5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12
9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12
9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12
9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12
9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13
9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Yao, et al. Expires February 20, 2011 [Page 2]
Internet-Draft bname August 2010
1. Introduction
More and more internationalized domain name labels [RFC3490] appear
in the DNS trees. Some labels [RFC3743] are equivalent in some
languages. The internet users want them to be identical in the DNS
resolution. For example, color.exmaple.com==colour.example.com. The
BNAME represents for bundle names. This document defines a new DNS
Resource Record called "BNAME", which provides the capability to map
an entire tree of the DNS name space to another domain. It means
that the BNAME redirects both itself and its descendants to its
owner. The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
only the descendants. The domain name that owns a DNAME record is
allowed to have other resource record types at that domain name. The
domain name that owns a BNAME record is not allowed to have other
resource record types at that domain name unless they are the DNSSEC
related resource record types defined in [RFC4033], [RFC4034],
[RFC4035] and [RFC5155]. A server MAY refuse to load a zone that has
data at a sub-domain of a domain name owning a BNAME RR or that has
other data except the DNSSEC related resource record types and BNAME
at that name. BNAME is a singleton type, meaning only one BNAME is
allowed per name except the DNSSEC related resource record types.
Resolvers, servers and zone content administrators should be cautious
that usage of BNAME or its combination with CNAME or DNAME may lead
to form loops. The loops should be avoided.
1.1. Terminology
All the basic terms used in this specification are defined in the
documents [RFC1034], [RFC1035] and [RFC2672].
2. Motivation
In some languages, some characters have the variants, which look
differently or very similar but are identical in the meaning. For
example, Chinese character U+56FD and its variant U+570B look
differently, but are identical in the meaning. If Internationalized
Domain Label" or "IDL" [RFC3743] are composed of variant characters,
we regard this kind of IDL as the IDL variant. If these IDL variants
are put into the DNS for resolution, they are expected to be
identical in the DNS resolution. More comprehensible example is that
we expect color.exmaple.com to be equivalent with the
colour.exmaple.com in the DNS resolution. The BNAME Resource Record
and its processing rules are conceived as a solution to this
equivalence problem. Without the BNAME mechanism, current mechanisms
such as DNAME or CNAME are not enough capable to solve all the
problems with the emergence of internationalized domain names. The
internationalized domain names may have alias or equivalence of the
Yao, et al. Expires February 20, 2011 [Page 3]
Internet-Draft bname August 2010
original one. The BNAME solution provides the solution to both ASCII
alias names and internationalized domain alias names.
3. The BNAME Resource Record
3.1. Format
The BNAME RR has mnemonic BNAME and type code xx (decimal). It is
not class-sensitive. Its RDATA is comprised of a single field,
<target>, which contains a fully qualified domain name that must be
sent in uncompressed form [RFC1035], [RFC3597]. The <target> field
MUST be present. The presentation format of <target> is that of a
domain name [RFC1035]. The wildcards in the BNAME RR SHOULD NOT be
used.
<owner> <ttl> <class> BNAME <target>
The effect of the BNAME RR is the substitution of the record's
<target> for its owner name, as a suffix of a domain name. This
substitution has to be applied for every BNAME RR found in the
resolution process, which allows fairly lengthy valid chains of BNAME
RRs.
3.2. The BNAME Substitution
A BNAME substitution is performed by replacing the suffix labels of
the name being sought matching the owner name of the BNAME resource
record with the string of labels in the RDATA field. The matching
labels end with the root label in all cases. Only whole labels are
replaced.
3.3. The BNAME Rules
There are two rules which governs the use of BNAMEs in a zone file.
The first one is that there SHOULD be no descendants under the owner
of the BNAME. The second one is that no resource records can co-
exist with the BNAME for the same name except the DNSSEC related
resource record types. It means that if a BNAME RR is present at a
node N, there MUST be no other data except the DNSSEC related
resource record types at N and no data at any descendant of N. This
restriction applies only to records of the same class as the BNAME
record.
3.4. BNAME Examples
The table below shows some examples of the BNAME usage.
Yao, et al. Expires February 20, 2011 [Page 4]
Internet-Draft bname August 2010
QNAME owner BNAME target result
---------------- -------------- -------------- -----------------
com. example.com. example.net. <no match>
com. com. net. net.
example.com. example.com. example.net. example.net.
a.example.com. example.com. example.net. a.example.net.
a.b.example.com. example.com. example.net. a.b.example.net.
ab.example.com. b.example.com. example.net. <no match>
bar.example.com. example.com. example.net. bar.example.net.
a.b.example.com. b.example.com. example.net. a.example.net.
a.example.com. example.com. b.example.net. a.b.example.net.
Table 1. BNAME Usage Examples.
If the owner name of the CNAME RR is regarded as the target of the MX
RR, it may cause some problems. Some mail servers may directly
connect the owner name of the CNAME instead of the name pointed by
CNAME for mail delivery and cause the undelivery of the mails. BNAME
has the similar problems with CNAME. This document specifies that
the owner name of the BNAME should not be the targets of some RRs
such as MX, SRV and PTR. In case that the owner name of the BNAME RR
is the target of some RRs, it should be cautious.
4. Query Processing
To exploit the BNAME mechanism the name resolution algorithms
[RFC1034] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
substitution on a name (either QNAME or SNAME) under control of a
BNAME record. This operation will be referred to as "the BNAME
substitution".
4.1. Processing by Servers
For a server performing non-recursive service steps 3.a, 3.c and 4 of
section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
to return certain BNAME records from zone data and the cache.
If the owner name of the bname is the suffix of the name queryed but
different, when preparing a response, a server performing a BNAME
substitution will in all cases include the relevant BNAME RR in the
answer section. A CNAME RR is synthesized and included in the answer
section. This will help the client to reach the correct DNS data.
If the owner name of the bname is same with the name queryed, when
preparing a response, a server performing a BNAME substitution will
Yao, et al. Expires February 20, 2011 [Page 5]
Internet-Draft bname August 2010
not include the relevant BNAME RR in the answer section unless the
type queryed is BNAME. A CNAME RR will be synthesized and included
in the answer section unless the type queryed is BNAME.
The provided synthesized CNAME RR if there has one, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to the corresponding BNAME RR,
An <owner> equal to the QNAME in effect at the moment the BNAME RR
was encountered, and
An RDATA field containing the new QNAME formed by the action of
the BNAME substitution.
The revised server algorithm is:
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise
step 2.
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
Yao, et al. Expires February 20, 2011 [Page 6]
Internet-Draft bname August 2010
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME RR,
and go back to step 1.
If the data at the node is a BNAME, and QTYPE doesn't
match BNAME, copy the BNAME RR and also a corresponding,
synthesized CNAME RR into the answer section of the
response, change QNAME to the name carried as RDATA in
the BNAME RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
b. If a match would take us out of the authoritative data, we have
a referral. This happens when we encounter a node with NS RRs
marking cuts along the bottom of a zone.
Copy the NS RRs for the subzone into the authority section of
the reply. Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache. Go to step 4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a BNAME record.
If a BNAME record exists at that point, copy that record into
the answer section. If substitution of its <target> for its
<owner> in QNAME would overflow the legal size for a <domain-
name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
perform the substitution and continue. The server SHOULD
synthesize a corresponding CNAME record as described above and
include it in the answer section. Go back to step 1.
If there was no BNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we are
looking for is the original QNAME in the query or a name we
have followed due to a CNAME. If the name is original, set an
authoritative name error in the response and exit. Otherwise
just exit.
Yao, et al. Expires February 20, 2011 [Page 7]
Internet-Draft bname August 2010
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
set the owner of the RR to be QNAME, and not the node with the
"*" label. Go to step 6.
4. Start matching down in the cache. If QNAME is found in the cache,
copy all RRs attached to it that match QTYPE into the answer
section. If QNAME is not found in the cache but a BNAME record is
present at QNAME, copy that BNAME record into the
answer section. If there was no delegation from authoritative
data, look for the best one from the cache, and put it in the
authority section. Go to step 6.
5. Use the local resolver or a copy of its algorithm (see resolver
section of this memo) to answer the query. Store the results,
including any intermediate CNAMEs and BNAMEs, in the answer
section of the response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
Note that there will be at most one ancestor with a BNAME as
described in step 4 unless some zone's data is in violation of the
no-descendants limitation in section 3. An implementation might take
advantage of this limitation by stopping the search of step 3c or
step 4 when a BNAME record is encountered.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a BNAME as somewhat analogous to a CNAME. The resolver
algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
Yao, et al. Expires February 20, 2011 [Page 8]
Internet-Draft bname August 2010
1. See if the answer is in local information, and if so return it to
the client.
2. Find the best servers to ask.
3. Send them queries until one returns a response.
4. Analyze the response, either:
a. if the response answers the question or contains a name error,
cache the data as well as returning it back to the client.
b. if the response contains a better delegation to other servers,
cache the delegation information, and go to step 2.
c. if the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical name
in the CNAME RR and go to step 1.
d. if the response shows a BNAME and that is not the answer
itself, cache the BNAME. If substitution of the BNAME's
<target> for its <owner> in the SNAME would overflow the legal
size for a <domain-name>, return an implementation-dependent
error to the application; otherwise perform the substitution
and go to step 1.
e. if the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to step
3.
A resolver or recursive server which understands BNAME records but
sends non-extended queries MUST augment step 4.c by deleting from the
reply any CNAME records which have an <owner> which is a subdomain of
the <owner> of any BNAME record in the response.
5. BNAME in DNSSEC
5.1. BNAME validating
With the deployment of DNSSEC, more and more servers and resolvers
will support DNSSEC. In order to make BNAME valid in DNSSEC
verification, the DNSSEC enabled resolvers and servers MUST support
BNAME. The synthesized CNAME in the answer section for the BNAME
will never be signed if there has one.
If the owner name of the bname is the suffix of the name queryed but
Yao, et al. Expires February 20, 2011 [Page 9]
Internet-Draft bname August 2010
different, DNSSEC validators MUST understand BNAME, verify the BNAME
and then checking that the CNAME was properly synthesized in order to
verify the synthesized CNAME.
If the owner name of the bname is same with the name queryed, DNSSEC
validators MUST understand BNAME and verify the BNAME. The BNAME
enabled resolver (validator) should do somewhat analogous to a CNAME
for further query.
In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
map SHOULD be checked to see that there was no BNAME that could have
been applied. If the BNAME bit in the type bit map is set and the
query type is not BNAME, then BNAME substitution should have been
done.
5.2. BNAME alias algorithm identifiers
In order to prevent BNAME-unaware resolvers from attempting to
validate responses from BNAME-signed zones, this specification
allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA-
BNAME-SHA1 is an alias for algorithm 3, DSA. Algorithm Z, RSASHA1-
BNAME-SHA1 is an alias for algorithm 5, RSASHA1. These are not new
algorithms, they are additional identifiers for the existing
algorithms. Zones signed according to this specification MUST only
use these algorithm identifiers for their DNSKEY RRs. The BNAME-
unaware resolvers will not know these new identifiers and treat
responses from the BNAME signed zone as insecure, otherwise the bname
RR will be regarded as bogus if there is no such a mechanism. These
algorithm identifiers are used with the BNAME hash algorithm SHA1.
Using other BNAME hash algorithms requires allocation of a new alias.
Validating resolvers which follow the BNAME specification MUST
recognize the new alias algorithm identifier. The future new DNSSEC
algorithms are suggested to indicate the support of BNAME.
5.3. Signaling of BNAME
A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can
be used to signal that the resolvers can understand BNAME in DNSSEC.
BNAME aware resolvers can set the Understand-BNAME (UB bit) to
receive a response without the synthesized CNAMEs. The UB bit is
part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers
should set this in a query to request omission of the synthesized
CNAMEs.
If the query is a DNSSEC query, the BNAME enabled resolvers MUST set
the UB bit in the query. The server receiving the UB bit MUST not
issue synthesized CNAMEs. Servers copy the UB bit to the response,
and should delete the synthesized CNAMEs from the answer if there has
Yao, et al. Expires February 20, 2011 [Page 10]
Internet-Draft bname August 2010
one.
If the query is the DNSSEC query but the UB bit is not set, the
server should follow the rules below:
o If the owner name of the bname is the suffix of the name queryed
but different, when preparing a response, a server performing a
BNAME substitution will in all cases include the relevant BNAME RR
in the answer section. An unsigned CNAME RR is synthesized and
included in the answer section. This will help the client to
reach the correct DNS data.
o If the owner name of the bname is same with the name queryed, when
preparing a response, a DNSSEC enabled server performing a BNAME
substitution will not include the relevant BNAME RR and its RRSIG
RR in the answer section unless the type queryed is BNAME. An
unsigned CNAME RR will be synthesized and included in the answer
section unless the type queryed is BNAME.
o Since the BNAME-unaware DNSSEC resolvers do not know the alias
algorithm defined in secton 5.2 of this document, any response
from these zones signed with these alias algorithms unknown to
them will be regarded as the insecure one according to section 5.2
of [RFC4035].
Below are Updated EDNS extended RCODE and Flags fields [RFC2671]:
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UB| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6. IANA Considerations
IANA is requested to assign the number to XX. This document updates
the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is
requested to assign the number to Y and Z.
[[anchor15: Note in draft: before this document goes to WG Last call,
it is better that we list all DNSSEC algorithms that need to be
aliased to reflect compatibility with this extension.]]
Yao, et al. Expires February 20, 2011 [Page 11]
Internet-Draft bname August 2010
7. Security Considerations
Both ASCII domain name labels and non-ASCII ones have some aliases.
We can bundle the domain name labels and their aliases through BNAME
in the DNS resolutions. The name labels and their aliases in the
particular languages are only known by those who know these
languages. Those labels may be regarded as different ones by those
who don't know those languages. Those who do not know the aliases
should only use the familar ones. The applications will not know the
aliases unless they are properly configured.
8. Acknowledgements
Because the BNAME is very similar to DNAME, the authors learn a lot
from [RFC2672]. Many ideas are from the discussion in the DNSOP and
DNSEXT mailling list. Thanks a lot to all in the list. Many
important comments and suggestions are contributed by many members of
the DNSEXT and DNSOP WGs. The authors especially thanks the
following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
this document.
9. Change History
[[anchor18: RFC Editor: Please remove this section.]]
9.1. draft-yao-dnsext-bname: Version 00
o Bundle DNS Name Redirection
9.2. draft-yao-dnsext-bname: Version 01
o Improve the algorithm
o Improve the text
9.3. draft-yao-dnsext-bname: Version 02
o Add the DNSSEC discussion
o Improve the text
9.4. draft-yao-dnsext-bname: Version 03
o Update the DNSSEC discussion
o Update the IANA consideration
Yao, et al. Expires February 20, 2011 [Page 12]
Internet-Draft bname August 2010
9.5. draft-yao-dnsext-bname: Version 04
o Improve the text
9.6. draft-yao-dnsext-bname: Version 05
o add section: bname examples
o add section: Signaling of BNAME
10. References
10.1. Normative References
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Yao, et al. Expires February 20, 2011 [Page 13]
Internet-Draft bname August 2010
10646", RFC 3629, November 2003.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
10.2. Informative References
[RFC2672bis]
Rose, S. and W. Wijngaards, "Update to DNAME Redirection
in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
17.txt, 6 2009.
Authors' Addresses
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
Yao, et al. Expires February 20, 2011 [Page 14]
Internet-Draft bname August 2010
Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813020
Email: lee@cnnic.cn
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA
Phone: +1 650 779 7001
Email: vixie@isc.org
Yao, et al. Expires February 20, 2011 [Page 15]
View Git Blame Copy Permalink