Dear WG,
best wishes and a happy and successful 2008 to all of you.
The minutes of our meeting in Vancouver are attached below and have also
been posted to the proceedings website, where they are available at
<http://www3.ietf.org/proceedings/07dec/minutes/dnsop.txt>.
Many thanks to Shane Kerr for taking notes and to Antoin Verschuren and
Andrew Sullivan for acting as jabber scribes. Please send editorial nits
and comments to Rob and me, more substantial issues to the list. For
inclusion in the final IETF70 proceedings, the deadline is Friday, 18 Jan,
1800 UTC.
Regards,
Peter
PS: Audio timestamps will be added for the final version.
-----------------------------------------------------------------------------
dnsop WG minutes for IETF 70, Vancouver, CA
-----------------------------------------------------------------------------
WG: DNS Operations (dnsop)
Meeting: IETF 70, Vancouver
Location: The Westin Bayshore Resort and Marina, "Salon A"
Date: Monday, 03 December 2007
Time: 09:00 - 11:30 (UTC-8)
Chairs: Rob Austein <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Peter Koch <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Minutes: Shane Kerr
Jabber: xmpp:[EMAIL PROTECTED]
J-Scribe: Andrew Sullivan, Antoin Verschuren
J-Script: http://www3.ietf.org/meetings/ietf-logs/dnsop/2007-12-03.html
Audio:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch5-mon-am-dnsop.mp3
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 $
-----------------------------------------------------------------------------
1) Administrivia [ 09:02 {audio 0:XX:XX} ]
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
Tools website for latest documents:
<http://tools.ietf.org/wg/dnsop/>
Agenda Bashing. No changes. Posted at:
<http://www3.ietf.org/proceedings/07dec/agenda/dnsop.txt>
All meeting materials on proceedings page:
<http://www3.ietf.org/proceedings/07dec/dnsop.html>
Thanks to jabber scribes (Antoin, Andrew) and minute taker (Shane)!
2) Status Update [ 09:05 {audio 0:XX:XX} ]
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
- RFCs published
-none-
- Internet-Drafts in RFC Editor Queue
-none-
- I-Ds at the IESG
[draft-huston-6to4-reverse-dns-07.txt] "DISCUSS"
Not a WG documented, but individual submission, brought to the WG for
review and comments.
Ron Bonica (OPS AD): INT AD put a DISCUSS on it, should clear
shortly. Document itself is fine.
[draft-ietf-dnsop-reflectors-are-evil-04.txt] "Revised ID Needed"
See (4.6)
- I-Ds in or past WGLC
[draft-ietf-dnsop-default-local-zones-03.txt]
Rob recused, Peter feels there is consensus.
Awaiting PROTO writeup
Mark will submit clean new version (-04) by end of IETF70;
First change is fix to example, second change is fix to remove use
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.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.
4.2) Referral Response Size Issues
[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
just after IETF meeting, and then ready for WGLC. Will
address comments received by 2007-12-10.
Awaiting WGLC
4.3) Reverse Mapping Considerations
[draft-ietf-dnsop-reverse-mapping-considerations-05.txt]
Andrew Sullivan: feels draft is essentially ready - a few nits
received last week. Aside from that ready to go.
Awaiting WGLC
4.4) DNSSEC Trust Anchor Configuration and Maintenance
[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
[draft-ietf-dnsop-resolver-priming-00.txt]
No progress. Some offline comments to be incorporated. No further
comments or discussion.
4.6) Recursive Nameservers in Reflector Attacks [ 09:23 {audio 0:XX:XX} ]
[draft-ietf-dnsop-reflectors-are-evil-04.txt]
The draft received 4 DISCUSSes during IESG review, including 2
from Security ADs. Joao Damas presents list of identified and open
issues. Missed submission deadline for -05 revision, but URL for
preview given.
<http://www3.ietf.org/proceedings/07dec/slides/dnsop-2.pdf>
{discussion of feedback from IETF Last Call}
Issue 1: Need to rephrase description of the attack to avoid formal
language and provide more prose.
Hopefully more understandable now.
Issue 2: Overemphasis of BCP 38, need to clarify role of BCP 38 vs.
role of operators of open recursive name servers.
Authors still think that if BCP 38 was implemented the attack
would not be a problem. Have changed focus away from BCP 38 to
specific configuration of the resolver.
DNS and network operators not usually the same people!
Issue 3: Some reviewers believe ORNS are needed to support mobile
users, especially to protect them from data capturing or
modification in "hostile" environments (e.g., hotels)
Editors suggest to introduce VPN as another option.
To start the discussion Peter explains that one concern
explicitly raised under issue 3 is that one needs to think
about the implications and side effects when a service
is disabled for security reasons.
Roy Arends: Open resolving name servers are a very, very bad
thing. I'm concerned that we need a hum or working group
support to highlight that. People who have open name servers
for mobility - do they also need open mail servers?
Peter: Difference is a single open name server is not
immediately harmful. A single open mail server can still do
harm.
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.
Bill Manning: Concerned about the binary nature of open and
closed. Resolver is only useful if open to some.
Joe Abley: If the question is: "Is it necessary to run an open
recursive name server?" - 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.
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.
Joe: IETF can't make a "MUST" when it comes to operational
policy.
Rob: Agree that "SHOULD" is the right word.
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)
Mohsen Souissi: Another option is to manually update the
configuration during mobility.
Peter: Anyone in support of the objection? - (No hands)
Who is not in support? - (Lots of hands)
Who did not care? - (Couple of hands)
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
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} ]
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
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.
Jaap Akkerhuis: Hard to get people to understand they are supposed
to follow IETF process. Task is to define requirements, hoped to
have by this meeting.
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} ]
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.
Nothing is yet to be considered for adoption as a WG item and this
should also not be considered design team output.
Steve Morris: NSCP Progress
<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.
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
the chairs if we could present this, and they reluctantly agreed.
There have been other ideas floating around, document is fairly
short, not much comment, but will contain the work we have done.
NOT an attempt to bypass working group.
Rob: A little concerned by putting zone data into this space. First,
we already have a mechanism to do this. Kind of wandered into this
space with the DNS MIB a long time ago. Related observation, would
like a management station that can do everything. That does not
mean we need one protocol that does everything.
Kurtis Lindqvist: Doing a requirements document is a much better
way. Requirements first! If we designed protocols based on what
vendors did we wouldn't have good protocols at all.
Wes Hardaker: Netconf group is just now defining how to write data
models. Have to be sure you track their work so end up with the
same language.
Joe: If we ignore the fact that this is a framework around netconf,
this is perfect input to a requirements document. Data model is
the important stuff.
Lars Liman: I think the goal *is* to put everything in one basket.
Peter: Can't speak for individuals on design team, the team has a
charter to come up with requirements and make recommendations
about what to address and what not to address. They cannot just
change their mission.
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} ]
Peter Koch
<no slides>
Different behaviour has been observed in mixed A/AAAA environments
with respect to following a DNS search path and terminating the
search. There is no written rule yet, so with increasing v6 and AAAA
deployment, inconsistencies could be painful. Some implementations
seem to continue path search for "A", even after "AAAA" has been
found at that path expansion.
Questions: Does anyone agree that this is a problem?
Does anyone have a suggestion that anyone should do
something about this?
Rob: Probably implementors not understanding NXDOMAIN vs. NODATA
responses. Maybe we haven't written it down clearly.
Mark: Very old issue. Raised this in the IETF 8 or 9 years ago and
was told, "there is no problem - go away!" Number of issues here,
"does a CNAME make a name exist when it points to NXDOMAIN", things
like that. Think we should be trying to formalize search methods.
That we have one algorithm out there, so we get to the same node
in the DNS.
Rob: Anyone wants to write the draft? (Mark volunteers)
Anyone will read it? (Some hands)
ACTION: Rob & Peter to follow up and appoint editor(s)
6) Other (non WG) Internet-Drafts [ 10:16 {audio 1:XX:XX} ]
6.1) draft-licanhuang-dnsop-urnresolution-00.txt
The author was not present and had not sent an explicit request for
adoption to the WG.
Rob and Peter ask people to have a look and send comments to
mailing list or author.
Mohsen: Have read but don't see anything related to dnsop work.
{Others support that view}
Rob: How many have read? (About 5 hands)
How many think it is out of scope? (Fewer hands)
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.1) ENUM WG: Universal Deployment of EDNS0
NAPTR records apparently require this. Maybe better if dnsop had a
document when EDNS0 is necessary from an operational perspective,
independent of specific application (i.e., ENUM). Also might need
to address ENUM-agnostic devices ("middleware").
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.
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
as of today.
Rob: Agree with George's concern. Talking to people about wildly
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.
Will write that EDNS0 MUST be implemented.
Peter: So is there overlap?
Olafur: Middleboxes will have their own separate section (or
sections if there are many classes). Would be wonderful if
this group came up with a short document saying you SHOULD
deploy EDNS0 software everywhere.
Peter: Any timeline for this document?
Olafur: Not optimistic about finishing it next year.
Peter: Chairs need to discuss.
8) A.O.B. [ 10:26 {audio 1:XX:XX} ]
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).
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?
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
infrastructure versus not infrastructure. Seen people saying, "we
want to treat certain labels specially", which makes me nervous. But
we have the same problem!
Johan Ihren: Lots of strange things come into DNS lately. Is this
really a technical or operational problem, or is this a business
problem that has spilled over into technical space? Traditionally we
are really really bad at solving business problems in the IETF.
Bernie Hoeneisen: Is there a delay between when names appear in
registry and when appear in DNS?
Antoin: Grace period of 40 days that we will add. Because policies
differ between registries, people move to ask the DNS.
Bernie: How about a random grace period? Problem can be solved by
telling them when domain names are free.
Joe: Is it reasonable work for DNSOP to provide guidance for dealing
with unwanted traffic? Like root-server guidelines, but for other
operators.
Kurtis: Presented something similar to that in Paris.
Chairs suggest any such guidance would fall into the charter, someone
would need to write a draft first.
-----------------------------------------------------------------------------
Z) Meeting closed [ 10:37 {audio X:XX:XX} ]
-----------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
