draft-ietf-dnsext-dnssec-okbit-01.txt   draft-ietf-dnsext-dnssec-okbit-02.txt 
INTERNET-DRAFT David Conrad INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-01.txt Nominum Inc. draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc.
November, 2000 May, 2001
Indicating Resolver Support of DNSSEC Indicating Resolver Support of DNSSEC
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 19 skipping to change at page 2, line 19
For the purposes of this document, "DNSSEC security RRs" are For the purposes of this document, "DNSSEC security RRs" are
considered RRs of type SIG, KEY, or NXT. considered RRs of type SIG, KEY, or NXT.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Rationale 2. Rationale
As DNSSEC is deployed, the vast majority of queries will be from Initially, as DNSSEC is deployed, the vast majority of queries will
resolvers that are not DNSSEC aware and thus do not understand or be from resolvers that are not DNSSEC aware and thus do not
support the DNSSEC security RRs. When a query from such a resolver understand or support the DNSSEC security RRs. When a query from
is received for a DNSSEC signed zone, the DNSSEC specification such a resolver is received for a DNSSEC signed zone, the DNSSEC
indicates the nameserver must respond with the appropriate DNSSEC specification indicates the nameserver must respond with the
security RRs. As DNS UDP datagrams are limited to 512 bytes appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
[RFC1035], responses including DNSSEC security RRs have a high 512 bytes [RFC1035], responses including DNSSEC security RRs have a
probability of resulting in a truncated response being returned and high probability of resulting in a truncated response being returned
the resolver retrying the query using TCP. and the resolver retrying the query using TCP.
TCP DNS queries result in significant overhead due to connection TCP DNS queries result in significant overhead due to connection
setup and teardown. Operationally, the impact of these TCP queries setup and teardown. Operationally, the impact of these TCP queries
will likely be quite detrimental in terms of increased network will likely be quite detrimental in terms of increased network
traffic (typically five packets for a single query/response instead traffic (typically five packets for a single query/response instead
of two), increased latency resulting from the additional round trip of two), increased latency resulting from the additional round trip
times, increased incidences of queries failing due to timeouts, and times, increased incidences of queries failing due to timeouts, and
significantly increased load on nameservers. significantly increased load on nameservers.
In addition, in preliminary and experimental deployment of DNSSEC, In addition, in preliminary and experimental deployment of DNSSEC,
skipping to change at page 4, line 14 skipping to change at page 4, line 14
DNSSEC security RRs and SHOULD retry the query without the EDNS0 in DNSSEC security RRs and SHOULD retry the query without the EDNS0 in
accordance with section 5.3 of [RFC2671]. accordance with section 5.3 of [RFC2671].
Security Considerations Security Considerations
The absence of DNSSEC data in response to a query with the DO bit set The absence of DNSSEC data in response to a query with the DO bit set
MUST NOT be taken to mean no security information is available for MUST NOT be taken to mean no security information is available for
that zone as the response may be forged or a non-forged response of that zone as the response may be forged or a non-forged response of
an altered (DO bit cleared) query. an altered (DO bit cleared) query.
IANA Considerations IANA considerations:
Allocation of the most significant bit of the Z field in the EDNS0 EDNS0[RFC2761] defines 16 bits as extened flags in the OPT record,
OPT meta-RR is required. these bits are encoded into the TTL field of the OPT record (RFC2761
section 4.6).
This document reserves one of these bits as the OK bit. It is
requested that the left most bit be allocated. Thus the USE of the
OPT record TTL field would look like
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Acknowledgements Acknowledgements
This document is based on a rough draft by Bob Halley with input from This document is based on a rough draft by Bob Halley with input from
Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
Rob Austein, and Steve Bellovin. Rob Austein, Steve Bellovin, and Erik Nordmark.
References References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", RFC 1035, November 1987. Specifications", RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/