Subject: Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 24 Jul 2013 19:03:21 -0700

At Mon, 24 Jun 2013 15:32:45 -0400,
Joe Abley <[email-masked]> wrote:

> I just exhumed the below-mentioned draft and recruited a co-author, since it seems like a timely topic for discussion.
> 
> This draft proposes a mechanism whereby an authority-server operator can signal to one or more recursive servers that the recursive server should flush a section of its cache. It's an in-band mechanism using TSIG-secured NOTIFY.

I have a few comments on the draft:

- A meta level comment: this proposal seems to me to be a protocol
  extension, and couldn't normally be handled in places like dnsop.
  I'm not an IETF procedure police, though, so if others think it's
  okay and should be able to convince the police (aka IESG), that's
  fine to me.

- despite the explicit terminology section, there is a mixture
  of "Authoritative" (server) and "Authority" (server).  "Resolver"
  (without the word "stub") and "Recursive Server" also seem to be
  mixed.

- the draft mentions UPDATE in several places, such as in Section 2:

   This document defines no new protocol elements and makes no changes
   to the existing specification for DNS UPDATE.  Rather, this document

  shouldn't these be NOTIFY?  If they are really UPDATE, I'm afraid
  the draft should explain more about how to use UPDATE...

- The use case described in Section 3.2 doesn't seem to be realistic
  (or I don't understand it correctly).  (Unlike the example of 3.1)
  it seems that the expected recursive servers are arbitrary ones, but
  that won't scale as the NOTIFY should be secured with TSIG.  If the
  intent is to do it for some limited set of recursive servers, I
  think the draft should explicitly say so, with what are such
  expected servers.

--
JINMEI, Tatuya
Infoblox Inc.

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Jul 2013 12:35:03 -0400

Hi Jinmei,

Many thanks for the review.

>  okay and should be able to convince the police (aka IESG), that's

I agree this is a shaky line that we're walking.

>  (without the word "stub") and "Recursive Server" also seem to be

I will fix that.

>  the draft should explain more about how to use UPDATE...

It should be NOTIFY. I must have been having a particularly weird day when I wrote that.

>  think the draft should explicitly say so, with what are such

The observed phenomenon that I think is worth improving upon is that whereby every now and then the operator of some important zone (a TLD, a web property that is particularly important to end users, etc) has a bad problem, finds that they will not go into space today, and then spends two days sending increasingly desperate mail to operations lists asking people to flush their caches. This manual process is ad-hoc and unreliable.

The goal was to define a convention (mechanism, whatever) that would allow an authoritative server operator to make arrangements with particular recursive server operators to allow caches to be automatically flushed in the event that the authoritative server operator has such a bad problem.

The convention would also enable a mediation layer, where (for example) DNS Facilitators, Inc. could build relationships with recursive server operators and authoritative server operators and could funnel the authenticated directions to flush appropriately.

I will review the text again and see if I can make this clearer.

Joe