Current Meeting Report
2.3.2 DNS Extensions (dnsext)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
O. Gudmundsson <firstname.lastname@example.org>
Randy Bush <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Erik Nordmark <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
Description of Working Group:
NOTE: The DNSEXT Working Group actually uses two additional mailing
DNS Security: email@example.com
To Subscribe: firstname.lastname@example.org
Archive: http://www.cafax.se/dnssec/ and
Key Distribution: email@example.com
To Subscribe: firstname.lastname@example.org
The DNSEXT Working Group has assumed the RFCs and drafts of both the
DNSSEC and DNSIND working groups. DNS is originally specified in
RFC's 1034 and 1035, with subsequent updates. Within the scope of
this WG are protocol issues, including message formats, message
handling, and data formats. New work items and milestones may be added
from time-to-time with the approval of the Working Group and the IESG.
Issues surrounding the operation of DNS, recommendations concerning
the configuration of DNS servers, and other issues with the use of the
protocol are out of this Working Group's charter. These issues are
considered in other venues, such as operational issues in the DNS
Operations Working Group.
Broad topics under consideration in DNSEXT are dynamic update, notify,
zone transfers, security and adjustments to address the requirements
of IPv6 addressing. Security topics, mostly inherited from the
erstwhile DNS Security Extensions Working Group, will be addressed in
cooperation with the DNS Operations Working Group.
The principal task within this Working Group is to advance several
documents describing proposed extensions to DNS. The current list of
documents under consideration for advancement is:
Title RFC Status
DNS Server MIB Extensions RFC1611 Proposed
DNS Resolver MIB Extensions RFC1612 Proposed
Serial Number Arithmetic RFC1982 Proposed
Incremental Zone transfer RFC1995 Proposed
Notify RFC1996 Proposed
DNS SRV service location RFC2052 Experimental
Dynamic Update RFC2136 Proposed
Security for Dynamic Update RFC2137 Proposed
Clarification to DNS RFC2181 Proposed
Negative Caching RFC2308 Proposed
DNS Security Extensions RFC2535 Proposed
DSA KEYs and SIGs RFC2536 Proposed
RSA KEYs and SIGs RFC2537 Proposed
Storing Certificates RFC2538 Proposed
Diffie-Hellman Keys RFC2539 Proposed
Extensions to DNS0 RFC2671 Proposed
Non-Terminal DNS names RFC2672 Proposed
Binary Labels RFC2673 Proposed
Other specific work items are:
o TSIG - transaction signatures in (dnsind-tsig-xx.txt)
o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt)
o Securing dynamic update (dnsind-simple-secure-update-xx.txt)
o Protocol clarifications and corrections for DNSSEC
o Clarifications for IANA in DNS assignments
o Documentation of the zone transfer protocol (AXFR)
o Retirement of DNS MIB's RFC's
New work items may be added from time-to-time with the approval of the
Working Group and the IESG.
Goals and Milestones:
|Done|| ||Advance RFC2052bis to RFC. |
|JAN 00|| ||Advance RFC1996 for Draft standard. |
|Done|| ||Advance TKEY and IANA considerations for IESG consideration |
|FEB 00|| ||RFC1995bis and AXFR advanced for Proposed |
|Done|| ||SIG(0) advanced for IESG consideration |
|MAR 00|| ||RFC2136bis advanced for Proposed standard |
|MAR 00|| ||IXFR (RFC1995bis) interoperabilty testing complete |
|APR 00|| ||Serial Number Arithmetic, Notify and DNS Clarify advanced
to Draft Standard. |
|APR 00|| ||RFC1611 and RFC1612 status chaned to historic. |
|MAY 00|| ||RFC2308bis advanced for IESG consideration. |
|Done|| ||Secure update completed and ready for IESG consideration |
|Done|| ||RFC2137 Obsoleted |
|JUN 00|| ||Request that TSIG be advanced to Draft Standard |
|JUL 00|| ||Revised DNSSEC submitted for advancement to Draft Standard |
Request For Comments:
|RFC2782|| PS ||A DNS RR for specifying the location of services (DNS SRV)|
|RFC2845||Standard||Secret Key Transaction Authentication for DNS (TSIG)|
|RFC2931|| PS ||DNS Request and Transaction Signatures ( SIG(0)s )|
|RFC2929||BCP||Domain Name System (DNS) IANA Considerations|
|RFC2930|| PS ||Secret Key Establishment for DNS (TKEY RR)|
|RFC3008|| PS ||Domain Name System Security (DNSSEC) Signing Authority|
|RFC3007|| PS ||Secure Domain Name System (DNS) Dynamic Update|
|RFC3090|| PS ||DNS Security Extension Clarification on Zone Status|
|RFC3110|| PS ||RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)|
|RFC3123|| E ||A DNS RR Type for Lists of Address Prefixes (APL RR)|
|RFC3226|| PS ||DNSSEC and IPv6 A6 aware server/resolver message size requirements|
|RFC3225|| PS ||Indicating Resolver Support of DNSSEC|
Current Meeting Report
IETF 54, Yokohama, July 2002
- Agenda Bashing.
State of Documents (WG document discussion is minuted below)
- Number of documents in the RFC editor queue.
+ gss-tsig is halted to December to be fixed.
It violates the tsig spec
Talks about A6 needs to be redone for AAAA
- IETF last call.
Obvious problems. Need to be done
Still being worked on.
Will be part of the total docset rewrite.
- Back to WG's lap
Number of issues raised by IESG.
No responses from the WG after comments from the AD.
- Ready for last call.
Was waiting for OPT-IN but will be pushed
Needs small clarification.
Not clear if it is ready to go.
- Not ready to go
To bind specific
Needs more work (discussed later)
Few last call comments. Need a volunteer for cut-n-paste of comments. Robert Elz volunteered
The document needs revision, went to last call. Elz and original author will get in touch and will go over the namedroppers archive.
More research is needed.
Will be talked about
- Blocked for other documents
dhcid untouched, work done in dhcp drafts
- Other documents
General remark: IETF interop tests do not name vendors. (see list)
Two implementation are inter-operable
- Advance RFC1886
- no benchmark
- Two tests: Definition of AAAA and IP6.INT
- two servers where fully inter-operable
- two resolvers have identical and correct behaviour
- One server partially conformed
Mailing list: email@example.com
Erik Nordman: Merge to one document.
DS interop test, Russ Mundy/Sam Weiler.
Non complete tests of two implementation. Some of the results maybe implementation problems others may be specification problems.
Need more research.
One issue should the TTL be chained down to effect RRs lower in the
Do it within the zones.
Austein question answered by Mundy: DS seem to solve the issues it was designed for: reducing parent-child interactions
Ed Lewis lots of people are restarting their experiments.
Chairs invite people to publish specific reports and write-ups of workshops and interop tests.
WG documents discussion
Comments where invited for all documents.
Relevant comments below.
Rob Austein: One of the reason that this is staying is maybe that there is more information needed.
Suggestion if ad=on then additional info can be found in the OPT RR.
Steve Bellovin: If you trust the the entity that sets the AD bit you have to setup a trusted/secure path between the resolver and the entity. The document must add that as requirement.
on the mdns-10.txt
Audience: Why both mdns and discover?
chairs: because they are different
Rob Austein: rfc2535 down-case names in rdata. unknown-rrs-03 forbids this. This can be dealt with in DNSSEC but it needs to be clarified.
draft-ietf-dnssext-opt-in-02.txt Roy Arends
Changes in opt-in
OPT-IN now only on delegation points.
- All authoritative RR types must be signed.
- The parent is not authoritative for delegation NS RRs.
Changes in security model
- 2535 NXT proves existence.
- OPT in: lack of NXT bit means no secure delegations.
OPT-IN Corner Cases.
No document yet.
- OPT-IN vs AD-bit
+ AD bit must be cleared on a negative OPT-IN response.
+ This need clarification
- NXT+SIG RRs are statements on security of a response.
+ Do not cache them individually.
+ Cache them as properties of a response.
There are a number of a caching problems. The issues are really implementation issues.
- OPT-IN NXT should really only be cached as a property of another RR.
DNSSEC is already complex. Does OPT-IN justify the added complexity.
Where is the resolver implementation?
If DS turns out to be stable there is little time for OPT-in left. There is a opt-in resolver (and server) implementation. Expected to be in bind soon.
There are implementations of opt-in: 2 servers and 1 resolver
Nordmark: Is anybody working on the additional implementation complexity?
Conrad: OPT in is implemented according to 01. The caching behaviour has not be implemented.
Vixie: ISC has no policy on OPT in. Good code will be put in.
Austein: Treading the NXT RRs as properties of RRset. There are issues with the TTL.
Bush: Current discussion is around corner cases. Both DS and OPT-IN need flag-date; DS signing testing will continue. By and of August there should be a document set for DS. Then estimate how long additional OPT-IN would take. So mid September an assessment will be made if to OPT-IN will be going into the document set.
Threat model not finished yet.
Bellovin: There are a lot of '*' MX records.
Typos can lead to email going to the wrong place. That is a problem that should be dealt with.
Conrad: Implementing the validation was to difficult with bit-string labels. The solution needs on-line signing. There is an implementation that does that now bit-stings have gone.
Atkins: <scribe: missed his remark>
Yuji Kamite presented the draft changes.
- renewal process a phase 2 process
- defined adoption message to begin using new key. Waiting for IANA considerations need
- Only DH will not use GSS. DH will be mandatory
Ted Lemon: DHCID language is correct, DHCPD will be modified; redundant text will be removed.
Kitamura San presented abstract of draft
There is an implementation.
Keep discussing and revising.
Goal is informational RFC.
- Draft documents a problem with queries that get multiple responses in a multicast environment.
Looking for experimental status.
Bush/Austin: Is this to be used on anycast? If this is to be used in an anycast situation the security section needs to be updated.
Anycast situation need clarification
Notes by Olaf Kolkman with help from Scott Rose
RFC1886 Interop Tests Reports