[01:20:26] --- keith.brazington has joined [02:34:58] --- keith.brazington has left [02:40:51] --- keith.brazington has joined [05:58:27] --- rstory has joined [06:09:02] --- keith.brazington has left [06:09:32] --- keith.brazington has joined [08:53:10] --- keith.brazington has joined [09:01:30] --- roy has joined [09:12:16] --- mikeb has joined [09:45:34] --- russmundy@jabber.org has joined [09:57:02] --- wouter has joined [09:57:36] --- ogud: Olafur Gudmundsson has joined [09:59:17] Audio works [09:59:59] --- mrichardson has joined [10:00:00] --- mrichardson has left [10:00:04] --- yone has joined [10:00:11] --- sm has joined [10:01:26] --- dblacka has joined [10:02:19] --- matthijs has joined [10:04:05] --- Jelte has joined [10:04:09] hiya [10:04:28] --- msj has joined [10:05:35] --- mrichardson has joined [10:05:36] --- Andrew Sullivan has joined [10:05:39] --- fujiwara has joined [10:05:50] Olafur, talks about the agenda, and why we are meeting. [10:06:05] --- mgraff has joined [10:06:08] AD is looking for co-chair. Got list, and is doing interviews. [10:06:36] reviews list of published RFCs since Prague. [10:06:42] Protocol work on DNSSEC is done. [10:07:25] fool me once - shame on you fool me five times and its an IETF working group on DNSSEC [10:07:26] --- Antoin has joined [10:07:30] --- agallant has joined [10:07:38] --- matt has joined [10:07:54] rfc2929bis is going through IESG. [10:08:02] issue with how IANA processes templates. [10:08:18] --- stephen.morris has joined [10:08:30] --- ona has joined [10:08:33] DNS profile is new major document. [10:08:44] to give people guidance about what modern DNS does. [10:08:57] and a zombie came back: axfr-clarify. [10:09:09] --- rstory has joined [10:10:06] ECC: let's just standardize a very few number of curves. [10:10:19] --- dblacka has left [10:11:10] how many are younger than DNS: just Ed. [10:11:45] I don't think Ed can do math. [10:12:09] --- stephen.morris has left [10:12:14] (non-scribe) Ed is reall a 12-year old girl (maybe in his head) [10:12:26] --- Suzanne has joined [10:13:10] --- jpc has joined [10:13:50] --- Antoin has left: Replaced by new connection [10:14:58] (scribe is distracted during discussion about WG document list) [10:16:58] --- dblacka has joined [10:17:35] --- Antoin has joined [10:17:56] PaulVixie: disagrees. Forgery resilience should be included, and two documents should progress together. [10:19:18] Scott Rose up next. [10:19:34] waiting for slides. [10:19:40] DNAME-clarify [10:19:50] what happens when you add/delete DNAME records. [10:20:25] --- levigner has joined [10:22:23] any q from jabber? [10:22:24] --- jiangxingfeng has joined [10:23:03] --- narten has joined [10:24:55] --- jm has joined [10:25:52] George: what does modern DNS really mean [10:25:56] this is from the RAI ADs [10:26:06] is s/w compliant? what needs upgrading? [10:26:33] --- shinta has joined [10:26:39] edns0, deployed does wrong thing, history of bad implementations. "spring clean" [10:26:46] --- pawal has joined [10:28:22] --- Antoin has left: Replaced by new connection [10:31:57] queries to microphone: how do structure this document? [10:34:34] the intention is that the document has to be more than 1 implementation team's views. [10:35:20] unlike other RFCs, this is meant to be revised. [10:35:34] suggestion to ask for future document numbers. [10:36:12] here is a list of RFCs that you need to implement, but take them with grain of salt, and here is how much. [10:36:28] this will grow into DNS 2.0, without changing the protocol, except when we do change the protocol. [10:36:44] will this document, or its existence, block clarifications? [10:37:15] 3rd issue: this is not only addresses to implementors, but also operators. [10:37:31] it could be in one document, or in two documents. [10:37:43] if it's in one document, needs to be seperate sections. [10:37:53] re: TCP listening. [10:38:53] discussion about collecting bits of text, and then redoing the right thing. [10:39:09] Olafur: any protocol work can proceed without blocking this document. [10:39:17] unless we discover that we need a bis of some other RFC. [10:39:57] --- aalain@trstech.net has joined [10:41:03] Ed: 3 parts. wire protocol, semantics, and services. [10:41:14] for some work, we don't follow the semantics, just the protocol. [10:41:57] --- fneves has joined [10:42:03] --- benno has joined [10:43:03] all three pieces are required. [10:43:21] --- weiler has joined [10:43:30] - scribe has to pay attention to emergency at work - [10:44:38] SRA: this doc should possibly include an attempt to address recurrent issues/confusions about terminology for this or that piece of DNS [10:44:50] GGM says "send text" [10:45:46] Andrew Sullivan: lots of little possible documents, termination of this document requires pruning....might depend on lots of sundry bis documents, then what? [10:45:51] GGM: not std [10:46:27] they're agreeing that the primary goal is "the world as it is," maybe with appendices/recommendations about what it should be [10:47:49] Olaf Kolkman: concerned that this document will become a checklist people will address without thought. [10:48:21] some discussion of tradeoffs needed, relative importance of various pieces [10:48:25] --- japi has joined [10:48:52] GGM: wants to shy away from interoperability matrices, but document does need to address the question. [10:48:56] "send text" :) [10:49:24] PAF (whose name I can't spell properly on my keyboard): checkbox lists can break interoperability, ironic but true [10:49:50] volunteers to send text (yay PAF) [10:50:32] PAF: more on checkboxes, consensus on any given one may be hard. [10:51:03] PAF: and maintaining such consensus through multiple revisions will be even worse. [10:51:36] also, sometimes a middlebox/firewall/thing complies with a policy rather than a protocol. [10:51:48] GGM: per Olaf, document the tradeoff when you do this [10:52:48] Olafur: before we go any further, is this worth doing? [10:53:45] poll the room, some support, some suspicion it's futile [10:53:50] --- juampe has joined [10:54:13] Olafur: should we stop now? [10:54:14] guest scribe now retires..... [10:54:25] *applauds for Suzanne* :) [10:54:30] peter: disagree with Patrick + Olaf. [10:54:48] we have documents in the IETF that are so consensus driven, that they have been rewritten beyond any recognizable shape. [10:54:54] that is why the "considerations" bothers me. [10:55:08] some people just want to be told that they ought to implement EDNS0. [10:55:11] --- jpc has left [10:55:15] --- Antoin has joined [10:55:17] this can not be a procurement guideline. [10:55:25] they need more strict advice. [10:55:41] mrichardson-as-me: actually, governments do need the document as a procurement guideline! [10:55:55] new speaker: should this document be an RFC at all? [10:56:03] Olafur: should be a BCP. [10:56:23] a really up-to-date list is necessary... so we need a new document each time? [10:56:27] mrichardson: is dnsext the right group to be offering that guide? [10:56:35] This seems like it should be a research project on a wiki. [10:56:53] Vixie: who thought this was a bad idea... Paul's hand went up. [10:57:03] 1) because it won't be an STD. [10:57:15] Olafur: bcp not good enough? [10:57:18] no. [10:57:23] bcp on ingres filtering... We all do that yes? :) [10:57:31] --- jiangxingfeng has left: Replaced by new connection [10:57:32] --- jiangxingfeng has joined [10:57:49] 2) 1034/1035 were the second edition. Someone thought it was cute to number the DNSSEC as 34/35 as well. [10:58:02] like 2821/2822 restatement of 821/822. [10:58:09] not a profile document, but a restatement from scratch. [10:58:20] Paul wants a new document that is complete. [10:59:49] --- mrichardson has left [11:00:17] --- mrichardson has joined [11:00:19] we need to make sure that this document gets done sooner. [11:00:29] hmm. I got kicked from jabber. [11:00:43] Ed: it helps having the documents split up. [11:00:58] not everyone wants dynamic update/zone interface, so it helps them pick and choose what they want. [11:01:33] new speaker: [11:01:37] deploying IPv6. [11:01:58] new speaker is Kurtis Lindqvist [11:02:02] a vendor who required an IPv6 address to be configured in order to get a AAAA back. [11:02:20] this was not specified in an obvious place. [11:02:32] guidance would be helpful. [11:03:05] new DNS person: wants this document so that he can read it. [11:03:10] would like to write it. [11:03:17] Even Hunt was speaker. [11:03:27] Marc Andrews: likes restatement [11:03:38] index document is important input to that. no wasted effort. [11:03:53] Olaf: someone must be wrong with rfc...foo index? [11:04:00] oh, with rfc-index.txt. [11:04:13] looking through that seems to be doable. [11:04:33] Kurt: we understand what we need to look for, but others do not. [11:04:55] Shane Curt: agree with most statements. This is not a DNS specific problem. So many documents that are so old. [11:05:25] * mrichardson points out that this problem was a problem that NEWTRK tried to solve. [11:05:26] --- fdupont has joined [11:05:48] Olafur: agreement that we need to improve DNS documentation. [11:06:05] disagreement over what we need to do: from checklist to revision to current documents to restatement from scratch. [11:06:15] Olafur is taking this under advisement. [11:06:59] would like timeline to be end of 2008. [11:07:21] this is reasonable, and it will take some work. [11:07:21] there will need to be documents by mid-year. [11:07:38] now next document: EDNS0. Paul. [11:08:05] we did 2671 awhile ago. [11:08:13] got there by throwing stuff out. [11:08:52] this update document is mostly clarification: typographical issues and interface to IANA/RFC-editor changes. [11:08:56] slide 1. [11:09:06] some ignore OPT RR. [11:09:10] --- nevil has joined [11:09:13] TC & !OPT is allowed. [11:09:18] --- jiangxingfeng has left [11:09:19] mention DO bit. [11:11:36] Olafur: EDNS0 great... add a paragraph that says that EDNS0 is mandatory to implement in new implementations. [11:13:12] path of least resistance to do this differently. [11:13:25] this may cause an IETF fight, but that's okay.... EDNS0 itself is out. [11:13:59] Olaf: put text in the security considerations that not supporting it has impacts. [11:14:28] Jim Reid was comments about path of ... [11:14:51] Donald: we can say whatever we want, and it's not unusual for things that were SHOULD to become SHOULDNOT. [11:15:17] Ed is next. [11:15:31] AXFR clarify. [11:16:20] --- Danny has joined [11:16:37] why do this now? [11:16:47] commercial concerns are requesting DNS operations "via AXFR" [11:17:25] process concerns, and were handled in -05. [11:18:17] thickening of the specification. [11:18:57] concern: AXFR client sending an AXFR with EDNS0, must be able to receive multiple records pre response message. [11:19:57] needs to hear from more implementers. [11:22:34] Sam: dnssec-bis-update [11:23:33] issue in 2007-09, with AD/DO conflict. [11:23:59] --- msj has left [11:24:04] copy CB bit to upstream queryes. [11:24:39] --- Roque@lacnic.net has joined [11:24:46] mst: intermediate resolution was designed as if there was only one resolver in the chain. [11:25:30] If client sets CB bit, and intermediate resolver asks another upstream intermediate resolver. The second one might filter out the authoritative data. [11:26:08] Olaf: support. [11:26:16] it's an end-to-end issue. [11:26:54] Marc Andrews: if we set the CB bit, it has to be pushed up the stack. [11:27:02] but, any resolver can set the bit, and it stays set. [11:27:30] a client which does not set CB, should still be able to get CB set upstream. [11:28:00] mst: the bit says that I want all the data. [11:28:07] Marc thinks... [11:28:41] Russ: this is legitimate clarification. [11:29:59] next item: SOA in negative answers. [11:30:04] :-) [11:32:00] Ed: nodata vs .... [11:32:08] shout out, header bits are not signed. [11:32:21] Sam: editors are not hearing enough to support this. [11:32:29] Marc: could put an RCODE on the nodata. [11:32:41] we have an RCODE allocated for no RR set. [11:32:46] Olafur: send text. [11:32:48] Yes Mark that would solve it [11:32:57] Sam: is there anything we have missed? [11:33:45] Jelte: RSA/SHA-256 signatures. [11:33:52] would like to make it a working group item. [11:35:45] Not implemented - understand [11:36:04] hopes WG can take this up. [11:36:30] Olafur: document is two years old, but was deferred for NSEC3. [11:36:37] do we want to start this work now, or is this premature? [11:37:33] concerns that SHA1 may become unrecommended within a year. [11:37:39] Paul: x-20 [11:37:50] no slides for this. [11:38:02] dns-x-20. a terrible hack. [11:38:12] Dave Dagen. usually has better ideas! [11:38:16] Dagon [11:38:25] Paul: a few million transactions now. [11:38:39] Paul thinks that it ought to advance. [11:38:53] changed so that the query can be copied bit-for-bit. [11:38:57] we, must be be copied. [11:39:02] s/we/er/ [11:39:19] Olafur: a resolver that does this has to undo things before handing to application. [11:39:39] Stuart Cheschire: compile a list of bad implementations. [11:39:55] not just recursive servers,but all other middle boxes. [11:40:11] the DNS servers given out here do not work for PTR records.... for instance. [11:40:26] explicit scope is for recursive name servers. [11:40:39] too many broken middle boxes for stub-resolver use. [11:41:00] Olafur: wants to ask for hum, but postpones to after Donald's slot. [11:41:08] --- jm has left [11:41:46] i wonder how much damage is done by 'hotel-middleboxes', both directly to guests at the hotels and by stopping protocol enhancements 'because hotel middleboxes will break it anyway' [11:42:02] discusses cookie handshake protocol. [11:42:16] eastlake-dnsext-cookies-03.txt [11:42:22] protect against off-path DNS DoS. [11:46:47] --- fdupont has left [11:47:07] --- narten has left [11:48:22] take document to list. [11:48:22] http://sa.vix.com/~vixie/dns-0x20.txt < x.20 idea. [11:48:22] Paul: looked at doing cookies with OPT. [11:48:22] this is not enough better than other things to justify this. [11:48:22] a great idea, and a much better explanation, but does not see a reason to pursue, vs TSIG or DNSSEC. [11:48:22] Donald: TSIG is not practical to deploy in this way, and DNSSEC makes DoS attacks much worse. [11:48:22] new speaker: personally interested in this idea.... cookie idea. [11:49:40] --- jm has joined [11:50:25] --- jm has left [11:50:48] --- juampe has left [11:50:54] Olaf: x.20 only protects client, but does not protect the server. [11:50:56] --- juampe has joined [11:51:04] --- matt has left [11:51:15] Olafur: we can adopt this as a WG item, and then decide not to proceed with it. [11:51:35] Olaf: is there someone willing to write code for cookie? [11:52:05] Peter: x.20 ... from what I grasp, it's a horrible idea.... there is nothing to standardized. except that the bits are copied. [11:52:20] that part should be addressed anyway. This gap should be filled. [11:52:41] Peter: would rather not recommend this. but it can't be prevented. [11:52:54] Could Peter explain why ? [11:53:06] roy, are you in the room? [11:53:12] Only on Jabber [11:54:24] Peter: it's a horrible kludge. Either we believe in the DNSSEC stuff, or we don't. [11:54:26] --- ona has left [11:54:52] Olafur: x-20 would be valuable even after universal of DNSSEC. [11:55:01] tx mike [11:55:14] Sam: it will be at least as useful afterwards as before. [11:55:30] Sam: what happens (with x-20) due to caching? [11:55:45] Sam: what about if I was asking for a certain name, IDN, etc.... [11:56:03] Olafur: US-ASCII was deemed to be case insensitive, so you can mangle. [11:56:43] Paul: if it's a binary label, then no work. [11:57:26] Paul: speak in defense of cookie proposal. It protects more than just the clients. [11:57:37] Paul: longer names are more secure than shorter ones with x-20. [11:57:57] Paul: expresses dismay about state of DNSSEC. But, Paul can do x-20 and cookies. [11:58:32] Olaf: believes in DNSSEC. this is ugly to the point of beautiful. [11:59:06] --- weiler has left [11:59:21] --- matthijs has left [11:59:41] can't we call it REM sleep? [11:59:44] Olaf: can you announce whether or not we are coming out of sleep. [11:59:50] to the WG as well. [12:00:29] --- pawal has left [12:00:36] --- dblacka has left [12:00:38] --- Jelte has left [12:00:50] --- juampe has left [12:01:10] --- Andrew Sullivan has left [12:01:53] --- agallant has left [12:01:56] oh... now at AXFR/UDP. [12:02:15] --- Roque@lacnic.net has left [12:02:26] Ed: maybe IXFR will do. [12:02:51] IXFR can not support this as written, but it could be changed....? [12:03:02] Olaf: or setting SOA to zero. [12:04:18] --- shinta has left [12:04:29] --- mikeb has left [12:04:43] --- levigner has left [12:07:08] --- japi has left [12:07:17] --- Antoin has left [12:08:07] --- sm has left [12:09:42] --- russmundy@jabber.org has left [12:11:29] --- Suzanne has left [12:11:52] --- roy has left [12:14:06] --- fdupont has joined [12:14:07] --- fdupont has left [12:14:49] --- mgraff has left [12:15:00] --- fneves has left [12:16:28] --- wouter has left [12:20:30] --- nevil has left [12:29:11] --- Roque@lacnic.net has joined [12:29:13] --- ogud: Olafur Gudmundsson has left: Replaced by new connection [12:29:16] --- levigner has joined [12:29:21] --- levigner has left [12:33:44] --- russmundy@jabber.org has joined [12:33:48] --- yone has left [12:47:24] --- mrichardson has left [12:52:28] --- rstory has left [13:11:00] --- keith.brazington has left [13:23:34] --- fujiwara has left [13:25:45] --- russmundy@jabber.org has left [14:12:22] --- aalain@trstech.net is now known as aalain [14:24:09] --- Roque@lacnic.net has left [15:01:24] --- Danny has left [15:03:56] --- benno has left [15:30:12] --- aalain has left [18:29:42] --- Danny has joined [22:33:05] --- Danny has left