Subject: [DNSOP] Agenda and Slides upload

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Nov 2015 05:25:52 +0900

I've uploaded a final final agenda and all the slides.  We had to move 
the 6761 Discussion earlier in the meeting to deal with a conflict Ralph 
has.  It's going to still have a 30 minute hard limit.

tim

---------

WG:                     DNS Operations (dnsop)
Meeting:                IETF 94, Yokohama
Location:               Pacifico Yokohama
Date:                   5 November 2015
Time:                   09:00-11:30, Room 304
Chairs:                 Tim Wicinski <[email-masked]>
                         Suzanne Woolf <[email-masked]>

- Agenda Bashing, Blue Sheets, etc, 10 min

- Working Group Document Update, Chairs, 15 min

- Old Working Group Business
     draft-ietf-dnsop-dnssec-roadblock-avoidance,  10 min
         Action: 3 possible

     draft-jabley-dnsop-refuse-any, Olafur(remote), 10 min

- 6761 Discussion, 30 min

- New Working Group Business

     draft-jabley-dnsop-ordered-answers, Sullivan, 10 min
         Actions:
             a) if this document needs more work adopt
             b) go away this is a bad idea

     draft-ogud-dnsop-maintain-ds,  Wouters, 10 min

     draft-muks-dnsop-dns-message-checksums, Sivaraman, 10 min

     draft-muks-dns-message-fragments, Kerr, 10 min

     draft-wessels-edns-key-tag, Wessels, 10 min

- New New Working Group Business
     DNAME in the Root?
     NXDOMAIN means NXDOMAIN  Bortzmeyer, 10 min

     draft-spacek-dnsop-update-clarif, Spacek

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Nov 2015 21:53:08 +0000

>     draft-spacek-dnsop-update-clarif, Spacek

Note that my 2317bis draft has a slightly different take on UPDATE vs
classless reverse DNS. The UPDATE section of my draft is entirely due to
Petr's draft, so I'm very grateful to him for pointing out the problem.
I'm interested in opinions about

- should this be a separate draft or is it sensible to put it in rfc2317bis?

- is the indirection problem specific to classless reverse DNS (which is
  the approach I took) or does it apply everywhere (which is what
  Petr Spacek's draft says)?

- is my detailed suggested UPDATE behaviour sensible?

https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Westerly or southwesterly 5 or 6, decreasing 4, then increasing 5
to 7 in northwest. Moderate or rough. Thundery showers. Good, occasionally
poor.

---

From: Petr Spacek <[email-masked]>
Date: Thu, 5 Nov 2015 04:19:08 +0100

>>     draft-spacek-dnsop-update-clarif, Spacek

Grrr, dnsop session ended right on time and Paul Wouters did not get necessary
30 seconds to present this draft to the WG.

> - should this be a separate draft or is it sensible to put it in rfc2317bis?

It could be combined with rfc2317bis because there is very tight relation
between these two. However spacek-update-clarif is more generic and IMHO we
should extend rfc2317bis to incorporate the generic-ness before dropping
spacek-update-clarif.

>   Petr Spacek's draft says)?

Personally I do not see why it should be specific to ARPA sub-tree ...
Conceptually it is the question if client wants to update RR at the terminal
node or on the node client can name beforehand ("reverse DNS query name" is
one example of a name known beforehand).

Thinking about it a bit more ... I can see that RFC2317bis should make
canonicalization mandatory for reverse sub-trees and all other cases should be
left to the implementation to decide. Let's see if we can do it in one document.

> https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9

Most importantly, I believe that limiting the new behavior ("canonicalize
first") to PTR RR type is a bad idea. We have DHCID, EUI48, EUI64 and people
are certainly using other RR types in the reverse sub-trees too (TXT comes to
mind...).

Even if we decide in the end to mandate the new behavior to ARPA sub-tree we
surely should not limit ourselves to PTR.

I would remove limitation to PTR and add a paragraph about sub-trees other
than IN-ADDR.ARPA and IP6.ARPA. For a while I was considering adding a
limitation to "*not* CNAME/DNAME", but IMHO your sentence "these requirements
do not apply if you are using DNS UPDATE to deploy classless IN-ADDR.ARPA or
IP6.ARPA delegations" is better.

I'm proposing to use following text (few nitpicks included):

"""
9.  Dynamic DNS UPDATE for reverse DNS sub-tree

   This section updates the DNS UPDATE specification [RFC2136].  It
   specifies additional requirements for DNS UPDATE clients, so they can
   dynamically change DNS records in reverse sub-tree in a way that is
   compatible with the techniques described in the previous sections.
   It applies both to the IPv4 reverse DNS under IN-ADDR.ARPA and
   the IPv6 reverse DNS under IP6.ARPA.

   These additional requirements only apply to DNS UPDATE clients that
   wish to add, remove, or change records in the reverse DNS sub-tree.
   Exception is that these requirements do not apply if you are using DNS
   UPDATE to deploy classless IN-ADDR.ARPA or IP6.ARPA delegations.
   No new requirements affect other uses of DNS UPDATE, i.e. uses outside
   of IN-ADDR.ARPA or IP6.ARPA sub-trees.

   In this section, we use the term "reverse DNS query name" to mean a
   name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making
   a reverse DNS query.  The resolver expects this name to resolve to a
   PTR or related RRsets, but (as described in previous sections)
   it does not have to be the direct owner of the RRsets but can instead
   be an alias.

   The problem addressed by this section is that DNS UPDATE clients
   sometimes use a reverse DNS query name in an UPDATE message without
   checking for CNAME or DNAME redirections.  If the usual reverse DNS
   query name is an alias, then this behavior results in an attempt to
   add or delete a record to or from a node that already contains
   the CNAME record, and the update fails.

   Aside:  Presumably the UPDATE will also fail if the node is occluded
      below a DNAME record, but neither [RFC2136] nor [RFC6672]
      specifies how a server out to react to attempts to UPDATE an
      occluded domain name.

   Please note that this problem is generic. For names outside of
   IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation
   to decide if it is necessary to update aliases itself or if it is
   necessary to update RRsets at terminal node of alias chain and thus
   method described in the section 9.2 needs to be applied.

9.1.  Requirements for updating records in the reverse DNS

   When updating a record in the reverse DNS sub-tree, an UPDATE client
   SHOULD NOT simply convert the IP address to a reverse DNS query name
   and send an UPDATE request for RRsets at that name.  It MUST
   NOT assume the zone cut falls on a particular boundary such as /24
   for IPv4 or /64 for IPv6.
"""

Additionally, Security Considerations section does not mention risks mentioned in
https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01#section-6

It would be nice to copy&paste/incorporate the text from there. These risks
should be explicitly mentioned.

Now it is ~ 4 AM here so I wish the text above makes sense :-) I will read the
procedure in section 9.2 carefully again this week, but it seems okay at a
first glance. (For generalization proposed above we would have to drop "PTR"
from the very last bullet in 9.2. Suggested behaviour but that is it.)

I believe that we can drop draft-spacek-dnsop-update-clarif in favor of
rfc2317bis if concerns above can be resolved.

Have a nice day!

-- 
Petr Spacek

---

From: Tony Finch <[email-masked]>
Date: Thu, 5 Nov 2015 11:08:07 +0000

Petr Spacek <[email-masked]> wrote:

Thanks for your thoughts!

> one example of a name known beforehand).

Right. I was partly reacting to Mark's comments
(http://www.ietf.org/mail-archive/web/dnsop/current/msg15333.html)
and I probably went too far in being specific rather than generic, sort of
deliberately to give us a concrete alternative to think about.

> left to the implementation to decide. Let's see if we can do it in one document.

Good idea, yes.

> surely should not limit ourselves to PTR.

Absolutely, very good point.

> I'm proposing to use following text (few nitpicks included):

Thanks, I'll incorporate those suggestions.

I'm trying to think of a good term for PTR-like records, or
non-delegation-non-alias records, because I would like to be
reasonably specific about what this does and doea not apply to.

> should be explicitly mentioned.

Yes.

> rfc2317bis if concerns above can be resolved.

Groovy :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Dogger, Fisher, German Bight, Humber: Southerly or southwesterly 4 or 5,
increasing 6 at times. Slight or moderate. Rain or showers, fog patches.
Moderate or good, occasionally very poor.

---

From: Bob Harold <[email-masked]>
Date: Fri, 6 Nov 2015 10:45:07 -0500

On Wed, Nov 4, 2015 at 4:53 PM, Tony Finch <[email-masked]> wrote:

> The UPDATE behavior makes sense to me.

minor nit - The first paragraph in section 9 has "change revers DNS" which
should be "change reverse DNS"

-- 
Bob Harold