Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.txt

Ray Bellis <> Thu, 15 March 2018 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40EC912D942 for <>; Thu, 15 Mar 2018 03:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fThCLewmoVbb for <>; Thu, 15 Mar 2018 03:01:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BD25126BF7 for <>; Thu, 15 Mar 2018 03:01:01 -0700 (PDT)
Received: from [] (port=59373 helo=rays-mbp.local) by ([]:465) with esmtpsa ( (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1ewPgx-0003DA-UF (Exim 4.72) for (return-path <>); Thu, 15 Mar 2018 10:00:59 +0000
References: <> <> <>
From: Ray Bellis <>
Message-ID: <>
Date: Thu, 15 Mar 2018 10:01:00 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Mar 2018 10:01:05 -0000

On 14/03/2018 22:07, Paul Wouters wrote:

> While I was initially afraid of abuse of this feature, the document has
> addressed this issue very well. So as long as implementors follow the
> specification, I think this document poses no privacy risk.
> I'm in favour of adoption.
> Some nits:
> Section 3.1:
>    Stub resolvers, client-side proxy devices, and recursive resolvers
>    MUST NOT add the XPF RR to DNS requests.
> Can this be extended to say what these should do when receiving or
> forwarding these?g

I think it would suffice to replace "client proxy devices" with "client
side proxies or forwarders".

> Section 3.2:
>    If a server finds this RR anywhere other than in the Additional
>    Section of a request it MUST return a REFUSED response.
>    If the value of the RR's IP version field is not understood by the
>    server it MUST return a REFUSED response.
> Why return REFUSED instead of FORMERR for these ?

That's fair, those are arguably "illegal packets" rather than "policy

There's perhaps also an omission here w.r.t the "Protocol" field which
is not mentioned in this context.

>    Servers MUST NOT send this RR in DNS responses.
> Can this be extended to include "not forward these packets" as well?

I don't think that fits here.   If the server is being used as a
front-end forwarder for a server farm than adding XPF would be appropriate.

> Setion 3.4:
> Why SHOULD and not MUST? Can you give an example of when the SHOULD can
> be ignored?

When the server doesn't implement XPF?  I think this wording was there
to prevent a charge of imposing retrospective mandates.

We could perhaps change that to say that "an XPF-capable server MUST ..."

> Section 3.5:
>    The XPF RR is formatted like any standard RR, but none of the fields
>    except RDLENGTH and RDATA have any meaning in this specification.
> If these fields don't matter, can we mandate a setting for these? I
> guess we can because you do :) So maybe this text can be omitted or
> changed to reflect that?

OK, will look at that.

> My petpeeve: using +---+---+---+---+---+---+---+ instead of
> +---------+-----------+
> I find the overuse of +-+-+ reduces readability.

That's one for the WG, I think, on adoption.  With sub-octet fields
present it makes the size of those fields completely explicit.

I also personally find it much more legible than the 32-bits per line
using '+-+-...' that e.g. RFC 791 (IP) uses.

It may be hard to reach consensus :p

>    Implementations MUST support IPv4 (4) and IPv6 (6).
> I would not say this. In the happy future where we are mostly/only v6,
> we wouldn't want to issue an update to this RFC just to kill this sentence.

I appreciate the sentiment, but I think it highly unlikely that the
original IPv4 specification will ever be rendered completely historic.

If that does ever happen, the RFC that does it can just update this one
without requiring a -bis.

> Section 3.6:
> This could use an example.


> Section 4:
> It could mention DNS-COOKIES as one way to avoid spoofing issues.

That sounds like a good idea.

thanks for the review!