NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 08-Oct-99
Olafur 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>
To Subscribe: email@example.com
Description of Working Group:
The DNS Incremental Transfer, Notification, and Dynamic Update Working Group is concerned with three areas of future DNS protocol development:
1. Incremental Zone Transfer - As the sizes of some zone files have grown quite large, it is believed that a protocol addition to allow the transfer of only the changed subset of a zone will reduce net traffic and the load on critical servers.
2. Change Notification - There can be large time intervals during which at least one secondary has data that is inconsistent with the primary. The proposed ``notify'' mechanism (where the primary sends a message to known secondaries) facilitates fast convergence of servers vis-a-vis consistency of data in the zones.
3. Dynamic Update - The need to frequently update small portions of a large zone and to have those updates propagate is perceived.
Goals and Milestones:
Consolidated review of draft-ietf-dns-ixfr-01.txt.
Submit Incremental Transfer and Notify Internet-Drafts.
Submit revised Incremental Transfer and Notify Internet-Drafts.
Submit Dynamic Update, Incremental Transfer, and Notify Internet-Drafts to the IESG for consideration as Proposed Standards.
Request For Comments:
Incremental Zone Transfer in DNS
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Serial Number Arithmetic
Dynamic Updates in the Domain Name System (DNS UPDATE)
Clarifications to the DNS Specification
Selection and Operation of Secondary DNS Servers
Negative Caching of DNS Queries (DNS NCACHE)
Classless IN-ADDR.ARPA delegation
Reserved Top Level DNS Names
Non-Terminal DNS Name Redirection
Extension mechanisms for DNS (EDNS0)
Binary Labels in the Domain Name System
46'th IETF DNSIND Working group minutes
The meeting started with agenda bashing and the appointment of Robert Watson notetaker.
The working group chairs went over the new proposed charter and the working group goals. The main thrust of the working group will be to promote existing RFC's or ID's soon to be RFC's along the standards process, not to admit new work items. The exception to this rule is the inclusions on new short ID's that attempt to clarify or specify better existing RFC's.
Olafur gave a long presentation on the status of all 20+ RFC that come under the working group and what the status of each one is. He also discussed the impact of the major changes that are currently sitting at proposed standards level are going to have on DNS and the interesting relationships these changes have among them selfs. These big changes should be absorbed before any new ones are admitted. The biggest challenges are
- DNSSEC: KEY, SIG, NXT, TSIG, TKEY records and operational
- IPv6: AAAA, A6, binary labels, and DNAME
- Dynamic update: Update, Notify and IXFR
The smaller ones are
- Negative caching:
- Secure update:
There is a need to perform many complicated tests to assess if vendors are implementing these extensions correctly. To clear out ID's the working group chairs will be having at least 2-3 WG last calls each month. The working group chair threatened to take editing away from authors that are not responsive enough.
DNS RFC status as of 1999/11/05:
- Full Standard: (2)
- 1034 1035
- Draft standard (0)
- Proposed (19)
- 1611 1612 1886 1982 1995 1996 2136 2137 2163 2181 2308 2535 2536 2537 2538 2539 2671 2672 2673
- 2052 2540 1183 1712 1876 2168
- 1706 1794 2230
High Priority Work items:
RFC 2136 Dynamic Update: needs clarifications based on implementation experience and testing. Depending on extent of changes this may have to be recycled at proposed standard.
RFC 2137 Secure Dynamic Update: No implementations. There is an alternate proposal on the table we need to pick. RFC 2136 will not advance without some security framework. The consensus of the meeting is to obsolete and go with the alternate proposal "Simple Secure Update".
RFC1995 IXFR, due to under specification implementors are having a hard time writing interoperable versions. Some clarifications have been suggested. They are being considered. Depending on the extent of the changes this may have to be recycled at proposed, but may advance to draft. There is an alternate proposal on the table that will be discussed later in meeting.
RFC1996 NOTIFY, minor changes needed to text advance to DRAFT standard.
RFC2052 SRV, replacement document awaiting IESG approval.
RFC2335 Negative caching, minor updates needed related to NXT advance to DRAFT if implementation experience allows.
RFC 2535 DNSSEC has number of rough edges that need to be addressed, these generally fall into following categories, protocol simplifications, protocol clarifications, operational difficulties and operational clarifications. He proposed that to address these a number of small update document be written to update RFC2535 each would be put on fast track to become proposed standard. In a year or so after things become clearer a major rewrite of RFC2535 replacement would start that combines all changes.
- IPv6 related:
- RFC 2672 DNAME, needs implementations and testing.
- RFC 2673 Binary labels, needs implementations and testing.
- RFC 1886bis A6, (officially an IPNGWG document), needs implementations and testing.
- RFC2537+RFC2536 DSA and RSA KEY records and Signatures. These need interoperabilty testing. Can these documents advance independent of RFC2535?
- RFC2538 CERT record, needs implementation and testing.
- RFC2539 Diffie Hellman KEY record, needs implementations and testing.
- RFC 1982 Serial Number arithmetic, how can this be tested ?
- RFC 2181 Clarify, testing is needed, question is can this be tested without testing the whole of DNS specifications ?
- RFC 1611 1612 MIB's for DNS. One implementation in existence, negative feedback from that implementation. RFC author (Rob) agrees to write a document that officially retires these documents to Historic status.
Summary of Working group Last calls since last meeting:
TSIG passed last call waiting for IESG consideration.
Kitchen Sink: Negative comments, end run round registering new types we have a large type space, do not worry about type space rejected for publication. There was some discussion if this was the right thing to do. The working group meeting attendees agreed with working group chair not to advance the document.
Local Compression: Negative comments, minimal space savings for significant implementation overhead. Do not publish this.
APL (address prefix lists) no opposition, minor fixes and advance document to IESG as a standards track document.
Next WG-char officially retiring number of ID's:SEC RR: bad idea rejected on mailing list, KEY referral: Predecessor to SEC RR obsoleted by SEC RR. Indirect KEY: not needed at this point wait until there are applications requesting this functionality. DDDD (deferred dynamic Delete) Working group decided to postpone this work as there is no agreements if this is needed. Rollover: Draft sent to DNSOPS working group as there is similar work discussed there.
William King discussed the interoperabilty testing that was to take place later that evening. 7 implementations expected.
Peter Koch: (draft-ietf-dnsind-apl-rr-03.txt) list of IP address prefixes, framework for application scenarios
- every address/prefix tagged with address family as maintained by IANA
- defined AFDPART for IPv4(1) and IPv6(2)
- had last call received comments on draft
- example is fictious and not intended to be exact example of use
- separate documents with real examples to come
Very recent Changes, Added AF indicator in textual representation in zone file format, added applicability statement, make clear no particular usage implied by draft, rather framework and editorial changes.
Levon Esibov "A DNS RR for the specifying the location of the services (DNSSRV)"
1. what was done
- since the last ietf meeting incorporated the chances to the draft since the IESG requirements moved to the ps
2. current stand:
- everyone agrees that this draft needs to go forward
- consensus on use of "should not" for the use of SRV record by applications
3. call for actions:
- per Thomas Narten suggestion, move the should not paragraph to the introduction
Matt Crawford: "DNS A6 record"
- recent changes
- no "A" or"AAAA additional section processing
- a6 additional info takes priority over NS
- priorities for additional info in NS,MX,RT (etc) replaces:
- A > A6 > AAAA
- mention that failure of some a6 queries may result in an incomplete (not non-empty_ set of IPv6 addresses
- client-side guidance for order of querying. default is a6, then AAAA
- vg/v4 precedence rules: yield to 1933
To Do: fix one editorial nit and typo
Donald Eastlake: "TSIG and SIG(0)"
- wrote TKEY needed a better way to key TSIG
- simplified quite a bit
- GSS API mode has been implemented by Microsoft
- has sent email to Steve (at Microsoft) to verify hasn't been changed since their implementation
- draft will be updated to specify more about DH key generation to guarantee correct keys
- changes to one key for a name, previously more keys
- another way of putting signature on a request/response to secure transaction
- intended for non-symmetric cases
- setting up symmetric keys using sig(0), to use TKEY/TSIG
- various changes based on implementation experience
- sig(0) was in RFC2535, which is replaced by this draft
WG-chair: there will be last call on both documents in near future
TALK: Brian Wellington: "Simple secure update draft"
- no revision for this ietf, not much has changed
- only identity of sender needs to be changed
- currently binds to a name, not useful if TKEY as name not useful
- should be changed to reflect what happens with TKEY
- only other possible change
- mentions signatory field as unsigned integer ("key strength")
- Brian will open discussion on namedroppers next week to see where it goes
TALK: Ed Lewis "When is a zone secure?"
- having multiple cryptographic algorithms has some downside
- DNSsec workshops
- nice-se in may 19999
- CAIRN in September 1999
- test situation
- software: bind 8.2.x with DSA and RSA algorithms
- parent uses both algorithms and child uses just one algorithm
RFC 2535 text at issue
- 2.3.4 special considerations at delegation points
- but, in the case of...
- 3.4 determination of zone secure/insecure status the secured verses unsecured status of ...
- what happens when, say, the parents signs in RSA and the child signs in DSA does parent add a null RSA key?
- does parent hold the key set because there is a null
- what does the child do with RSA sig(key) if RSA is unsupported
- why is a zone secure "by algorithm"?
- experimental key status what is the benefit of "experimental" algorithms?
- signatures may appear with data that do not correspond to published keys
- why not keep a signature optional by not issue key for .. more here
- by defining a zone to be secure by algorithm .. more here
- more here
Impact of Problem:
- suppose the only keys in a particular secured zone belong to an algorithm unsupported by a globally remote resolver. further suppose this causes the resolver to conclude the zone is unsecured as a result, bad things happen
- rhetorically asked: who is hurt more? who deserves the blame?
- zone for not using a mandatory to implement algorithm
- resolver for ignoring "warnings"
- which it couldn't understand anyway
- A zone is either secured or unsecured
- without regard to algorithm
- considered secured only if a mandatory to use algorithm signs each set
- the KEY bit in the upper NXT field is set if and only if the parent has signed keys for the child.
- the parent no longer even holds a NULL key.
- secured/unsecured is yes/no so just one bit is needed
- this puts more weight behind NXT, redefines the meaning of its bit
- see next slide
- drop experimental keys
- generalizing resolvers to understand this status is unwieldy
discussion on NXT bit proposal
- a delegator has an unsigned NS set, a signed NXT, and perhaps a signed null key (set)
- want to eliminate the null key set
- signed/unsigned could be just as a 1 bit piece of data
- use the key bit in the next types present bitmap
- difficulty in getting parent's NXT set
- may need meta-query
- signer needs to know to turn the bit on
- online certification and off-line signer complicates life
third downside: unhappiness with NXT in general, not on slide
- simplify the DNSsec data protection function
- plurality of algorithms and states of keys is not beneficial
- specify that only mandatory to implement algorithms are acceptable for DNSsec verification
- specify that a zone must be signed in one of the mandatory to implement algorithms for interoperabilty
- alternatives is to be non-conformant or unsecured
- separate the data protection functions from other features
- key publication, immaterial signatures
Where this is heading
- this proposal or something resembling it will become a draft as a clarification/update to RFC 2535
- as more issues are raised in deployment, more short and focused documents will be generated
- the collection of documents will be used as input to the next round of standardized DNSsec
TALK: Rob Austein: "sigalgop"
- it's really short, no need to present on topic of sigalgop
- problem: using UDP for transport, and will for foreseeable future
- UDP currently best
- UDP packet length problem
- packet truncation problem
- signatures can be pretty big, some bump it off the end
- if seven sig algorithms in use, couldn't server send back the one for the algorithm the client likes?
- sigalgop to request the algorithm
- straw proposal
- one of the problems is that it is about breaking rrsets
- oops, should not have used key types / subtypes, ... more here ...
Donald: originally was suggested using a bit from the rrtype field to use for the signature. didn't do that, might have been an idea.
TALK: Donald: "dns-iana and local names"
- wants reaction on dns-iana
- formalize guidance to iana as to decision criteria for numbers for various parameter spaces for various IETF algorithms
- several sections:
- error numbers, query rr types, opcodes, so forth
- please look to see if criteria OK (standard parts, liberal, etc)
- traditional states don't be too type if room
- section for allocation names
- for just type names, et al,
- reserved names -- BCP 32 already called top level reserved names will be removed, possibly a new RFC in BCP 32, with other material (controversial part)
WG concencus was to drop all mention of domain names and then do a Last call on the document.
Next there was extended discussion on why DCHP people want DDDD and why it is a BAD idea, discussion was halted and moved to the end of the working group meeting.
Next section was presentation of ID's that are requesting to become official WG drafts:
TALK: Kevin Dunlap: Dynamic Update Zone Transfer -DUXFR
- why stir up the hornets nest?
- He's an implementor and ran into problem --
- want IXFR-like and address problems with IXFR
What is DUXFR?
- draft draft-dunlap-dns-duxfr-0.txt
- defines AXFR query type using the dns updates format defined in RFC 2136
- Zone changes are transmitted using dns update formatted packets
- Ability to express deletes of all RRs for a given name
- with IXFR each RR type needs to be deleted individually for a name
- DUXFR does in a single request
- Bracket request - request a range of changes (serial 4 thru 8)
- allows a closer tie with notify
Extended discussion followed, summary of which was IXFR needs to be specifed better, there is no need for DUXFR
TALK: Donald: new key type ECC draft-schroeppel-dnsind-ecc-00.txt
- Thought elliptic curve signatures might be good due to compactness
- Key and Sig format for elliptic keys
- There is use in KEY format if not sig--same as DH to store, but no sig format.
- Depends how multi-algorithm thing comes out--2 and 3 not much different, 2 and 20 big, but 1 or 3 relevant.
- Technical content done by Richard Schroeppel
Olafur: Not accepted as working group document because document specifies used of ECC for signatures, so until we resolve the multi-algorithm problem we will not add more algorithms that can sign data. Does the working group concur? HUM
TALK: Donald: local names
- draft in two parts, needs to be reorganized
- recommendation BCP on how to name things which you intend to have only locally accessible -- i.e., within enclave to minimize possibility if (when) they leak out (i.e., email headers, etc)
- by adding one entry to root + other stuff, have it so that vanilla resolvers out of box can still resolve local names within the enclave.
- needs to be revised to make separation clearer, or even two drafts
Some discussion about the difficulty in getting this document though the IESG, due to controversial issues with name assignment suggestions where made to break document into two documents or zero documents.
TALK: Padmaja Rao " A convenient scheme to distribute verified public keys using secure DNS"
- want to distribute external keys for other secure key distribution services
- convergence of existing PKIs seems unlikely to happen
- need to simplify client software understanding of retrieval and format of each PKI certificate
- injecting verified public keys into the secure dns infrastructure
- support this scheme by providing the following information
- original certificate type
- issuer of certificate
Indirect Key Resource Record
- Modifications courtesy Donald
- Not for use by DNSsec, instead just storage
Extended Key Resource Record
- special algorithm number in original, DNSsec knows not to use
- originally - pointer to key elsewhere, also w/hash securing key retrieve,
- also now a version with a key
Olafur: What was presented here is significantly different than what is in the latest draft document -- resubmit revised document, and determination made based on that.
- A lot of people want to store information on network and retrieve it
- lots of people want to develop new mechanisms
- lots in dns
- this is (often) a bad thing
- was asked to write down what we think are properties of information storage systems for the network
- can ask question of information storage system: one question, some answers, or one question: one answer. Different.
- This would help in saying things such as "The DNS is NOT a directory" and be able to explain what we mean by that.
- Slept on this for two months, woke up in the middle of the night and wrote it in two hours.
- Two reactions
- One "I like this"
- Two: deafening silence
- mailing list -- firstname.lastname@example.org -- supposedly the discussion forum.
Rob Austein: Tagged non-US-ASCII character sets in DNS labels
- BOF tomorrow entitled "putting international character sets in DNS"
- Question about
- should it be in DNS?
- Latter category out of scope
- Not clear we should do non-US-ASCII DNS at all but...
- If we do, let's learn from the MIME folks
- There's no consensus on character sets
- some say UNICODE
- some prefer iso-8849-*, jis*
- problem scheduled to be solved imm,,
- In MIME -- tag it
Something untypable on my keyboard
- Use EDNS0 extended labels
- octet 0 - code indicating "labeled charset label"
- octet 1 - total label length
- octet 2-4: iana charset registry
- no new iana registry required
- octet 6-n label
- Problem: mapping glyphs to codes
- in what order does resolver try multiple charsets
- what about characters that look the same, etc.
This comes down to: "adds so many more ways you can screw yourself"
Least bad solution: put character set data into DNS
- partial solution: new rr type specifying order
- call this the "csny" rr type for now
- character set normalization
- type code and real name TBD
- does not address intra-charset normalization, e.g. within UNICODE
- For backwards compatibility keep us-ascii at front of list
- additional section processing / glue rr problem here
- how much does this slow down queries
Maybe this is just a bad idea
- perhaps this stuff just doesn't belong in DNS
- come to the IDNS BOF if you want to discuss this
Lots of good discussion about if this is a good way to do things. Recommendation that people attend the IDNS BOF the day after.
Harold: Just a couple of technical comments -- mechanism for identifying a limited set of characters -- so that even if you use unicode you can say "I only care about..." -- normalization issue is unsolved and possibly unsolved.
Rob: Many believe that unicode is not the answer.
Harold: people who got the short end of the stick in unicode may never agree with unicode. However, it is the game in town.
Randy: How much of an
a) protocol and
b) operational change would this imply? If we assume we do, how much change do we assume.
Rob: Certainly changes in the protocol -- uses EDNS which is currently only used for binary labels, which isn't deployed. Also requires upgrades of all clients. If the concern is immediacy, there are faster ways to do it -- incredibly slow. Topic for tomorrow's BOF: least of our concern is upgrading DNS.
Randy: But in fact, this is not an operational change in that I don't have to deploy different sets of servers, and don't have to change beyond that which is currently standardized? EDNS0 covers it?
Bob: Not just do you support EDNS0, but also definitions: what is DNSsec sort order, and what about canonicalization -- very important to know this because of ordered sequence in DNSsec. Agree that apps upgrade is bind problem, but that happens no matter what. Also interoperabilty issues with existing name servers.
Rob: Not saying we don't need to add international character sets -- the issue is does it belong in DNS?
James Sang: IDNS chair -- working on IDNS for two years. Whether representation in client or in server? Server is not really an option. MIME is a data representation, not for processing. Tagging and coding is a good idea for some languages, but when goes down to localized languages (such as in India) -- tagging not possible. Tomorrow.