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

[Paul Wouters <[e-mail]>]

On Mon, 5 Mar 2018, Peter van Dijk wrote:

> Please find below revision 04 of the XPF draft. We believe all concerns 
> previously raised have been addressed in this version.

> We’d like to ask the WG to consider adoption. Ray and myself will be present 
> at IETF101 if you want to discuss.

>> Htmlized:        https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04

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

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 ?


    Servers MUST NOT send this RR in DNS responses.

Can this be extended to include "not forward these packets" as well?

Setion 3.4:

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

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?

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


    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.

Section 3.6:

This could use an example.

Section 4:

It could mention DNS-COOKIES as one way to avoid spoofing issues.

Paul