Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

CHAIN Query Requests in DNS
RFC 7901

Yes

(Alissa Cooper)

(Ben Campbell)

(Brian Haberman)

(Joel Jaeggli)

(Stephen Farrell)

No Objection

(Alvaro Retana)

(Barry Leiba)

(Benoît Claise)

(Deborah Brungard)

(Jari Arkko)

(Martin Stiemerling)

(Spencer Dawkins)

(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Alissa Cooper Former IESG member

Yes

Yes (for -06) Unknown

Ben Campbell Former IESG member

Yes

Yes (for -06) Unknown

Brian Haberman Former IESG member

Yes

Yes (2016-02-15 for -06) Unknown

Modulo the missing privacy issues in section 8, I support the publication of this document and the resulting experimentation to reduce the latency of DNSSEC validation.

Joel Jaeggli Former IESG member

Yes

Yes (for -06) Unknown

Stephen Farrell Former IESG member

Yes

Yes (2016-02-15 for -06) Unknown


- In section 3 you promised me privacy considerations in section
8 but I didn't find any there. That was almost a DISCUSS, but
since fixing it is easy and I assume won't be controversial I
can stick with a YES ballot:-)

- I would suggest that you do note in section 8, that the fqdn
in the CHAIN option could allow an attacker to (re-)identify a
client. E.g. if the attacker sees that you have validated
tetbed.ie before that could single you out, even if you have
changed your n/w, cilent IP address etc. Presumably that would
be a relatively long lasting concern as well, as RRSIG expiry
tends to be weeks ahead. I think just noting that and maybe
saying that DPRIVE is a likely mitigation would be a good thing
to do.

Alvaro Retana Former IESG member

No Objection

No Objection (2016-02-16 for -06) Unknown

The Intended Status on the document itself says "Standards Track" (and not Experimental).  It should be changed before approval.

Barry Leiba Former IESG member

No Objection

No Objection (2016-02-17 for -06) Unknown

-- Section 6.3 --

   It is RECOMMENDED that TCP sessions not immediately be closed after
   the DNS answer to the first query is received.  It is recommended to
   use [TCP-KEEPALIVE].

A very tiny point: it strikes me that the 2119-level "RECOMMENDED" is on the wrong half of this -- I think the 2119-level recommendation should be on the TCP-KEEPALIVE part.  I'd word it this way, but you can certainly ignore this if you prefer, and no response is necessary:

NEW
   The use of [TCP-KEEPALIVE] on DNS TCP sessions is RECOMMENDED, and   
   thus TCP sessions should not immediately be closed after the DNS
   answer to the first query is received.
END

Benoît Claise Former IESG member

No Objection