NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97
Chair(s):
Randy Bush <randy@psg.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Jeffrey Burgan <burgan@home.net>
Mailing Lists:
General Discussion:namedroppers@internic.net
To Subscribe: namedroppers-request@internic.net
Archive: ftp://rs.internic.net/archives/namedroppers
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:
Done |
|
Consolidated review of draft-ietf-dns-ixfr-01.txt. |
Done |
|
Submit Incremental Transfer and Notify Internet-Drafts. |
Done |
|
Submit revised Incremental Transfer and Notify Internet-Drafts. |
Apr 96 |
|
Submit Dynamic Update, Incremental Transfer, and Notify Internet-Drafts to the IESG for consideration as Proposed Standards. |
Internet-Drafts:
· Classless IN-ADDR.ARPA delegation
· Secret Key Transaction Signatures for DNS (TSIG)
· The Kitchen Sink Resource Record
· Negative Caching of DNS Queries (DNS NCACHE)
· Test and Example Top Level Domain Names
· Local DNS Names
· Larger Domain Name System UDP Replies
Request For Comments:
RFC |
Status |
Title |
RFC1995 |
PS |
Incremental Zone Transfer in DNS |
RFC1996 |
PS |
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) |
RFC1982 |
PS |
Serial Number Arithmetic |
RFC2136 |
PS |
Dynamic Updates in the Domain Name System (DNS UPDATE) |
RFC2181 |
PS |
Clarifications to the DNS Specification |
RFC2182 |
Selection and Operation of Secondary DNS Servers |
Minutes of the DNS IXFR, Notification, and Dynamic Update (dnsind) WG
Reworking agenda - Randy's laptop does not work so went off old one kre remembered corrections. Kitchen sink not being discussed here.
Purpose of group is to push things PS->DS
Map
All set to go with testing of insecure, but problems with mailing list. If you think you are on the list, send map email. Three implementations of dynamic update/notify.
· notify - are 2 parts
· same with update
May have one example of each; probably have two of all of them. Need independant implementation of each end. Need to demo each proto is interopable with two implementations of each proto. Do not need to demo that update is interoperable with notify.
Dynamic update is kinda useless without notify, so testing dynamic will also test notify. Let them know if email is not received by Friday.
Secure dynamic update - one impl in progress - tis is one other also - Rob Stevens, competitive automation.
Need to give justification of why you want to subscribe to list or will ignore.
ohta
Have mailing list with 10 people
2.5 implementations
martic chapple (??) - seems to be working
prati opta (??) - not yet public, doing private testing now, maybe this month
josh, doing ixfer, not done yet
hope tests to begin this month
Do each of the four drafts have test plans? Which? One does - map. Please share the test plans publicly
What is dns testing event in sj?
Vixie: imc is doing an event on jan 27 in bay area
Don't know why they are doing this but Vixie will be there with several versions of bind, also microsoft will be there.
Someone from usoft: goal is to test on a wide scale.
· test dynamic update, and dhcp/dns interaction
· hopes that there are multiple implementations
Test plan? Not yet; hope to be one. Report? Hope so. Please do it formally so that results can be public and usable.
· results will not be public
· thus is not useful for this working group
classless - IESG wants some change; waiting for new draft from authors.
· issue is the / in the example
· agreement to change has been done
· mild disagreement which way to change
· change has not been done
· 1101 examples should be removed
· bush: would kre/bush change the draft and get the authors to resubmit
Local-names - informational
· test-tlds - bcp
· kitchen-sink - need time to update doc
· ncache - author not here, kre speaking
· vixie: yes, is ok
· kre: we are done
· in last call
· DS
Vixie on tsig
· way to do cheap security until real thing is there
· all comments are now in or answered
· will go to last call after notice comes out
· no more comments, no more issues, will issue last call
Local-compression
· Peter is not here
· reading his email message
· draft is out
· implementation in progress
· modifing debugging tool in progress
· testing need guinne pig RR
· ask IANA for RR - GP
· should be more than 1 domain name in the RDATA
· maybe RP RR?
· could use the SOA....
· suggest - use SOA
· bug in section 5, will be fixed
· kre: are only 4 type codes; 2 already used, this will eat 1 more
- is this worth it?
- there is also a canadate for other bit
- can also have all 4 bits set mean extend bit - to get 6 more bits
- Bush: please bring this discussion up on the list
dns error (?)
· got comments
· authors finger pointing who to do next draft
· internationalization concerns
· dname
· other concerns
· prob at least 2 more drafts needed
· please send in more comments
Donalds udp draft
· way of getting bigger udp response
· objections heard - forwarding of queries via path of servers that may not understand this may cause loss of data
· problems of recursive queries
· most queries don't need this
· use tcp instead? overhead?
· larger udp may be less load than using tcp
· do you need to know path mtu?
· scheme may be too complex - to figure out how big a udp response to ask for
· vixie: on really advanced system, you might be able to find how big a udp socket you can use but if this comes out, and makes things more usable, then vendors will give us this knob
· need to specify a resonable default behaviour if you don't have any better info of what to use - perhaps 1280
· dnssec is the problem we are trying to solve here so it might be possible to change the dnssec to say that security aware resolvers should do something like this.
· vixie: two other concerns - are a huge base that does not look at rcode on queries, so if there are resolvers that send garbage, new server will do something whacko and thus not work; and strict servers that do not implement this may ignore these queries. Will check the root server to see they get rcode with random data
· vixie has another proposal that was more complex, will look at merging these. Simplicity is good, but it also has to work
· vixie draft: like tsig, add rr in addition section, cache info
- no ambiguity if you get answer back
- more bits to put size, so less ambiguity
· Vixie's way may be a better way of additional functionality hop-by-hop or end-to-end attribute. Further discussion on the list
128bit ipv6 addr, rfc 1880 for quad RR
· view addr different, split into pieces - 8+8 or routing goop. Thus how to renumber a site and change all of the quad RRs
· especially with security and having to resign all of the records takes too long.
· so how to change so that don't need to resign if renumber, plus get more than 1 prefix
· so add bit length of prefix plus pointer to the rest of the stuff and pointers can recurse
should gain bits at every lookup
· is it an error too loose? or stay the same?
· can trade off efficiency of building data versus doing lookups
· need to make sure # of bits is not fixed
· also need to do reverse lookups
· so, should we do this? does it make sense?
· really an ipng draft, but want feedback from dns community
· additional section should be filled in as much as possible with the rest of the quads
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
· rd length will be different from what it is now
· resolver does the combining of these to make real addr
· does this give us variable length addrs????
· can end up with more than one real addr as you do the combining
· name compression is unresolved issue
· ignore the d-bit hack in this stuff
D-bit (another draft)
· in-addr lookups (for above) are problems
· need to track delegation heirarchy
· keep going until you get to the host but need to store this delegation stuff in the dns
- stored as
- number of bits in this delegation
- owner names
- so N.N.N.N.N.N...ip6.int. Dbit M dns.name
- where NNNN is addr and M is how many more to add
- but things are in binary, not text/bcd
· this presentation was not clear
· not sure if this fits the way the we do delegations????
· where is authority break?
· is it like NS or something else?
· this idea has been around for a while
This draft does *not* match the way that I do delegations. How do you do a lookup on a site local or xx local addr? Lots of discussion ensued.
Trying to delegate on bit boundaries or just do the cidrized in-addr trick (at least to all but the bottom nibble).or do bit.bit.bit.bit.....
Further discussion to continue on the list
None Received