[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNSOP] Re: DNSOP minutes for Vancouver -- IETF 70
Dear WG,
> PS: Audio timestamps will be added for the final version.
the minutes for the DNSOP meeting at IETF70 have been updated.
Please find the latest version at
<http://www3.ietf.org/proceedings/07dec/minutes/dnsop.txt> and a diff attached
below.
-Peter
--- ietf70-minutes.txt 2008/01/04 18:48:45 1.2
+++ ietf70-minutes.txt 2008/01/22 22:24:59
@@ -16,10 +16,10 @@
WG URL: http://www.dnsop.org
Material: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num
=70
-Version: $Id: ietf70-minutes.txt,v 1.2 2008/01/04 18:48:45 pk Exp $
+Version: $Id: ietf70-minutes.txt,v 1.3 2008/01/22 22:24:00 pk Exp $
-----------------------------------------------------------------------------
-1) Administrivia [ 09:02 {audio 0:XX:XX} ]
+1) Administrivia [ 09:02 {audio 0:06:38} ]
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
Tools website for latest documents:
@@ -33,7 +33,7 @@
Thanks to jabber scribes (Antoin, Andrew) and minute taker (Shane)!
-2) Status Update [ 09:05 {audio 0:XX:XX} ]
+2) Status Update [ 09:05 {audio 0:08:35} ]
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
- RFCs published
@@ -62,43 +62,40 @@
of undefined term ("centrally assigned").
Reason to have -04 is to submit clean document to IESG; typos and such.
-3) WG Charter
- <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
-
- No progress, edited version to be WG Last Called
-
-4) Active Drafts [ 09:12 {audio 0:XX:XX} ]
+4) Active Drafts [ 09:12 {audio 0:15:40} ]
4.1) AS112
[draft-ietf-dnsop-as112-under-attack-help-help-01.txt]
[draft-ietf-dnsop-as112-ops-01.txt]
Resubmitted with only minor changes to revive expired drafts
- Mohsen Souissi: Isn't it a good idea to make some dynamic
- reference somewhere? In case of prefixes we don't know today?
- Joe Abley: We had this conversation in Prague. There were
- some complications adding/removing servers, and this
- document explains what is done today. So changes to how it
- would be done in another document.
- Mark Andrews: My draft does create a registry, and does not
- require coordination between different sites.
- Peter: We decided to keep this issue separate, because the
- properties of adding/deleting were subtly different.
- Peter: Will issue WGLC on these soon.
+ Mohsen Souissi: Isn't it a good idea to make some dynamic
+ reference somewhere? In case of prefixes we don't know today?
+ Joe Abley: We had this conversation in Prague. There were
+ some complications adding/removing servers, and this
+ document explains what is done today. So changes to how it
+ would be done in another document.
+ Mark Andrews: My draft does create a registry, and does not
+ require coordination between different sites.
+ Peter: We decided to keep this issue separate, because the
+ properties of adding/deleting of new address ranges were subtly
+ different.
+ Chairs will issue WGLC on these soon.
- 4.2) Referral Response Size Issues
+ 4.2) Referral Response Size Issues [ 09:17 {audio 0:20:18} ]
[draft-ietf-dnsop-respsize-08.txt]
Editors updated/revived the draft.
- Akira Kato: Most of comments have led to modification to
- text. 92%+ of queries have EDNS0 at one of JP servers.
- Multi-homed servers section updated. Going to publish -09
+ Akira Kato: Most of comments have led to modification to text.
+ After Chicago there was discussion around the deployment of EDNS0
+ 92%+ of queries have EDNS0 at one of JP servers.
+ IPv6 and multi-homed servers sections updated. Going to publish -09
just after IETF meeting, and then ready for WGLC. Will
address comments received by 2007-12-10.
Awaiting WGLC
- 4.3) Reverse Mapping Considerations
+ 4.3) Reverse Mapping Considerations [ 09:19 {audio 0:22:58} ]
[draft-ietf-dnsop-reverse-mapping-considerations-05.txt]
Andrew Sullivan: feels draft is essentially ready - a few nits
@@ -106,20 +103,21 @@
Awaiting WGLC
- 4.4) DNSSEC Trust Anchor Configuration and Maintenance
+ 4.4) DNSSEC Trust Anchor Config and Maintenance [ 09:21 {audio 0:25:03} ]
[draft-larson-dnsop-trust-anchor-02.txt]
Formal adoption pending. Discussion and review needed.
10-15 people had read the draft and supported adoption as a WG item.
Confirmation to be requested on WG mailing list.
- 4.5) DNS Resolver Priming
+ 4.5) DNS Resolver Priming [ 09:22 {audio 0:26:14} ]
[draft-ietf-dnsop-resolver-priming-00.txt]
- No progress. Some offline comments to be incorporated. No further
- comments or discussion.
+ No progress. Some offline comments to be incorporated, some discussion
+ on the mailing list.
+ No further comments or discussion.
- 4.6) Recursive Nameservers in Reflector Attacks [ 09:23 {audio 0:XX:XX} ]
+ 4.6) Recursive Nameservers in Reflector Attacks [ 09:23 {audio 0:27:18} ]
[draft-ietf-dnsop-reflectors-are-evil-04.txt]
The draft received 4 DISCUSSes during IESG review, including 2
@@ -129,10 +127,10 @@
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-2.pdf>
- {discussion of feedback from IETF Last Call}
+ {Discussion of feedback from IETF Last Call}
Issue 1: Need to rephrase description of the attack to avoid formal
- language and provide more prose.
+ language and acronyms and provide more prose.
Hopefully more understandable now.
Issue 2: Overemphasis of BCP 38, need to clarify role of BCP 38 vs.
@@ -163,28 +161,40 @@
Joao: Yesterday at the IEPG a presentation showed that there
are 16 million open resolvers.
Dave Hankins: Another difference between DNS and SMTP open
- resolvers. In SMTP clients can identify themselves.
+ resolvers. In SMTP clients can identify and authenticate
+ themselves.
+ Peter: Document already mentions TSIG and SIG(0), but their
+ availability was questioned.
Bill Manning: Concerned about the binary nature of open and
closed. Resolver is only useful if open to some.
+ Would suggest everyone ran their own caching entity.
Joe Abley: If the question is: "Is it necessary to run an open
- recursive name server?" - clearly not!
+ recursive name server to support roaming users?" - clearly
+ not!
If the question is: "Is it reasonable?", then it is a
- balance between utility and risk, which is what the draft
- is all about.
+ balance between convenience and risk, which is what the draft
+ is all about. Maybe should focus on how the wrong conclusion
+ could have been drawn from the draft.
Peter: If we recommend closing all open recursive name servers,
then the option to use them for mobility would no longer
- exist. AD DISCUSS asks us to consider strength of
- recommendation.
+ exist. Following the SHOULD to the letter would leave the
+ opportunity to continue this support of roaming users.
+ AD DISCUSS asks us to consider strength of recommendation.
Joe: IETF can't make a "MUST" when it comes to operational
policy.
- Rob: Agree that "SHOULD" is the right word.
+ Rob: Agree that "SHOULD" is the right word. Also, RFC 3833
+ already addresses the attack by the hotel provider.
Mark: With hotels it doesn't matter where you try to direct
the DNS queries, because they'll intercept your packets anyway!
+
Frederico Neves: Two options:
- 1) TSIG and SIG(0), 2) VPN (now in draft)
+ 1) local recursive name server
+ 2) addition of VPN (now new in draft)
Mohsen Souissi: Another option is to manually update the
configuration during mobility.
+ Joao: IP address based access control is mentioned already.
+
Peter: Anyone in support of the objection? - (No hands)
Who is not in support? - (Lots of hands)
Who did not care? - (Couple of hands)
@@ -192,19 +202,24 @@
Peter: Who is in support of the VPN option? - (A few hands)
Who is opposed to it? - (No hands)
- Peter asks the editors to incormorate the comments and resubmit
+ Peter asks the editors to incorporate the comments and resubmit
the draft as -05 in coordination with AD and PROTO shepherd.
Shane: What is the expected next status?
Peter: Shepherding AD responsible to make sure comments are
addressed.
-5) Current & New Topics [ 09:51 {audio X:XX:XX} ]
+3) WG Charter [ 09:49 {audio 0:52:45} ]
+ <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
+
+ No progress, edited version to be WG Last Called
+
+5) Current & New Topics [ 09:51 {audio 0:54:20} ]
5.1) Design Team Report: Requirements for a Name Server Control
and Configuration Protocol
- In Chcago it was agreed upon to form a design team to draw
+ In Chicago it was agreed upon to form a design team to draw
a broader picture of name server management and to produce
a list of potential work areas and requirements and non-requirements.
Jaap Akkerhuis volunteered to lead the team.
@@ -215,11 +230,11 @@
A mailing list has been set up with some initial discussion.
- 5.2) Input to the Design Team Discussion [ 09:53 {audio X:XX:XX} ]
+ 5.2) Input to the Design Team Discussion [ 09:53 {audio 0:56:45} ]
Peter explained that due to the WG schduling the design team didn't
have the chance to meet yet, so instead of a report the time slot
- would be used to provide input to the design team discussion.
+ would be used to provide public input to the design team discussion.
Nothing is yet to be considered for adoption as a WG item and this
should also not be considered design team output.
@@ -227,7 +242,8 @@
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-1.pdf>
Alexander Mayrhofer: Would suggest user-level configuration of a name
- server also. Such as switching on and off caching functionality.
+ server also. Such as switching on and off recursive or caching
+ functionality.
Mohsen: Thought goal of design team was to work on requirements.
This seems like a mixture of solution and requirements.
Roy: What you just saw is work we started with before. We have asked
@@ -259,7 +275,7 @@
No action required, the design team is supposed to meet during
the remaining IETF week.
- 5.3) DNS Search Path Issues [ 10:10 {audio 1:XX:XX} ]
+ 5.3) DNS Search Path Issues [ 10:10 {audio 1:13:50} ]
Peter Koch
<no slides>
@@ -287,7 +303,7 @@
ACTION: Rob & Peter to follow up and appoint editor(s)
-6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:XX:XX} ]
+6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:19:30} ]
6.1) draft-licanhuang-dnsop-urnresolution-00.txt
@@ -303,7 +319,7 @@
Rob: Probably a good idea for people who have read it to explain
to the author why they don't understand it.
-7) I/O with other WGs [ 10:18 {audio 1:XX:XX} ]
+7) I/O with other WGs [ 10:18 {audio 1:22:10} ]
7.1) ENUM WG: Universal Deployment of EDNS0
@@ -315,6 +331,7 @@
George Michaelson: Tried to perform measurements on use of EDNS0.
Occasionally get comments that it is almost universal, 90%,
we can use this. I see 50% attempts specifying EDNS0.
+ "EDNS0 is ubiquitous" is not operationally feasible.
This must be borne in mind!
Peter: Intent was not to declare deployment of EDNS0 done, but
rather to raise the awareness that EDNS0 has to be supported
@@ -323,8 +340,8 @@
varying deployment, shows that our sampling techniques are not
good. We don't really know what is going on yet. We need to do
serious measurement work.
- Olafur Guomundsson: dnsext has a document inm preparation that
- will address general DNS support in software.
+ Olafur Gudmundsson: dnsext has a document in preparation that
+ will address general DNS support in software ("DNS profile").
Will write that EDNS0 MUST be implemented.
Peter: So is there overlap?
Olafur: Middleboxes will have their own separate section (or
@@ -335,15 +352,16 @@
Olafur: Not optimistic about finishing it next year.
Peter: Chairs need to discuss.
-8) A.O.B. [ 10:26 {audio 1:XX:XX} ]
+8) A.O.B. [ 10:26 {audio 1:29:40} ]
Antoin Verschuren reported that SIDN (NL TLD registry) sees small amounts
- of /24 which are doing 10x rest of world in traffic (tens of thousands).
+ of /24 which are doing 10x rest of world in traffic (>10000 q/s).
What can we do about it? How much traffic can we consider "abuse"?
These are name grabbers. Long list of names that they are querying.
This is a policy issue.
- Rob: Do we want to work on developing guidance?
+ Rob: Seems not to affect only this name server operator. Do we want to
+ work on developing guidance?
Liman: Suggest name holder or maybe server operator can set policy for their
own zone. So, say, "this type of traffic we would consider an attack".
Andrew: Gets us close to the idea of classifying certain domains as
@@ -370,5 +388,5 @@
would need to write a draft first.
-----------------------------------------------------------------------------
-Z) Meeting closed [ 10:37 {audio X:XX:XX} ]
+Z) Meeting closed [ 10:37 {audio 1:40:30} ]
-----------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop