[DNSOP] Minutes from IETF 84 DNSOP Meeting

[Stephen Morris <[e-mail]>]

The minutes from the WG meeting last week in Vancouver are here
for review; they have also been uploaded to the meeting materials
page.

Please advise the chairs of any errors or omissions.

Stephen


====
WG:         DNS Operations (dnsop)
Meeting:    IETF 84, Vancouver
Location:   Hyatt Regency Vancouver, Georgia B
Date:       Thursday, 02 August 2012
Time:       17:30 - 18:30 (UTC-07:00)
Chairs:     Peter Koch     <[e-mail]>
            Stephen Morris <[e-mail]>
Jabber Log: <http://www.ietf.org/jabber/logs/dnsop/2012-08-03.html>

(Times in brackets are times on the audio record:
http://www.ietf.org/audio/ietf84/ietf84-georgiab-20120802-1730-pm3.mp3)


0) Introduction [0:00]
   <http://www.ietf.org/proceedings/84/slides/slides-84-dnsop-2.pdf>

1) Administrivia [0:40]

Minute Taker:   Alexander Mayerhofer
Jabber Scribes: Andy Newton, Patrik Wallstrom

2) Status Update (drafts not mentioned in "Active Drafts") [3:20]

draft-ietf-dnsop-respsize: This should go to the IESG really soon.
It has already had several last calls, so another nits review will be
done, then the proto write-up created and posted to the list for a week
or two (instead of doing another last call).  After this it will be sent
to the AD.

3) Active Drafts
   3.1) <draft-ietf-dnsop-rfc4641bis> [5:00]

This is finally off the chairs' plate - there have been a couple of
revisions since WG last call. It is currently awaiting AD evaluation
and  IETF last call (the chairs are expecting comments from broader
community). Some typos have already been found, and these will be
corrected after IETF last call.

    3.2) <draft-ietf-dnsop-dnssec-dps-framework> [5:40]

IETF last call finished on 17 July, and was discussed at IESG meeting on
18 July.  There were three DISCUSSes: one concerned copyright permission
and has been cleared.  The second concerns communication of a change
of DNSSEC policy (with a related comment about PKI comparison): the
intention is to make some changes to clear this. The third comprises
three questions about: agreements with relying parties, trust anchor
distribution, and description of algorithm rollovers: it is hoped these
can be cleared in discussion with the relevant AD.

The chairs are in discussion with the editors on these and hope to
clear them with the ADs.  Significant changes will be posted to list:
if no objections, a -09 version will be submitted.

    3.3) Next steps in Key Timing (Stephen Morris) [8:00]
         <draft-ietf-dnsop-dnssec-key-timing-03.txt>
         <http://www.ietf.org/proceedings/84/slides/slides-84-dnsop-2.pdf>

The document got resurrected after about a year. KSK timings (related to
RFC 5011) were modified and a minor change made to the section on first
keys in a zone. A number of other nits were corrected. In Quebec (IETF-81)
there was a feeling that the document should be published. In light of
the long delay between versions, and that the -bis version of Matthijs
has found some favour on the list, is that still the feeling of the WG?

About 15 people have read the document.

Matthijs Mekking: Important to continue the work on the base document,
but do that quickly. Don't want to wait another year.

John Dickinson: As one of the authors of the original draft, please get
it published.

Andrew Sullivan: Remembers we said quick decision at last meeting. Ship
it or kill it, but make a decision.

Paul Hoffman: Kill it. Will be the wrong message to the community sending
out two documents. Operators will implement this, and later be surprised
by the change. Kill it and have the -bis document include everything.

Matthijs Mekking: Yep, agree, same question again.

Stephen Morris: Is the -bis document based on your experience of
implementation?

Matthijs Mekking: This document is not flexible enough, this is the
experience, eg. when going from signed to unsigned. To sum  up, yes.

Andrew Sullivan: Don't personally care whether we ship it or not, but
make a decision! People out there are waiting for information, and we
will give out information that changes, but this is better than nothing.

Bill Manning: Perfect is the enemy of the good. Ship it now, at least
we have some information out. By the time -bis is ready, something will
have changed.  If not, kill it.  Ship it, but do not stop work on the
-bis. If we can get it out quickly, do it.

Peter Koch: Heard interesting different things. Are there strong issues
with the *current* document? No hands. Putting the question in another
way: how many think it is ready for last call? About ten-ish. Who thinks
it is not? No-one.

Conclusion: WGLC will be issued soon.

Question from Jabber: When issued? Definitely before Atlanta!


4) Other (non WG) Internet-Drafts

   4.1) Omniscient AS112 Servers (Warren Kumari) [19:35]
        <draft-wkumari-dnsop-omniscient-as112-00.txt>
        <http://www.ietf.org/proceedings/84/slides/slides-84-dnsop-0.pdf>

Warren Kumari described what AS112 is for - a distributed sink of Anycast
servers to answer e.g. RFC 1918 space PTR queries.

How will new space be added to AS112? Just send AS112 operators new
zone file.  However, the AS112 project is really a loose collaboration,
many operators unknown. Some enterprises have local AS112 nodes not
announced externally. Also cases where contact information is out of date.

Omniscient AS112 servers - are authoritative for everything ("."),
but know nothing. They comprise an empty zone with SOA and NS records
shown. Will authoritatively answer "does not exist" for everything. To
add new space to AS112, just delegate the space to them.

Main question: should the server be authoritative for "." or ".arpa"?

[27:43]

Mark Andrews: Examples have AA flag set.  Please re-check through
recursive servers with local zones turned off - will not work. named
does sanity checks on SOA record.

Warren Kumari: Original propose was to synthesise answers on the file.
Will recheck with BIND.

George Michaelson: This is not the last AS112 draft, just the last draft
about how to do it. Delegating and undelegating requires a formalism.
This proposal makes a lot of sense.

Peter Koch: Do you have an opinion on the "." SOA record?

George Michelson: Am confused about what happens if someone is directed
to one of these servers.  Absolutely sure there are no side effects?

Warren Kumari: Absolutely sure there are side effects.

Bill Manning: Looks hauntingly familiar. It might also work if doing
a wildcard in the existing root (laughter) Serious question: If you are
authoritative for the root, two questions: how is this different from
people running their own root, and are you going to sign it?

Warren Kumari: Not going to sign it. For other question, not hugely
different, but different motivation.

Ondrej Sury: Different, because there are delegations to those
servers. Not pretending you are root.

Lars Johan Liman: If you are going to be authoritative for the root,
why lie? Why not put the true root zone there?

Warren Kumari: Because you are just trying to serve an NXDOMAIN.

Lars Johan Liman: Problem is that NS records could be cached. Respond
with the real root zone instead! Also, this plays into hands of people
who want to fiddle with domain names, e.g. requests from law enforcement
who want names removed: perfect infrastructure for it.

Warren Kumari: Answer to second point is that if you can delegate to
these, you can remove the zone.  Questions: a) is it worh progressing,
possibly synthesising responses b) adopt this document?

Peter Koch: Significant issues raised, please continue the discussion,
adoption would be premature.


   4.2) Child-Parent DNSSEC Key Exchange (Paul Wouters) [38:00]
        <draft-wouters-dnsop-secure-update-use-cases-00.txt>
        <http://www.ietf.org/proceedings/84/slides/slides-84-dnsop-1.pdf>

(Peter Koch: Introduction - Paul Wouters volunteered to write use cases
following a couple of rounds on this and other mailing list where people
came up with ideas for substituting/exectinging provisioning stream for
key material.)

Use cases. Can we use DNSSEC to solve problems we had before but could
not address because we did not have authentication? This is not about
replacing dynamic updates in any way.  Have assumed that the target
RRTYpes are DS/NS/glue. Trying to take into account various relationships
between parent and child.  Hope that we can parallelize use cases and
specification at the same time.

Peter Koch: How many read the draft? 10-15?

Andrew Sullivan: Have read, appreciate the work, perfectly good as
a starting point for WG. Support adopting it. Parallelizing the work
(doing requirements and implementation) is a bad idea. We should try to
get this done pretty quickly, would like to see the WG working on this.

Mark Andrews: DNSSEC is a catalyst, definitely work we need to do.

Johan Ihren: Have implemented this sort of thing before, and it works.
Not clear this is a DNS issue: although data goes in-band, need triggering
mechanism outside of DNS.

Antoin Verschuren: Remember starting this, was enthusiastic back
then. Needs and external authentication mechanism to bootstrap,
therefore always two mechanisms in place - needs to be clear in the
document. Question about adoption, especially by ICANN and registrars.

Paul Wouters: Further down the tree there is no registry etc. involved,
and we want to automate things there.

Paul Hoffman: Johan - are you OK with limiting the use cases to *finding*
the trigger in the DNS?  If use case is everthing in DNS, is that OK?

Johan Ihren: Seeing problems, but very much in favor of progressing this!
Question of automating *lots* of delegations further down the tree -
costs can be minimised.

Paul Hoffman: Very much in favour of work being done.

Patrik Wallstrom: We are so bound by policies, we cannot possibly
bypass the registrars, cannot see how registrars will be involved in
this WG. Registrars need encouragement to do it.

Olafur Gudmunsson: Nothing to stop registrars vetting data.

Patrik Wallstrom: Problem with separation of registries and registrant.

Olafur Gudmunsson: But data is in the DNS, added by registrar, this is
just another mechanism to passing it through.

Johan Ihren: Nothing to prevent parent discovery, very difficult to work
out how do that notification in-band.

Peter Koch: Devoting time and energy of WG participants means there needs
to be chance of deployment. Need to discuss this further on the list.
Can we frame the problem such that any solution is used beyond "DNS
geeks"?  How big is the target audience?

Andrew Sullivan: People who paid for me to come here want this, not only
for registry/registrar operations.

Peter Koch: Conclusion: Take this to list, please. Seriously. Have
to continue framing discussion there and collect input, then make a
determination - *before* Atlanta.

Matthijs Mekking: If people in the room want to adopt the document,
why do we have the question?

Peter Koch: "Price Tag" is in the commitment for the document.
Even though we adopt documents, we have a hard time getting input and
quality reviews.

Wes Hardaker: "I use the Internet" - What's frequently broken is the
parent/child relationship, worse with DNSSEC. This will be a god-send in
synchronizing the data! Promise to read and review the document. Problem
is there and needs to be fixed.


6) A.O.B.
   DNS operational/counter data collection (Simon Perreault)
   [57:35] <draft-perreault-dnsop-stats-mib-01.txt>
   <http://www.ietf.org/proceedings/84/slides/slides-84-dnsop-4.pdf>

DNS statistics collection: TLD operator who has third-party anycasts and
wants per-node statistics. Proposed is MIBs - simple read-only counters
based on BIND9 statistics (that's what's in the draft). Simple goal -
expose usage statistics over SMTP - don't want to configure or control it.
MIB was simple to write.

John Dickinson: Never heard anyone say MIBs are easy to write.
Are alternative ways, e.g. NETCONF, which has advantages such as
role-based access control.

Peter Koch: How many people have read this? Five-ish. Two questions: a) is
the problem worth exploring and then b) are MIBs the right way? Recommend
abstract the problem from the MIB solution.

Lars Johan Liman: Idea of a DNS MIB is not new, it's been around at least
once (or twice?). Compare with previous attempts? Should not  preclude
other access methods to access the data.


5) I/O with other WGs [1:04:35]

Peter Koch: Please look at the other WGs eg. HOMENET.

Actions
=======
1) [ALL] Respond to change suggestions for the DPS framework once they hit the
   list.  IESG comments can be found at:
   <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/ballot>

2) [Peter] NITS review and PROTO writeup for
   <draft-ietf-dnsop-respsize-14.txt>

3) [Peter] Issue WGLC for <draft-ietf-dnsop-dnssec-key-timing-03.txt>

4) [Chairs] Frame discussion around the child/parent interaction on
   mailing list

5) [Chairs] Stipulate discussion on the issue of stats collection
   (problem vs MIB or other solution)


(Version: 2012-08-09 09:23)