Skip to main content

Last Call Review of draft-ietf-dnssd-hybrid-07
review-ietf-dnssd-hybrid-07-secdir-lc-harkins-2017-10-19-00

Request Review of draft-ietf-dnssd-hybrid
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-10-12
Requested 2017-09-28
Authors Stuart Cheshire
I-D last updated 2017-10-19
Completed reviews Iotdir Last Call review of -07 by Ralph Droms (diff)
Opsdir Last Call review of -07 by Joel Jaeggli (diff)
Genart Last Call review of -07 by Joel M. Halpern (diff)
Secdir Last Call review of -07 by Dan Harkins (diff)
Assignment Reviewer Dan Harkins
State Completed
Request Last Call review on draft-ietf-dnssd-hybrid by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has nits
Completed 2017-10-19
review-ietf-dnssd-hybrid-07-secdir-lc-harkins-2017-10-19-00
   Greetings,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   This draft describes a new type of proxy that uses multicast DNS
to discover multicast DNS records on local links and then makes
corresponding DNS records visible in the unicast DNS namespace.

   This is a very well written draft and is easy to read and understand.
I believe it is "Ready with nit". My nit is this:

   I understand that there is a general problem with restricting certain
DNS records but this draft seems to exacerbate that problem. The draft's
privacy considerations do discuss the case where a "Multicast Service
Discovery Proxy" makes records for transient devices from the local link
available to, theoretically, the global public DNS database and thereby
advertises the presence or absence of a laptop (and more importantly it's
owner from a house). This is a serious issue and I think the draft should
address it instead of punting the problem to "firewalls, split-view DNS,
and Virtual Private Networks". Due to my general DNS ignorance I am unable
to suggest a workable solution but there should be a way to instruct the
proxy to suppress certain records (perhaps encode something in the QNAME,
I don't know). I just think this draft creates a serious problem out of a
protocol limitation and it should provide some way to address it.

   regards,

   Dan.