Initializing a DNS Resolver with Priming Queries
draft-ietf-dnsop-resolver-priming-11
Yes
(Joel Jaeggli)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 09 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -09)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-11-29 for -09)
Unknown
In section 3.1, is there a reason the requirement in paragraph 2 does not get a 2119 keywords, when the requirement in the first paragraph does? They seem similar in impact.
Benoît Claise Former IESG member
No Objection
No Objection
(for -09)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-11-30 for -09)
Unknown
I support Stephen's comments.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -09)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-11-30 for -09)
Unknown
I find myself curious about both SHOULDs in Resolver software SHOULD treat the response to the priming query as a normal DNS response, just as it would use any other data fed to its cache. Resolver software SHOULD NOT expect exactly 13 NS RRs. Do you think these SHOULDs (especially the first one) are required for interoperation? I'm wondering (1) why they aren't MUSTs, and (2) why RFC 2119 language is actually needed at all. If they are RFC 2119 SHOULDs, what happens if the resolver software violates them?
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-11-30 for -09)
Unknown
- intro: References for directions that fail "disastrously" would be good, if only to decrease the chances that other implementers choose known-bad approaches. - section 5, 2nd para: such an attacker can also see what queries are being emitted by the resolver, and, in the absence of qname minimisation, that can be quite privacy sensitive. I think it'd be well worth noting that with a reference to RFC7816 as a possible mitigation.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -09)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(2016-11-30 for -09)
Unknown
Thank you for producing a well written artefact. I also support Stephen's request to identify the scenarios in which "Some implementers have chosen other directions, some of which work well and others of which fail (sometimes disastrously) under different conditions." An appendix would be fine IMHO. Given you raise some (awareness) issues in the security consideration section, if an administrator implements RFC7706 would that alter any of those concerns? (admittedly, potentially buying others that are well documented in 7706)