Dear WG,
here are the draft minutes of our meeting at the Dublin IETF, also posted
at <http://www.ietf.org/proceedings/08jul/minutes/dnsop.txt>.
Audio time stamps will be added for the final version.
Thanks to Shane Kerr for being the scribe, post editing errors are mine.
Please let Rob and me know of any errors or omissions by 15th September 23:59
UTC.
-Peter
-----------------------------------------------------------------------------
D R A F T dnsop WG minutes for IETF 72, Dublin, IE
-----------------------------------------------------------------------------
WG: DNS Operations (dnsop)
Meeting: IETF 72, Dublin
Location: Citywest Hotel, Saggart, Co Dublin, IE; "Ballroom 1"
Date: Tuesday, 29 July 2008
Time: 13:00 - 15:00 (UTC+1)
Chairs: Rob Austein <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Peter Koch <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Minutes: Shane Kerr
Jabber: xmpp:[EMAIL PROTECTED]
J-Scribe: Marcos Sanz, Joao Damas
J-Script: http://jabber.ietf.org/logs/dnsop/2008-07-29.txt
Audio:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch7-tue-noon.mp3
WG URL: http://www.dnsop.org
Material: https://datatracker.ietf.org/meeting/72/materials.html
Version: $Id: ietf72-minutes.txt,v 1.1 2008/08/29 18:57:16 pk Exp $
-----------------------------------------------------------------------------
1) Administrivia [ 13:07 {audio 0:00:00} ]
<http://www.ietf.org/proceedings/08jul/slides/dnsop-0.pdf>
- Scribes, blue sheets
- Mailing list now has TMDA in front of it, so posters not subscribed
should expect a challenge to respond to
- agenda bashing <http://www.ietf.org/proceedings/08jul/agenda/dnsop.txt>
no changes
- IETF guest day
-----------------------------------------------------------------------------
2) Status Update [ 13:10 {audio 0:00:00} ]
- RFCs published
- NONE -
- Internet-Drafts in RFC Editor Queue
- NONE -
- I-Ds at the IESG
draft-ietf-dnsop-reflectors-are-evil-05.txt
<https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-reflectors-are-evil/>
All issues with reflectors-are-evil document resolved except one
IESG comment. AD holding document because of comments from Paul
Hoffman, but he is not aware of that and is happy with current
version.
Ron Bonica (area director) will call off DISCUSS.
- I-Ds in or past WGLC
draft-ietf-dnsop-default-local-zones-06.txt
Waiting for PROTO Write-Up
draft-ietf-dnsop-reverse-mapping-considerations-06.txt
Waiting for PROTO Write-Up
-----------------------------------------------------------------------------
3) WG Charter [ 13:13 {audio 0:00:00} ]
Performance and measurement topics might have overlap with both
PMOL and BMWG, but talking with chair of these WGs (same one person),
so expect new draft after IETF.
-----------------------------------------------------------------------------
4) Active Drafts [ 13:14 {audio 0:00:00} ]
4.1) draft-ietf-dnsop-respsize-11.txt
Awaiting WGLC
4.2) draft-ietf-dnsop-as112-ops-01.txt
draft-ietf-dnsop-as112-under-attack-help-help-01.txt
Awaiting WGLC
Need to be revived for WGLC, no other hurdles.
4.3) draft-ietf-dnsop-dnssec-trust-anchor-02.txt [ 13:15 {audio 0:00:00} ]
Matt Larson: Thought were going to have a WGLC in April.
Think everyone's comments are addressed in -02 of this draft,
so still ready for last call. When will this be?
Chairs: Real Soon Now
4.4) draft-ietf-dnsop-resolver-priming-01.txt [ 13:16 {audio 0:00:00} ]
Peter Koch: How many have read it? [About 10]
Revised document to include comments on -00 versions.
One topic removed:
* DNSSEC validation of priming response.
Other changes:
* should NOT expect exactly 13 NS RRs (due to private/split
DNS scenarios)
* differences in priming response should notify operator
somehow
Issues:
* What to do when only 512 octets available for response?
Current text says, "prefer A". Different strategies exist
today.
Lars-Lohan Liman: What is the reason for wanting to specify
this?
Peter Koch: Sounded like a good idea to be consistent and
friendly to resolving systems. If we can leave this
open, then happy to remove this stuff.
Lars-Lohan Liman: I think you should avoid specifying and
leave it to operator of the server. Allows changes, and
also diversity between operators, and also either A or
AAAA recommendation will be premature or outdated.
Peter: RFC 4472 already makes recommendations. One
reason there should be guidance is that those root name
servers that fill in AAAA might give priming responses
that lack information completely for a given root
server. How should a resolver deal with that situation?
Lars-Lohan Liman: If you don't know, ask a root name server.
They all carry all the names for the others. If we *do*
have a recommendation, it should be to mix address
types.
Jaap Akkerhuis: Better to be mixed than to prefer things.
Jaap Akkerhuis: Some of the recommendations are not really
clear whether they are for the servers or for the
resolvers. These problems can be solved by making
explicit.
Peter: Intent is for it to be specific for client and
server.
Stephane Bortzmeyer: <missed first comment>
Peter: Addresses for name servers for TLDs or futher
Stephane: What to do if priming response is
incomplete? Inconsistency between cache and response. Not
a big difference between priming and ordinary requests.
Rob Austein: There is a larger issue. EDNS fallback rules
are starting to be a problem. What does a client do if it
tries EDNS query and it does not work?
Andrew Sullivan: [ Mostly echoing from jabber room. ] Should
be talking about tradeoffs rather than making
recommendations. A little uncomfortable making firm
recommendations here. If you prefer A, some people will
be 2nd class systems if they are moving to AAAA.
Peter: Documenting tradeoffs means you cannot reach
concensus, and I hope that we are not there yet. Also,
this is a special place in the DNS tree.
Mark Andrews: A lot of this comes back to bad behavior in
BIND 8. IPv6 capable name servers are supposed to accept
EDNS0. If you want to keep BIND 8 working you need to
preference AAAA.
Peter: If you have received your first incomplete
response, you already have something to feed into your
cache, so you could start the normal resolution process.
Mark: You can, but you can also ask for the rest of
your information. BIND 8 and BIND 4 did not, as they are
lazy.
Peter: Chapter & verse welcome as additional text.
* What to do if priming response is incomplete (size or lack
of EDNS0)?
* Can we assume all root name servers to be authoritative for
the root name servers names. Today this is not true, as L
root does not serve root-servers.net.
Matt Larson: The intent is that they all serve
root-servers.net, and if this not true now we need to fix
this.
Mark: Information should be the same.
Peter: Yes, but how efficient is it to get this
information? Better to not have to go to the .NET servers
to get this information.
Brian Dickson: Rather than having a universal set of rules
for each root server, we can have a set of results that
can be expected.
Peter: What happens if the client did not signal EDNS0
or used 512 and the server replied with more? That is a
protocol violation. You cannot send unsolicited large
packets.
Lars-Lohan Liman: It is not good to return information that
should come several layers down. But this is how it
works.
Removed DNSSEC recommendations:
Should we reconsider this and put the recommendation back?
Is there any purpose in setting the DO bit in the priming
query?
Mark: Recommend letting client make own decision
about DO bit.
Peter: What would you do? What do you do?
Mark: We set DO bit if DNSSEC is enabled.
Stephane: -01 says priming request must be UDP.
Why is this? Also do recent developments mean we should
reconsider?
Peter: 1123 says you must start with UDP instead of
TCP.
Stephane: If resolver poisoned during priming a
big problem. We can suggest TCP for priming only.
Other Issues:
* Are A/AAAA/NS RRSet TTLs to be aligned?
* Within the root zone? With root-servers.net?
* Should it be in IANA considerations? (Not strictly covered
by RFC 2860)
Lars-Lohan Liman: IANA considerations is not in the right
place. Not all root servers are handled by IANA; you can
have a private network.
Peter: What about the first two questions?
Lars-Lohan Liman: I would think aligning is a good thing.
But DNSSEC might not allow this. Mark?
Mark: Records should not be there. Answers will
always come from .NET, so non-issue.
Peter: But if you look at the TTLs, they are different,
and do not match root-servers.net.
Mark: Should not be there. Nothing in 1035 that says
to look there! Need to fix the spec!
Mark: As for TTLs... make them align.
-----------------------------------------------------------------------------
5) Current & New Topics [ 13:35 {audio 0:00:00} ]
5.1) Design Team Deliverable [ 13:35 {audio 0:00:00} ]
"Name Server Configuration Protocol Requirements"
<draft-hardaker-dnsops-name-server-management-reqs-03.txt>
<http://www.ietf.org/proceedings/08jul/slides/dnsop-1.pdf>
Wes Hardaker
Who has read that was not on the design team? [ Several hands ]
Ed Lewis: Lot of security items. Did you also consider like
"also-notify", and other things?
Wes Hardaker: See if addressed later in presentatin.
Carsten Strotmann: named-checkzone in validating the data?
Kind of weird.
[ agreed to hold until end of presentation ]
Steve Crocker: One of the scenarios is ability for one group
to manage the contents of the data, but service and
signing elsewhere (or where the data is). To what extents
do the requirements anticipate both scenarios?
Wes Hardaker: Document is much higher level. Gut feeling is
to list as deployment scenarios.
Steve Crocker: These scenarios are of interest to user
communities.
Questions: Does DNSOP want it?
Where should follow-on standards work be done?
5.2) Design Team Status and Next Steps [ 14:09 {audio 0:00:00} ]
Jaap Akkerhuis
- Make requirements WG work item
- Disband design team (DCOMA)
- Start protocol work
- Need design team?
Rob Austein: Our feeling is design team has done its job, so
just normal WGLC procedure for document.
Peter Koch: How many read latest version, outside of design
team? [ More than 5 hands - 10ish? ]
Peter: Is this a useful draft to continue within this WG?
Andrew Sullivan: [ Jelte Jansen in jabber room. ] Should
document not be an RFC but just used as a basis for protocol
work?
Rob Austein: Want a stable document to pass off to other group
(maybe).
Jaap Akkerhuis: Written as a requirement not a design.
Mohsen Souissi: Read document, found quite comprehensive.
Should we use some new keyworks like RFC 4307 (should+,
must-, and so on)?
John Schnizlein: Critical for managing DNS, so support this and
appreciate design team.
Roy Arends: Please issue a hum for adoption.
Rob Austein: Already seen more than 5 people who have read it.
Show of hands who will read future versions. [ LOTS of
hands, 20ish ] Hum... [ loudish hum in favor ]
5.3) Proposal to revise RFC 4641 [ 14:20 {audio 0:00:00} ]
<http://www.ietf.org/proceedings/08jul/slides/dnsop-2.pdf>
Paul Hoffman: Came from .ORG DNSSEC review, PIR used the RFC
and it was not good!
Olaf Kolkman: All issues brought up are worth discussing. Do not
necessarily agree wth all arguments, but that is part of
discussion. Not sure if should be informational or BCP. Was
not a BCP; maybe should be, but probably still in too much
flux. Willing to hold a pen for this. Will support changing
the document.
Steve Crocker: Trust anchor words put them in a 2nd class
position if your parent is signed. I think this is debatable.
We are going to have to deal with trust anchors, comfortably,
in a 1st class way. Trust anchor system is necessary, and
will stay around.
Paul Hoffman: Signing the root does not make the problem go
away. We still have trust anchors!
Olaf Kolkman: You will never know who configured your key as a
trust anchor, so you always have to treat your KSK as a trust
anchor.
Wes Hardaker: If you are going to talk about rolling keys and
putting DS in parent, I recommend putting advice for TTLs.
Rob Austein: Should we adopt the document?
Wes Hardaker: Hard to say, since you say "we may want to change
things".
Olaf Kolkman: Propose treating current document as draft and
starting an issues list.
Peter Koch: Want clear deliniation of issues, some from crypto,
rollover issues, and so on.
-----------------------------------------------------------------------------
6) Other (non WG) Internet-Drafts [ 14:37 {audio 0:00:00} ]
6.1) Non-Availability of Dynamic Updates [ 14:37 {audio 0:00:00} ]
<draft-jabley-dnsop-missing-mname-00.txt>
<http://www.ietf.org/proceedings/08jul/slides/dnsop-3.pdf>
Joe Abley
Rob Austein: Useful proposal, but not obvious to me this is a
DNSOP item, might be protocol change so for other WG.
Mark: Document predicated on broken update clients.
Supposed to use NS RRSET, not SOA. MNAME in SOA is only used
to choose between name servers in NS RRSET.
Joe Abley: Behaviour I have seen is if MNAME matches something
in NS RRSET then do not set.
Peter Koch: Appreciate the problem description. Do not like the
adoption as WG item, since I don't like the solution. Should
do something about problem though.
Wes Hardaker: Would want to see a description of why this is a
problem in the real world. Do you have measurements about
this?
Rob Austein: Look at "A Day in the Life of J.ROOT"
Joe Abley: Traffic is being received, not sure it is a problem.
Jim Reid: <missed comment>
Olafur Gudmundsson: Chairs of two DNS WGs need to talk about
where this will reside.
Rob Austein: Hum if you think this is a problem that needs to be
solved? [ Pretty loud in favor, nothing against ]
Andrew Sullivan: Even if this is a protocol change, there may be
other answers which do not involve protocol changes.
Olafur: Chairs of DNSEXT would like DNSOP to host a
discussion about the problem. Later decide where to deal with
it.
[ Some hum in favor of this discussion ]
Joe Abley: Would like to point out that draft is shorter than
the discussion.
6.2) EDNS0 Support in Auth Servers on 27 July [ 14:50 {audio 0:00:00} ]
<draft-kerr-dnsop-edns0-penetration-00.txt>
<http://www.ietf.org/proceedings/08jul/slides/dnsop-4.pdf>
Shane Kerr
George Michaelson: Does not contract clients not using EDNS0. On
client side I see 60/40 split (60 do have it).
Rob Austein: EDNS capable clients may not need to do fall back
anymore.
Ed Lewis: Measuring this against domains? Could be someone has a
slave server stuck in the old days. Curious how many domains do
not work.
Wes Hardaker: Numbers done before or after CERT announcement?
Joe Abley: After. We may run this a number of times.
Olafur Gudmundsson: Really cool. You hit "regular" name servers,
not load balancers and so on.
Jim Reid: Wonder if you have any analysis on recursive resolvers?
Joe Abley: Zones we use, we run authority servers.
Shane Kerr: May not be quite as rosy because some name servers drop
packets for EXAMPLE.COM. Will run again with queries within
delegated zones.
6.3) draft-licanhuang-dnsop-distributeddns-04.txt [chairs]
cancelled
-----------------------------------------------------------------------------
7) I/O with other WGs [ 15:01 {audio 2:00:00} ]
v6ops: DNS AAAA synthesis
-----------------------------------------------------------------------------
8) A.O.B. [ 15:02 {audio 2:00:00} ]
NONE
-----------------------------------------------------------------------------
Z) Meeting closed [ 15:03 {audio 2:00:00} ]
-----------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
