Internet DRAFT - draft-gieben-bert-response
draft-gieben-bert-response
DNSEXT R. Gieben
Internet-Draft NLnet Labs
Expires: May 17, 2005 November 16, 2004
Online Signing of Negative and Wildcard Responses
draft-gieben-bert-response-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on May 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This draft contains a number of loose ends and does not include any
text on any (known) corner cases. Its primary goal is to document
the choices the DNSEXT working group has on the subject of fixing the
NSEC enumeration in DNSSEC. If at any point in time the working
group feels this idea needs further work, this draft will be updated.
DNSSECbis [RFC LIST] allow for zone enumeration by walking NSEC
chains. It also has a large impact on the zone size at the initial
Gieben Expires May 17, 2005 [Page 1]
Internet-Draft BERT Resource Record November 2004
deployment stage. This draft proposes a method to address these
issues by the use of online signing of negative and wildcard
responses.
1. Method
To achieve the goal of online signing we will introduce the Basic
Error Response Type (BERT) meta record (type = TBD). We will sign
the BERT meta record to indicate the type of negative response and
the type(s) covered.
The BERT record contains two fields. A Rcode field, 8 bits long.
Which can hold two values: "No Error" or "Name Error" [RFC 1034/35].
The second is the type covered field, which is 16 bits.
Rcode field:
No Error: A No Error rcode indicates that the <QNAME, QCLASS>
tuple exists in the DNS but the QTYPE does not.
Name Error: A Name Error rcode indicates that the <QNAME, QCLASS>
tuple does not exist.
Type covered field: This is normally the QTYPE value from the
original query but MUST be set to `*` (255) for Name Error
response and No Data responses from empty non-terminal nodes.
This record is signed with online DNSKEY(s) by the authoritative
server for the zone with a TTL derived from the SOA MINIMUM field.
The resulting RRSIG is included in the response to the client.
Multiple signatures are allowed.
Since this method requires online signing there is no longer the need
to special case wildcard records. These will now be signed on the
fly. This in turn simplifies negative responses, as there is no
longer the need to prove that the original QNAME does not exist.
2. DNSKEY Considerations
A zone can choose whether to share a common key for online signing or
each authoritative server can have its own zone signing key or use a
mixture. The key signing key should not be shared amongst the
servers. Note: all public keys used to perform online signing MUST
be in the DNSKEY RRset.
[Loose end]
Gieben Expires May 17, 2005 [Page 2]
Internet-Draft BERT Resource Record November 2004
3. RRSIG Considerations
Signatures generated by this method can be cached by the
authoritative server as a aid against DoS attacks or broken clients.
[Loose end]
4. Interaction with DNSSECbis
To permit this online signing method to interact with DNSSECbis we
will take the high bit from the algorithm field of the DS record and
use it to indicate whether the child zone is signed with DNSSECbis or
this online signing method, 0 indicates DNSSECbis, 1 indicates this
method.
[Editors Note: Needs more work, Loose End] Islands of trust need to
know a priori which DNSSEC method is being used. They can tell this
by looking at the ALG field of the DS records.
5. Security
Zones signed with this online signing method will appear to be
insecure to DNSSECbis servers. The DNSSECbis resolvers will not
understand the algorithm.
Then there are the usual risks associated with keeping keys online.
One of the operational impacts of using online signing is that a
primary server feeding a couple of slave servers is less easily
setup. Because an administrators is faced with the problem of how to
distribute the private keys(s) used to generate the BERT RRs.
The DS BERT records can either be generated on the fly or be
precomputed.
6. Acknowledgements
7. Loose Ends
Some of the loose ends not covered in this draft are, SERVFAIL
reponses, DoS attacks on nameservers. Key consideration for slave
servers. General key usage issues; how long to use, what length.
RRSIG considerations. Empty non terminals. Rcode of the BERT
message itself. In which section should these RR be placed.
Ed Lewis:What happens if there is a mix of DNSSECbis and "this
method" keys in a DS set? Maybe we need a different signalling
Gieben Expires May 17, 2005 [Page 3]
Internet-Draft BERT Resource Record November 2004
indicator.
If the working group decides so, these loose ends will be tied up.
Author's Address
Miek Gieben
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
The Netherlands
EMail: miek@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
Gieben Expires May 17, 2005 [Page 4]
Internet-Draft BERT Resource Record November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gieben Expires May 17, 2005 [Page 5]
