2.3.2 DNS Extensions (dnsext)

Last Modified: 2003-08-11

Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <okolkman@ripe.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.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

    DNS Security: dnssec@cafax.se
    To Subscribe: dnssec-request@cafax.se
    Archive: http://www.cafax.se/dnssec/ and
    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

  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
Done  SIG(0) advanced for IESG consideration
Done  RFC1995bis and AXFR advanced for Proposed
Mar 00  RFC2136bis advanced for Proposed standard
Done  IXFR (RFC1995bis) interoperabilty testing complete
Apr 00  Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.
Done  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
  • - draft-ietf-dnsext-axfr-clarify-05.txt
  • - draft-ietf-dnsext-gss-tsig-06.txt
  • - draft-ietf-dnsext-dhcid-rr-06.txt
  • - draft-ietf-dnsext-dnssec-roadmap-07.txt
  • - draft-ietf-dnsext-unknown-rrs-06.txt
  • - draft-ietf-dnsext-mdns-22.txt
  • - draft-ietf-dnsext-ad-is-secure-06.txt
  • - draft-ietf-dnsext-delegation-signer-15.txt
  • - draft-ietf-dnsext-dnssec-opt-in-05.txt
  • - draft-ietf-dnsext-rfc2536bis-dsa-03.txt
  • - draft-ietf-dnsext-rfc2539bis-dhk-03.txt
  • - draft-ietf-dnsext-dnssec-intro-05.txt
  • - draft-ietf-dnsext-ecc-key-04.txt
  • - draft-ietf-dnsext-tkey-renewal-mode-03.txt
  • - draft-ietf-dnsext-dns-threats-03.txt
  • - draft-ietf-dnsext-dnssec-records-03.txt
  • - draft-dnsext-opcode-discover-01.txt
  • - draft-ietf-dnsext-keyrr-key-signing-flag-08.txt
  • - draft-ietf-dnsext-rfc1886bis-03.txt
  • - draft-ietf-dnsext-dnssec-protocol-01.txt
  • - draft-ietf-dnsext-ipv6-name-auto-reg-01.txt
  • - draft-ietf-dnsext-insensitive-03.txt
  • - draft-ietf-dnsext-dnssec-2535typecode-change-04.txt
  • - draft-ietf-dnsext-wcard-clarify-01.txt
  • Request For Comments:
    A DNS RR for specifying the location of services (DNS SRV) (RFC 2782) (24013 bytes)
    Secret Key Transaction Authentication for DNS (TSIG) (RFC 2845) (32272 bytes)
    Domain Name System (DNS) IANA Considerations (RFC 2929) (22454 bytes)
    Secret Key Establishment for DNS (TKEY RR) (RFC 2930) (34894 bytes)
    DNS Request and Transaction Signatures ( SIG(0)s ) (RFC 2931) (19073 bytes)
    Secure Domain Name System (DNS) Dynamic Update (RFC 3007) (18056 bytes)
    Domain Name System Security (DNSSEC) Signing Authority (RFC 3008) (13484 bytes)
    DNS Security Extension Clarification on Zone Status (RFC 3090) (24166 bytes)
    RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (RFC 3110) (14587 bytes)
    A DNS RR Type for Lists of Address Prefixes (APL RR) (RFC 3123) (14648 bytes)
    Applicability Statement for DNS MIB Extensions (RFC 3197) (8610 bytes)
    Indicating Resolver Support of DNSSEC (RFC 3225) (11548 bytes)
    DNSSEC and IPv6 A6 aware server/resolver message size requirements (RFC 3226) (12078 bytes)
    Representing IPv6 addresses in DNS (RFC 3363) (11055 bytes)
    Tradeoffs in DNS support for IPv6 (RFC 3364) (26544 bytes)
    Obsoleting IQUERY (RFC 3425) (8615 bytes)
    Limiting the Scope of the KEY Resource Record out (RFC 3445) (20947 bytes)

    Current Meeting Report

    IETF 57 - Vienna, Austria
    DNSEXT Minutes
    Olafur thanked Randy Bush for his long service as WG chair and welcomed
    Olaf  Kolkman as the new co-chair.
      Text on list
      Focus on DNSSEC docs and its dependencies
        Process in the coming 2-3 months
      Important to have the core documents reviewed by more people
      Once DNSSEC done, advance docs that are in PS status to DS
        List put out of docs and will be used to build milestones
    Update from AD
      OPT-IN to Informational RFC, instead of Experimental
      Question on why INFO vs. EXP, answer was WG didn't accept, but there is 
    need to document this for history.
      Since code exists and its sort-of half-baked, and people may want to 
    "play" with it, it should be EXP.
      INFO: here's the endpoint, we're not putting on ST, EXP: go play 
    withthis and come back
      More words needed as to why decision was made, chairs to draft 
    boilerplate text for document.
      WG defining RR to store IPSEC Keys for Opportunistic Encryption, Will be 
    most likely defining new IANA registry to key types for IPSECKEY if you 
    think that's not a good idea, speak up on IPSECKEY WG list
      18 Issues raised and 17 resolved
      WG Last Call asked for in email
    DNSSEC Editors Report
      Want more input on the drafts from the list
      4 drafts, 1 is threats, other 3 are BIS core drafts
      Open Issues
        Unresolved questions posted to list with some still unresolved
        Type code rollover
          draft may be revised to create new registry for new types
          not sure if that's necessary
          motivation came from wanting to keep KEY/SIG for SIG(0) uses
          new registry will allow DNSKEY/RRSIG to drop cruft from current 
          are there any issues with having all of these new registries?
            IANA might be concerned about it due to the number of 
        DS and Wildcard draft
          DS is in IESG last call
          Waiting on wildcard clarify
    DNSSEC-editors Question 6: should caches retain failed 
    verifications (rephrase: how to interpret CD bit) Should caches try to 
    reduce the number of identical queries going out by caching failed 
    verification responses? CD bit just an optimization (a way to tell 
    recursive nameserver you don't have to check SIGs if you don't want to) 
    should CD be: I'm going to check SIGs, stay out of my way. one 
    interpretation of RFC2535 is to say if verification fails, the 
    recursive nameserver must drop the data SERVFAIL is not a good response 
    when DNSSEC fails, need way to tell application what failed, why, where to go 
    threat: if recursive nameserver's clock is wrong, but application host's 
    clock is right, indirect DOS, which is unacceptable any other thoughts on CD 
    bit, discuss on list
    Wildcard Clarification
      Since March
        Proof to formalize the notion/definition of closest encloser
        Split document into 2 pieces
          Pre-DNSSEC and DNSSEC parts
          document contains 1034 updates and DNSSEC updates
          chapters 1-5, and appendix Appendix A update 1034
          chapters 6,7 update/clarify DNSSEC
      Clarifying 1034 (Pre-DNSSEC)
        Existence statement
        Impact of Wild Card domain name owning particular RRs (CNAME, NS,
        DNAME, SOA)
        Related to CNAME-change to 4.3.2-3.c
      DNSSEC Part
        Rules for NXT's as part of authenticated denial as it relates to
        wild cards
        Fix up the proof, Bob would like someone with more formal math
        knowledge to check over proof
        Add "recipe" resulting from proof for implementor
        Where does this "part" go?
        1034 words too vague
        what happens to CNAMES owned by wild card names?
        according to 4.3.2 its okay
        MAY? SHOULD? MUST? reject zone on load?
          no - don't say anything on wild cards owning NSs
        DNAME has problems, not specifically related to wild cards
        doesn't need discussion...
      Q: for these things that are deemed non-scenical, are implementor going to 
    be directed to give horrible errors?
      it might not make sense to bar these at this time
      CNAME: not sure there's no problem text in 1034 is advisory, not a 
    step-by-step procedure, different implementor might do steps in 
    different order, it might be good to write the steps into a protocol 
      Q: is this necessary for the Pre-DNSSEC stuff? DNSSEC stuff is 
      Yes, the issue is 2 different servers doing it differently (a master and a 
      Change to 4.3.2-3.c
        add explicit text for CNAME chasing
        Add text to clarify "* NS"
        Modify step 3.c of 4.3.2 in 1034
        Move DNSSEC text to own document
        Add "recipe" resulting from proof, edit proof
      Q: should these DNSSEC bits be put into a separate doc and 
    progressed and then added to BIS documents by editors
      Not sure, depends on what the change is
      Comment: If we're going to mess with 4.3.2-3.c, then let's go ahead and 
    make  all the necessary changes to the algorithm change it from 
    advisory  to a nailed-down set of steps
      Chair: move DNSSEC parts to dnssec-BIS documents, only update 1034 in 
    your document.
    TSIG Interoperabilty Testing Results
      Goal to move RFC2845 from PS to DS
      Must do interop tests with at least 2 independent 
        Client-Server (C-S)
        Slave-Master (S-M)
        Client-Forwarder-Server (C-F-S)
      Preliminary report at
        Full or partial interoperabilty found depending on category of
        tests (C-S, S-M, C-F-S)
      Q: were "other" clients (dhcpd doing TSIG dynups) tested?
      Q: was any feedback given back to implementor on error messages due to 
    error conditions?
      don't think so
    Secure Notify
      (diagrams showing zone relationships and steps in SEP key rollover)
        automate parent-child interactions
        derived trust from established trust anchor (e.g. parent DS record)
        change parent-child interactions from OPS issue to Protocol issue
        Remove human from loop for routine actions
        use NOTIFY from child to signal changes in
          Apex SEP KEY RRs
          NS records
          Glue? (maybe, maybe not)
        Secure NOTIFY by
          SIG(0) from SEP KEY
          chains to parent's DS
        Type code change removes SIG(0) for SEP KEY (SEP DNSKEY)
          Will be resolved by TSIG(0) document (proposed)
      Q: Does this require that the SEP bit be set?
        yes that doc said that that bit would be info only, not used for 
    protocol then why put it in the protocol? it should be used really 
    applies to verification protocol - shouldn't be used there, but uses like 
    this are okay
      Q: Use a key that belongs to the child to talk to the registry? no, not 
    the registry, but to the master this changes the way registries 
    interact with masters don't think so, parent may choose to not accept this 
    packet, doesn't affect how registries talk to masters
      Chair: should separate DS bits from NS bits, parent zone has no way to 
    check whether child zone is properly configured, updating NS could be 
    harmful isn't it local policy to do that? lots of checks must be done to 
    protect DNS from bad operators
      Comment: worried about adding new features to NOTIFY, designed along 
    SNMP-TRAP theory: hint that now would be a good time to pull NOTIFY is 
    pre-DNSSEC, since NOTIFY can be signed, data can be included 
    preference to use UPDATE rather than NOTIFY UPDATE semantics don't 
    cleanly fit this model
      Comment: could be really, really useful in the reverse tree 
    universities have delegated entire /24s to departments who run their own 
    nameservers policy would fit well automatic tunnel brokers using reverse map 
    are also a good fit
      Q: what can i do with this, that i can't do with dynamic update? DS 
    doesn't belong to child, DS is just a hash of my key technically, 
    content of DS belongs to child, but signature of DS belongs to parent
      Comment: another key change document that uses only 1 DS at a time
      Comment: no shortage of opcodes, let's define a new opcode for it don't 
    want to write yet another draft
      Comment: using dynamic update does remove one timing dependency
      Mike: trust anchor sits in SEP key, could you expand on that in the doc
      Q: is work in this area important for this WG?
      Chair: this doc makes changes to the protocol, must be DNSEXT, but it 
    makes assumptions based on ops possibility all of this work gets dumped 
    into a completely new WG
      Q: this WG or another WG? DNSEXT can take this work on if it doesn't go 
    anywhere else not a prereq for the base docs
      Comment: cautious about changing the protocol since other protocol 
    changes are being made for the DNSSEC stuff not sure if it is a good 
    general solution
      Chair: key management issues are a major deployability issue for DNSSEC 
    this needs to be looked at really hard wants the key management 
    "pieces" to work on their own
      Chair: even with this doc in DNSEXT and changing the protocol, 
    addressing ops issues  maybe there are other solutions that address the 
    same problem
      Chair: number of requirements assumptions that need to be fleshed out may 
    be a couple of good, effective ways to solve it there are multiple 
    requirements with multiple solutions
      Comment: come to DNSOP and discuss things there
    Final Comment
    There are now two tall Vikings running DNSEXT and if no one reads the 
    documents, we will be using our Viking knowledge 


    Wildcard Clarify
    Flow chart
    Interoperability Tests Report for RFC2845 (TSIG)
    Interoperability Tests Report for RFC2845 (TSIG)