Current Meeting Report
Slides


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

Chair(s):
O. Gudmundsson <ogud@ogud.com>
Randy Bush <randy@psg.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.com>
Mailing Lists:
General Discussion: namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: ftp://ops.ietf.org/pub/lists/
Description of Working Group:
NOTE: The DNSEXT Working Group actually uses two additional mailing lists.

DNS Security: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list Key Distribution: keydist@cafax.se To Subscribe: keydist-request@cafax.se Archive: ftp://ftp.cafax.se/pub/archives/keydist.list

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 (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt)

o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt)

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
Internet-Drafts:
  • - draft-ietf-dnsext-axfr-clarify-04.txt
  • - draft-ietf-dnsext-gss-tsig-05.txt
  • - draft-ietf-dnsext-dhcid-rr-05.txt
  • - draft-ietf-dnsext-dnssec-roadmap-05.txt
  • - draft-ietf-dnsext-dnsmib-historical-00.txt
  • - draft-ietf-dnsext-unknown-rrs-03.txt
  • - draft-ietf-dnsext-mdns-10.txt
  • - draft-ietf-dnsext-ad-is-secure-06.txt
  • - draft-ietf-dnsext-obsolete-iquery-03.txt
  • - draft-ietf-dnsext-delegation-signer-08.txt
  • - draft-ietf-dnsext-dnssec-opt-in-02.txt
  • - draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt
  • - draft-ietf-dnsext-rfc2536bis-dsa-02.txt
  • - draft-ietf-dnsext-rfc2539bis-dhk-02.txt
  • - draft-ietf-dnsext-dnssec-intro-01.txt
  • - draft-ietf-dnsext-ecc-key-02.txt
  • - draft-ietf-dnsext-ipv6-addresses-02.txt
  • - draft-ietf-dnsext-tkey-renewal-mode-01.txt
  • - draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
  • - draft-ietf-dnsext-dns-threats-01.txt
  • - draft-ietf-dnsext-dnssec-records-01.txt
  • - draft-dnsext-opcode-discover-00.txt
    • Request For Comments:
    RFCStatusTitle
    RFC2782 PS A DNS RR for specifying the location of services (DNS SRV)
    RFC2845StandardSecret Key Transaction Authentication for DNS (TSIG)
    RFC2931 PS DNS Request and Transaction Signatures ( SIG(0)s )
    RFC2929BCPDomain 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

     Minutes DNSEXT
    IETF 54, Yokohama, July 2002

    - Agenda Bashing.

    No 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

    + message-size
    Talks about A6 needs to be redone for AAAA

    - IETF last call.

    + restrict-key-for-dnssec
    Obvious problems. Need to be done

    + delegation-signer-0.8
    Still being worked on.

    Will be part of the total docset rewrite.

    - Back to WG's lap

    + ad-is-secure-06.txt
    Number of issues raised by IESG.

    + dnssec-roadmap-05.txt
    No responses from the WG after comments from the AD.

    - Ready for last call.

    + dnssec-records-01.txt
    Was waiting for OPT-IN but will be pushed

    + unknow-rrs-03.txt
    Needs small clarification.

    + dnssec-intro-01.txt

    + rfc2536bis-dsa-01
    + rfc2539bis-dhk-01

    + mdns-10.txt
    Not clear if it is ready to go.

    - Not ready to go

    + axfr-clarify
    To bind specific

    + dnssec-opt-in
    Needs more work (discussed later)

    + obsolete-iquery-0.3.txt
    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.

    + dns-threats-02
    More research is needed.

    + tkey-renewal-mode-0.2
    Will be talked about

    - Blocked for other documents

    + ecc-key-01
    + dhcid-rr-05

    dhcid untouched, work done in dhcp drafts

    - Other documents

    + kitamura-ipv6-name-auto-reg-01

    + opcode-discover-00.txt
    Experimental.

    ----------------------------------------------------------------------
    Interoperability reports
    ------------------------

    General remark: IETF interop tests do not name vendors. (see list)


    RFC1886
    Vladimir Ksinant

    Two implementation are inter-operable


    Goals:
    - Advance RFC1886
    Non goals:
    - no benchmark
    - Two tests: Definition of AAAA and IP6.INT

    Features tested:
    A. AAAA
    ....

    Test results
    - two servers where fully inter-operable
    - two resolvers have identical and correct behaviour
    - One server partially conformed
    Mailing list: rfc1886@nic.fr
    www.ipv6.6wind.com/standard/testRFC1886.nic.fr

    Comment:

    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.

    Sam Weiller
    One issue should the TTL be chained down to effect RRs lower in the

    Derek Atkins:
    Do it within the zones.

    Austein question answered by Mundy: DS seem to solve the issues it was designed for: reducing parent-child interactions

    DNSSEC@cafax.se 'meeting'

    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.


    draft-ietf-dnsext-ad-bit-is-secure-06.txt

    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


    unknown-rrs-03.txt

    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

    Caching Responses

    - 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.

    Concerns raised

    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.


    dnsext-dns-threats-01

    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>
    tkey-renewal-01

    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

    no comments.

    dnsext-dhcid-rr-05

    Ted Lemon: DHCID language is correct, DHCPD will be modified; redundant text will be removed.


    kitamura-ipv6-name-auto-reg-01
    Kitamura San presented abstract of draft
    There is an implementation.
    Keep discussing and revising.
    Goal is informational RFC.

    No comments.

    draft-dnsext-opcode-discover-00.txt

    Bill Manni<ng:

    - 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

    ----------------------------------------------------------------------
    AOB
    ---

    None.

    -------------------------------------------------------------------------
    Notes by Olaf Kolkman with help from Scott Rose


    Slides

    RFC1886 Interop Tests Reports