2.3.5 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <okolkman@ripe.net>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: http://ops.ietf.org/lists/namedroppers/

Description of Working Group:

DNS was originally specified in RFC's 1034 and 1035, with subsequent
updates.  Within the scope of this WG are DNS protocol issues,
including the specification of message formats, message handling, and
data formats used for DNS client-server and server-server

This WG is focused on advancing the zone transfer, update, notify
and DNSSECbis documents to Draft standard.

The WG works on solutions for DNSSEC deployment issues that may
require protocol modifications. Two of these issues are identified
and are worked on under the umbrella of this WG. 1] (a) method(s) to
prevent the possibility of trivial zone enumeration and 2] a method
for automated rollover of trust-anchors configured in validating

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 scope for this Working Group.  These issues
are considered in other venues, such as the DNS Operations Working

The DNSEXT Working Group sometimes uses an additional mailing list
for discussion of DNS Security related issues. This list is open to

  Discussion: dnssec@cafax.se
  To Subscribe: dnssec-request@cafax.se
  Archive:  http://www.cafax.se/dnssec/ and

The 2535bis document set was edited by a team. This team was
chartered with making editorial changes only, with all substantiative
changes discussed on the WG list. The archive of this editors-only
mailing list is available at:

Specific work items are:

      o Advance the DNSSECbis document set through the standards

      o Clarification of RFC1034/1035 relating to DNSEXT ongoing work.
        + Clarification of wildcard processing rules.

      o After the work items above have been completed the working
        group will continue on reviewing the following existing
        proposed standard and examine if there is a possibility to
        progress them on the standards track.

        + RFC1995 (IXFR)  to Draft standard.
        + RFC1996 (Notify) to Draft standard.
        + RFC2136bis (Dynamic Update) to Draft Standard.
        + RFC2181 (Clarify) to IESG for advancement to Draft Standard.
        + RFC2308 (Neg Caching) to Draft Standard.
        + RFC2671 (EDNS0) to Draft Standard.
        + RFC2672 (DNAME) to Draft Standard, or revision.
        + RFC2845 (TSIG)to Draft standard.
        + RFC2930 (TKEY) to Draft standard.
        + RFC3007 (Secure Update) to Draft standard.
        + RFC3645 GSS/TSIG to Draft Standard       
        + RFC3??? AXFR clarify to Draft Standard.

      o Identify (a) method(s) to prevent the possibility of trivial
        zone enumeration.

      o Define a method for automated rollover of trust-anchors
        configured in validating resolvers.

      o Foster the development of Link Local Multicast Name
        Resolution (LLMNR) standard. The WG has taken up this work
        since LLMNR it is very similar to the DNS protocol.  LLMNR is
        targeted as proposed standard.

The lifetime of the group is set by the work items above but while
these are ongoing the working group has additional tasks:

      o Reviewing and providing recommendations about the
        specification, by other working groups, of RR types that do not
        require any special processing and that do not require any
        special naming conventions.

Goals and Milestones:

Done  Forward NSEC rdata to IESG for Proposed Standard
Done  Forward RFC2535-bis to IESG for proposed standard
Done  Forward Case Insensitive to IESG for Proposed Standard
Done  Forward LLMNR to IESG for Proposed Standard
Feb 05  Update boilerplate text on OPT-IN
Feb 05  Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard
Mar 05  Finalize Zone Enumeration Requirements
Mar 05  Forward Wildcard clarification to IESG for proposed standard
Apr 05  Start of process of reviewing the following RFCs and to move them to Draft Standard status
May 05  Submit to IESG RFC2845 (TSIG)to Draft standard
Jun 05  RFC2671 (EDNS0) to Draft Standard
Jun 05  RFC2672 (DNAME) to Draft Standard or revision
Jul 05  RFC2136 (Dynamic Update) to Draft Standard
Jul 05  RFC3007 (Secure Update) to Draft Standard
Jul 05  RFC1995 (IXFR) to Draft standard
Jul 05  RFC1996 (Notify) to Draft Standard
Sep 05  RFC2930 (TKEY) to Draft standard
Sep 05  RFC2181 (Clarify) to Draft Standard
Sep 05  RFC2308 (Neg Caching) to Draft Standard
Nov 05  RFC2782 (SRV RR) to Draft Standard
Nov 05  RFC1982 (Serial Number Arithmetic)
Nov 05  RFC2538 (CERT RR) to Draft Standard
Nov 05  FRC2539 (DH Key RR) to Draft Standard
Nov 05  RFC3226 (Message Size) to Draft Standard


  • draft-ietf-dnsext-dhcid-rr-09.txt
  • draft-ietf-dnsext-mdns-41.txt
  • draft-ietf-dnsext-dnssec-opt-in-07.txt
  • draft-ietf-dnsext-rfc2536bis-dsa-06.txt
  • draft-ietf-dnsext-rfc2539bis-dhk-06.txt
  • draft-ietf-dnsext-ecc-key-07.txt
  • draft-ietf-dnsext-insensitive-06.txt
  • draft-ietf-dnsext-wcard-clarify-08.txt
  • draft-ietf-dnsext-dnssec-trans-02.txt
  • draft-ietf-dnsext-tsig-sha-04.txt
  • draft-ietf-dnsext-interop3597-02.txt
  • draft-ietf-dnsext-nsec3-02.txt
  • draft-ietf-dnsext-rfc2538bis-03.txt
  • draft-ietf-dnsext-dnssec-experiments-01.txt
  • draft-ietf-dnsext-dnssec-online-signing-00.txt
  • draft-ietf-dnsext-dnssec-bis-updates-01.txt
  • draft-ietf-dnsext-2929bis-00.txt
  • draft-ietf-dnsext-dns-name-p-s-00.txt

    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)
    RFC2929 BCP Domain Name System (DNS) IANA Considerations
    RFC2930 PS Secret Key Establishment for DNS (TKEY RR)
    RFC2931 PS DNS Request and Transaction Signatures ( SIG(0)s )
    RFC3007 PS Secure Domain Name System (DNS) Dynamic Update
    RFC3008 PS Domain Name System Security (DNSSEC) Signing Authority
    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)
    RFC3197 I Applicability Statement for DNS MIB Extensions
    RFC3225 PS Indicating Resolver Support of DNSSEC
    RFC3226 PS DNSSEC and IPv6 A6 aware server/resolver message size requirements
    RFC3363 I Representing IPv6 addresses in DNS
    RFC3364 I Tradeoffs in DNS support for IPv6
    RFC3425 PS Obsoleting IQUERY
    RFC3445 PS Limiting the Scope of the KEY Resource Record out
    RFC3596 Standard DNS Extensions to support IP version 6
    RFC3597 PS Handling of Unknown DNS Resource Record (RR) Types
    RFC3645 Standard GSS Algorithm for TSIG (GSS-TSIG)
    RFC3655 Standard Redefinition of DNS AD bit
    RFC3658 Standard Delegation Signer Resource Record
    RFC3755 Standard Legacy Resolver Compatibility for Delegation Signer
    RFC3757 Standard KEY RR Secure Entry Point Flag
    RFC3833 I Threat Analysis Of The Domain Name System
    RFC3845 Standard DNSSEC NSEC RDATA Format
    RFC4033 Standard DNS Security Introduction and Requirements
    RFC4034 Standard Resource Records for the DNS Security Extensions
    RFC4035 Standard Protocol Modifications for the DNS Security Extensions

    Current Meeting Report

    Minutes of the DNSEXT working group
    63rd IETF, Paris, France
    August 3rd 2005

    Olafur Gudmundsson
    Olaf Kolkman

    Jelte Jansen (minutes)
    Wes Griffin (jabber)

    Previous Minutes

    There were no comments on the previous minutes.

    Agenda Bashing

    There were no comments on the agenda.


    The documents are handled in a last-call order.

    Documents that are past last call:

    draft-ietf-dnsext-mdns-41: waiting for the chairs to go over the document to see if all changes have been made.

    draft-ietf-dnsext-tsig-sha-04: waiting for a chair to make a summary for the area director.

    draft-ietf-dnsext-wcard-clarify-08: chair will write summary and submit the document.

    draft-ietf-dnsext-rfc2538bis-03: exact current state unknown, but it should be close to standard now.

    Documents in last call:
    draft-ietf-dnsext-dns-name-p-s-00 and

    Olaf is not sure what status these documents will need to get, experimental, informational or standards track. There seems to be little interest for these documents, at least on public channels.

    Peter Koch: DENIC would like to see an implementation for this. They are still evaluating, but this is definitely on their path to DNSSEC. He is not sure that experimental is appropriate, since it modifies the protocol.

    Olaf: there won't be any difference on the wire, in the way that packets are built. And if the consensus is to put it on the standards track, this discussion would become irrelevant.

    Olaf asks the working group to heed the last call and look at the documents.

    draft-ietf-dnsext-dnssec-trans-02: the authors would like another round before last call.

    Documents close to last call:

    draft-ietf-dnsext-experiments-01: will be in last call in September.

    The DNSKEY algorithm documents are all ready for last call, last call will start soon (draft-ietf-dnsext-rfc2536bis-dsa-06, draft-ietf-dnsext-rfc2539bis-dhk-06 and draft-ietf-dnsext-ecc-key-07).

    Ongoing work:

    draft-ietf-dnsext-dnssec-bis-updates-01: Olaf asks the working group to send anything of notice (implementors, readers who see weird language, etc.) in the DNSSEC docs to Sam Weiler, so it can be included.

    draft-ietf-dnsext-nsec3-02: there is a new version of this document. Olaf Kolkman wants at least one workshop with running code before advancing this document, between now and the IETF in Vancouver.

    Olaf Kolkman mentions that old and expired documents can be found on http://tools.ietf.org/wg/dnsext

    Update on NSEC3

    Roy Arends reports that most of the changes in the document are textual. There is still some uncertainty on whether truncating hashes is a good idea. Now the documents allows for a signal that hashes are truncated. There are some clarifications on dos issues, and an example has been included.

    They are waiting for -trans and -ter to stabilize before specifying the way to indicate NSEC3 is used.

    The next version of the document will address rolling NSEC to NSEC3.

    Some tools have been implemented: an NSEC3-capable signer, based on Net::DNS(::SEC), and a NSEC3-capable server for testing corner cases.

    There should also be NSEC2 patches for bind, but we'll see that on the list.

    Mark Kosters: we plan to have nsec3-capable servers before the workshop.

    Miek Gieben asked why include opt-in?

    Roy still thinks technically there's nothing wrong with it. OPT-IN would have stopped progress on last docs, now time is right.

    There was some further discussion if NSEC3 and OPT-IN are separative and/or required. Chair made the comment that if Opt-In feature is removed from NSEC3 then that requires changing the name to NSEC4. A large operator commented that they will not deploy DNSSEC without opt-in for number of operational reasons including significant churn of names.

    Rob and chairs appeals to room: please review the old discussion on OPT-IN.

    IPR Issues update

    Olafur reports that there are two different drafts to manage trust anchors:
    draft-ietf-dnsext-trustupdate-timers-00 and

    Both documents have had an IPR claim filed against them. The patent this has been issued in one country at the moment (Israel) but filed in some other countries as well, just not approved (yet). There is a license available that is royalty free, but does have some terms. So implementors either don't know what to do or are ignoring it.

    Automatic Updates of DNSSEC trust anchors

    Olafur Gudmundsson reports that having no key management standard might become the next excuse for not deploying DNSSEC. Early adaptors may need to bear additional costs configuring trust anchors. The need for configured trust anchors will never disappear, in the best case it might be reduced to only one anchor, the root. Olafur pleas to the working group for more activity here. Authors are frustrated with the complete silence on this issue, they cannot continue until there is discussion, feedback, a list of selection criteria and a time line.

    Bill Manning: I see silence as consent, and the document should go to last call.

    Mike StJohns: Well the problem is that there are two documents that met with silence, so my document was approved-by-silence too.

    Olaf Kolkman: the working group decided once that there should only be one solution. On the other hand these documents do not exclude each other, one is purely operational.

    Mike StJohns: I disagree, both change resolver behavior.

    Mark Andrews: We definitely need to decide on one or the other, because it will have impact on how operators do their key management. I do not want to try managing both.

    Sam Weiler: I'm not sure if we have to make a choice, is there any harm in a resolver not following these drafts?

    Mike StJohns: by ignoring the timer bit the trust anchors won't be updated and things go stale.

    Olafur: and in the case of 2 mechanisms there should be signalling for zones to declare which method they use.

    Mark Andrews: Well something has to notice keys are changing, not necessarily resolvers, so they don't have to change. It could be an external tool.

    Russ Mundy: My understanding is that the mechanism should not prevent other mechanisms to update keys.

    Olafur: Yes, this is just a way for validator to do it in-band.

    Mike: if you have a mechanism people will not pay as much attention, and those who don't will fall behind.

    Russ: but it was not intended to be an exclusive mechanism.

    Mike: If operators are making different choices a signalling mechanism becomes interesting.

    Sam Weiler: I was hearing this 'you have to have a signaling mechanism' as 'you have to have one in-band', which suggests to me that you have to have one whether you use one of these schemes or none at all. If we can get away with saying it's all out of band when you first configure a trust anchor you say which method you're using, then the proposals are not mutually exclusive.

    Mike: A problem is, the trust anchor may or may not do automatic rollover, but you don't know when you configure your server.

    Olaf: The keying policy needs to be known.

    Mike: The policy will be decided by the one that ships the software. Most people will ignore it, do whatever works.

    Rip Loomis: I have read both drafts, and could not decide on one. Could the authors make statements why their solution is the better one? Or if someone thinks we can do both, please say that. Another point: even if you have auto-rekey, there should still be a methodology to do it manually.

    Sam Weiler: I heard Mike wants to be able to use schemes with already configures trust anchors.

    Mike: Well anything we can do to off load operator load on end-users will improve deployment. Like web browser certificates.

    Olaf: I think we all agree that we don't want people going back to their configuration and changing things all the time.

    Rip Loomis: I would like a 1 paragraph statement (or abstracts or differences) about the drafts from the authors on the list.

    Bill Manning: I would like someone unbiased and not involved in these documents to write a short document with abstracts and differences

    Jim Cassels is volunteered to do this. He agrees.
    Action point: Jim Cassels will write a short document on the differences between the two automated key rollover drafts.

    Rob Austein: Could we have a verbal summary now?

    Wes Hardaker: If i look at other protocols with keys, the ones without automatic key rollover get deployed, but the keys just never change. They are not rolled at all or their lifetimes are exceptionally long.

    Olaf: We could say we use very short lifetimes, so the operators will get bitten quickly. That's the other way to get keys changed.

    Wes: Only if you document that in advance in a protocol, otherwise users will do whatever they want.

    Olafur Summarizes the two drafts, and asks if people have feelings about either one.

    Mike: the revoke solution deals explicitly with key compromise, not operational errors.

    Rob Austein (directed to Olaf Kolkman): you recently did tests on bandwidth usage with DNSSEC. Does the n out of m proposal have a lot of impact on servers in that way?

    Olaf: currently there is an implementation that sends the key in the additional section of the answer packet. With that implementation, it would have a lot of impact. Apart from that, it is an orthogonal question. Only relevant if the DNSKEY RRset lives in the answer or authority section of the packet, because then we'll get truncation issues. We should try to keep the packet sizes below 2048 bits, because that's what i see on the wire now.

    Olafur shows an old spreadsheet that shows DNSKEY packet sizes for different algorithms with different numbers of keys.
    Assuming: domain: ogud.com
    Assuming: always a rollover in progress for both KSK and ZSK
    Assuming: 2-3 threshold
    Assuming: RSA KEYS ZSK: 768 bits  KSK: 1536 and all keys sign DNSKEY set
    Timers Proposal has 2 KSK and 2 ZSK:
          DNSKEY RRset is 1365 bytes on the wire (assuming name compression)
    Threshold Proposal: has 3 KSK and 2 ZSK
          DNSKEY RRset is 1788 bytes.

    There was some discussion on the minimum number of each type of key and one person voiced some concerns that n-of-m mechanism DNSKEY set was worrying large. There was also a comment that ECC keys are much smaller for same strength so that might be part of the solution.

    Miek Gieben: Back to the proposals. I don't like the revoke bit, if you leave it out of that proposal, then the m out of n stuff seems an implementation of the other proposal without the revoke bit.

    Mike StJohns: No, the revoke bit helps you maintain coherence. The other proposal has a lot of ways to make mistakes operationally. There's a lot of interesting problems with respect to how you do the stuff.

    Miek: From what I understand now, you can even combine the two into one thing. Do them both at the same time.

    Mike: Well it seems that the minimum number of keys is 2, and it can't actually be lower without losing the compromise protection.

    Sam Weiler: I like the idea of having a revocation mechanism, but I'm a little bit worried about this one. If a resolver that does not know about the revoke bit gets a key that has that bit set, can it still use that key for validation? If so, we may want to look at a different signalling mechanism, and I would suggest that the working group is about to last call a draft written by mister Blacka, which suggests one, which could also be signalling which mechanism is in use.

    Mike: There is specific language in the document about how the revoke bit does not make it any worse than without it.

    Sam: I think it might be, because with the revoke bit, you might keep a key published for longer that you otherwise might.

    Olaf: Changing the revoke bit changes the key, as soon as you swap it you change the key, and the validator does not recognize it as the same key any more.

    Johan Ihren: First, about packet size. The assumption was that with 4K packet size, we would be safe. With 2K i do not know. We need to look at that further. As regards to the ability to get rid of all trust anchors by mistake, however, DNS is a lot of rope, if people want to shoot themselves in the foot, they can easily do that already, without DNSSEC. DNSSEC just gives them more rope. So in my opinion, the real task here is to find a mechanism that makes it viable to deploy it large-scale, so that it'll actually work on the full Internet. That we'll need software development to make that work without mistakes is kind of clear. If someone chooses to go around software tools that cater towards avoiding mistakes, and makes changes manually, than that person will be in for a bumpy ride regardless.

    Olaf: On 4K and 2K limits. (shows screen with statistics about packets on reverse zones). You essentially only see 2048 and 4096 advertised as the size clients can handle. 2048 is a significant proportion of that, and so we have to consider it as something the DNSKEY and signatures have to fit in.

    Rob Austein: We once looked at a proposal that had revocation, and we dropped it because it was too difficult to make it work. The people that got the revocation signal were the people that did not need it. Here, with key id's changing because of the revocation bit, i think we might be okay. Given that, revocation seems at least somewhat useful to me, I don't think it really changes the PKI-ness of DNSSEC. Last comment: I don't really have a strong feeling yet, but i'm leaning more towards the proposal of Mike at the moment.

    Olaf: Let's have a show of hands.

    * Who wouldn't mind if we go in the direction of the StJohns document, with revocation, which means resolver updates?
    Couple of hands.

    * Who wouldn't mind if we go in the other direction?
    Again, couple of hands.

    * Does anyone have a strong preference for either one?
    Not really.

    Olaf: I think we need to do this on the list. Jim Cassel, you have an action point. I think we need to decide on this before next meeting in Vancouver.

    Olafur: Minor point. both documents are expired now. We can either ask the authors to submit a new version or I can ask the area director to have them revived in current state.

    Mike StJohns: We can't just resubmit it because the boiler plate keeps changing underneath us. If you can get it revived, please do. If not, please let us know and I'm marginally willing to do it. Johan Ihren:I'll submit a new version.


    Rob Austein reports about a proposal that is not yet a working group item: the NSID proposal. This came out of the work in the dnsop working group, where Rob is co-chair, so he can't author there. There are repeated requests for a standard way to identify the server that gave an answer. Especially in anycast settings where different queries can be answered by different servers this could be very helpful for debugging. The current ad-hoc way uses a separate query in the CHAOS class, and there were effort to make a standard out of this. But those efforts got stuck, and that's were it's been at for a couple of years. Last year we revived that draft, changing the recommendation so that it is no longer an extension of the CHAOS class TXT record hack, and basically the draft was a problem statement, and a description of the existing mechanisms that have already been deployed. That called for a solution, maybe at another group, possibly a protocol extension, that would solve the problem. That's what this draft is supposed to be.

    It's a very simple mechanism, it's in EDNS, because that's the only place we can put extensions in anymore. There's a flag bit in which you can state in a query: "oh by the way, could you please identify yourself, server", and there's an EDNS option field in which the server can reply, stating what it's identity is. Identity is very carefully left undefined, that's one of the changes since last round.

    The two open issues from when I presented this last year are: * What should the payload of the response be?

    It could be the real name, or the real address. There are security issues. So i asked around about this and the feedback i got was, can we please just make it an arbitrary string. So it's basically becomes a cookie that the server operator can use for debugging.

    The main point of using a protocol extension instead of a separate query is that quick routing changes might change the server your second query goes to. You have to be able to add it in the packet.

    * Whether or not recursive nameservers can play too.

    The original request only had to do with authoritative nameservers, but there's no real reason not to do this with recursive nameservers and we know that there are anycast setups with recursive nameservers too. The mechanism is quite explicitly defined as not being transitive. So the bit means 'server I sent this packet to, please identify yourself", so it applies equally well to recursive nameservers. The question is: should it? My personal opinion is that it should, no one argued with me, I did not get a lot of feedback on this one, so I left it like that for the moment.

    The requirements document is in last call at dnsop, but it got hung up there, long story. So the question is do we want to make a working group item of this, and do we want to wait for the requirements, assuming they ever appear.

    During discussion there was strong preference shown for getting this document done soon. People like this mechanism, and in particular the fact the string is just an simple identifier that can be set to any value. There was a question about support for recursive queries of NSID, but that issue is not addressed and will not be addressed until after this is done.
    Document was adopted as WG item and milestone to be added that the WG process to document before next meeting.

    DNS IANA Considerations

    Donald Eastlake presents some drafts about cryptographic algorithms.

    First something about draft-ietf-dnsext-ecc-key-07:
    There have been some questions in the past about patents, but as far as is known, these only cover specific implementations, not on the basic theory or scheme of it, perhaps on specific equations. Algorithm number 4 has always been reserved for ECC, and this draft proposes a specific format for ECC keys and signatures in the DNS. People need to read it and comment on it.

    Olafur: The chairs would like this to hit last call soon, and it would be great if someone can implement it, and can comment on how useful it is. We have been getting statements from cryptographers that ECC's are really good, and that signature and key sizes are significantly smaller than RSA. So it is a very interesting addition, so any technical feedback would be great.

    Back to IANA considerations: draft-eastlake-dnsext-2929bis-01.

    Donald Eastlake reports that rfc2929 was the first IANA considerations document for RR types, classes, rcodes, opcodes, header bits, et cetera. It provided some private numbers, depending on how numerous the particular item was, some publication required, and a few higher level IETF consensus or standards actions. What people are mostly interested in was RR types. It defines thing for the other numbers too, but people are mostly worried about the ease or difficulty of getting new RR types.

    Publication required was supposed to be pretty easy, but it appears that no RR type has ever been allocated based on the provision of publicly available publication. There was a discussion on the list, and there is a mechanism in rfc4020, called "Early Allocation". If something is going to be a standards track parameter, and there's working group consensus, and some other things, then you can get a temporary early allocation of an IANA parameter value. It's supposed to last a year, and then you have to request renewal, if it hasn't progressed to the point where it's in a standards track draft. The discussion on the left was that it was still too strict. For instance there were things that were heading for experimental, there were competing proposals. The early allocation seems to only apply on single proposals that are known to become standard, were early allocation is only there to make things more convenient, but people wanted something more loose than that.

    So this draft tries to do things easier, and wrote 2929bis. The main effect is to try to make things more liberal. In many cases it replaces what used to say "IETF consensus" with "DNS special allocation policy", and there's a part in the document which defines what this allocation policy is.

    There are also some other little things in the document, some things about AFSDB, a specification required subset of values for RCODE, and other minor changes, some updates to rfc references.

    The "DNS special allocation policy" is like rfc4020, but with looser requirements. What it currently says is one of:
    * Standards action
    * Approval of something as experimental
    * Temporary allocation like in rfc4020, but with looser criteria, you need a draft that describes it, and approval by a working group chair and area director, or by two area directors if it's an individual draft.

    One of the discussion was about the perpetually of the working groups and mailing lists. This draft did assume that the namedroppers mailing list will be perpetual, and it defines a template to request a number. The template is not yet fully defined, this still needs some discussion, but it's similar to registering new mime types.

    Thomas Narten: What problem are we trying to fix here? People overload the TXT record for a lot of reasons, and only one of them is IETF consensus for getting an RR type.

    Donald Eastlake: I believe that 100 percent, but this is aimed only at that one problem.

    Rob Austein: But you're changing RCODE allocation too.

    Donald: Well if you're making changes anyway, I thought i might include that too, since there were just plain oversights in rfc2929 i think. But then again, if the working group think that this should just be about RR types, then I'll only talk about RR types.

    Thomas Narten: rfc4020 is really not appropriate for this kind of thing. it was meant for the routing group where they wanted to get code points assigned while they were still drafts before they popped out of the working group. In the case of resource records, a good number of the proposed RR types don't come to the dns extensions working group, because they have nothing to do with dns extensions charter. They're really for some application that wants to use the DNS. My belief is that the role of this working group, with regard to reviewing proposed RR types, is to basically make sure that the definition is specified enough, that is does not cause the DNS system to crash if the size is too big, or cause operational problems and so forth, but not so much about the semantics of what's inside the type.

    Olaf Kolkman: That's actually the direction this working group is taking. We try to look at the DNS merits of the whole thing and don't make any statements about what the protocol is actually doing. People just need a code point to get stuff on the wire to do experiments, so they can go on.

    Thomas Marten: Okay. Something else: given that the RR types we have 16 bits, why are we worried about reclaiming unused allocations? Then why are they temporary? Why are we bothering?

    Donald: Well I got that from the list, people were saying 'why can't people just get these temporarily?'.

    Margaret Wasserman: I don't know that they have to be temporarily allocated, but if you're going allocate code points based only on ID's you're going to have operational problems if those ID's are going to cease to exist or change fundamentally, and someone sees a code in their configuration file and there's no reasonable pointer for them to figure out what they are supposed to mean.

    Olaf: I think that was the point of making them temporary.

    Margaret: But taking them expire from IANA does not remove them from the configuration file. I'm not really sure that making them temporary would solve he potential problems.

    Donald: Of course, if I was IANA, what i would actually do, is mark them as 'temporary' and later change that to 'temporary, expired' and I would actually roll through them and wouldn't reallocate them until the entire space of temporary allocations has wrapped around.

    Margaret: I strongly disfavor creating new processes for new situations, and would like to see us trying to fit this into existing standard policy. Then IANA will know what to do and will not come to me anytime anyone wants to allocate a DNS code point. If you keep the process the same you can train someone to do it. Expert review means that we can assign someone else, other than me, who they can go to every time and that person can go through whatever process we write down that they can go through, but it makes the interface with IANA along with our standards service model, and allows us to do whatever we want underneath that. I think that was more or less what Thomas was suggesting, and I think that's sort of a superior process architecture.

    Olaf: Yes, but it seems that the community is suffering from this.

    Margaret: Why would an expert review where Olafur was in charge of running this process be any slower than having me run this process? Olafur probably cares more, or has more time to care about whether or not the community is suffering than I do.

    Donald Eastlake: Even if you had expert review, it's quite likely you want to use this template to gather information. What this currently is, is a distributed expert review, where every working group chair and area director has some small chance of being the expert. And if that's the bottom point, you can eliminate it. We can eliminate the temporariness, and replace the approval part with that of an assigned expert.

    Rob Austein: Couple of points. I'm not on any side, sometimes I'm for, sometimes against. But I don't think the process is fundamentally broken. I think people are not getting new RR types is not because of the process, it's because they're not asking. Specific points, assuming that this proposal goes forward instead of us saying 'let's just not': Two weeks is too short. People can be on holiday for longer than that and something that went from first proposal to completion within that time is just wrong. Thirdly, rcodes I see as different as this, if you don't know a certain RR type, you should not ask for it. But an RCODE is something you get back. What are you supposed to do if you see an error that you have never seen before? I'm not sure if we should loosen up on rcodes.

    Thomas Narten: I agree, adding an error code is changing the protocol. It's about semantics, not about bits. (Back to review part) Looking at what you got there, if you replace that last part with 'expert review' then you've plugged it into something that is understood in IETF processing, and it gets you to where you want to go. The purpose of the expert is that sometimes he has to say 'I'm in charge and I have to tell IANA yes or no'. But the expert still has to follow some procedure that it is adequately described in some draft, and reviewed on namedroppers for some time, taking into account that time is longer around Christmas, etc cetera. I'm actually personally not opposed to loosening allocation of new RR types, but I also don't think it's fundamentally broken. The bigger issue is I think how to get a new RR type deployed, as opposed to getting the code point for it.

    Margaret: There's been some words about how the community is suffering, and currently there is a specification required provision. And personally I can't see how this proposal is any easier or faster than specification required.

    Olaf: This draft did not come out of the blue. It came from a long discussion on the mailing list. There is a bunch of unhappy people out there, and the reason Donald picked this up, I think, is to make sure that we get a process and we get around the bureaucracy that make people frustrated with the IETF. There's a couple of things that make is difficult. One of the things I see is that when people come to this group for review, and they post on the list and ask for review, you hardly see people picking up that work and doing something. That will not be changed by this procedure. I think we should address that in this working group. We have a responsibility in this working group to do that expert review. If some people do that then we're set for this. And the review essentially takes looking at the DNS part, and any bugs can easily be fixed. It is not a lot of work. This settles with the fact that you have to wait for the bureaucracy to actually get the number. We all want the best here, but there is definitely some responsibility for the DNS experts to take turns and do the review. And then if we can make the process issue easier and get those type codes assigned relatively soon to the people who want to use them and do not want to collide.

    Sam Weiler: Maybe we should approach this from a different direction, and provide a faster permanent publication scheme, like a permanently archived template, so they can walk in saying 'Here's my template, it's permanent. Now give me my type code."

    Peter Koch: We have heard arguments of people adding things to the DNS that they can't change the definition of their type codes because of an alleged deployed base. So my question is, how stable does this permanently archived template have to be. And part of the frustration might be comments about what happens to the DNS. The other one is sneaking a definition in, and changing it afterwards. What is the idea about stability in that case?

    Donald: If people are going to get something allocated and then use it for something other than was originally specified, I don't know if there's anything we can do about that.

    Donald: Obviously I'm going revive the draft based on the feedback.
    Currently the changes I plan to make are:
    - RCODE is always IETF consensus
    - go to expert review
    - make template archive permanent
    - make allocation permanent
    So the question remains what is going into the template? Obviously RCODE will be removed, and RR class and RR type have a set of questions, like 'why can't you use an existing one?'. Would these questions be adequate, or do we want something else?

    Thomas Narten: I have a more basic question. How many CLASS types have we assigned in the last ten years? Zero. So why do we need a special accelerated procedure to handle them?

    Donald: Because it seemed more elegant.

    Olafur: I would say that class is out of scope.

    Rob Austein: There are enough layer 9 and above issues with new classes. I'm not sure we want to go into this.

    Interoperabilty testing report

    Olafur reports that there is not really much to report. One effort is underway. Mohsen Souissi reports that they have already started a testing plan at AFNIC. They have realized that the RFC is ambiguous sometimes in rfc2119 department (the MUST/SHOULD wording). Also there is some ambiguity whether the test is really conformance or interoperabilty, so they have to dig into that some more. They have sent the plan to Olafur, and the working group should expect a message from Mohsen with a request for software to be used in the interoperabilty tests.

    Jaap Akkerhuis: I did some interoperabilty testing for rfc1982 (Serial Number Arithmetic). I have not had time to write it up yet, it will be done next month.

    Drafts from other WG's requesting review

    None at the moment. Those that were there have been helped.

    Tahi DNS test tool

    Nobumichi Ozoe reports that they have started to develop an application layer protocol test for DNS. Information can be found at http://www.tahi.org/dns

    The test targets clients and servers, and will initially test for conformance to:
    rfc1034, rfc1035, rfc1123, rfc1995, rfc2131, rfc2308, and rfc3425
    Later it will be extended by:
    rfc671, rfc2781, rfc3596, rfc3401-rfc3405, and rfc4033-rfc4035

    A beta version will be available in October 2005, please comment to improve the test tool.

    There is a mailing list: dnstest@tahi.org

    Mohsen Souissi: It seems to be very useful for draft standard RFC's, but is it worth it to make this for proposed standards? Is there any collision between compliance tests and interoperability tests?

    Olafur: I don't think there is a risk in having too many tests. I would really encourage people to help out in any way. I am thinking of interop tests that will become compliance tests. Version 0.something is definitely a rough test, but I think this is a very important development.

    Rip Loomis: There's a will and a can and an it. As far as I can see now on the website there is no download yet, and an empty mailing archive. Can you send a message to namedroppers when there is more there to review?

    The room tells Nobumichi Ozoe to say yes.

    Other things

    Olaf notices that there are a lot of long discussion on namedroppers, that go nowhere. Good intentions, but no actions. For instance the wildcard discussion. That does not go anywhere unless people write drafts. Please write a draft, so we have a way forward.

    Rob Austein: one thing, this problem is not specific to our working group. I have a script that counts messages from identifiable addresses and summarizes it onlist. It is entirely up to the chairs and the working group whether or not I ever do anything like this for namedroppers, but the offer is there. Meanwhile, I would strongly urge to anybody who does post to the list: If you need to post more than 2 messages a day, unless you're answering specific questions asked to you, you're probably posting too often.

    Both Olafur and Olaf will be on vacation. Ed Lewis will be moderator of the list while they're gone.

    End of meeting


    Next steps in Trust Anchor Management for DNSSEC
    2929bis etc.
    draft- ietf-dnsext-nsec3-02