Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.
The document describes the issues associated with the practice of
whitelisting in DNS servers, in an attempt to limit which recursive
resolvers receive responses to requests for AAAA (IPv6) records.
The practice of whitelisting can have significant impact on transport
protocols in the reachability of IPv6 endpoints. There are no transport
issues of a more specific nature discussed or determined as part of this
review.
I do have some other concerns which are noted below, and which are
offered for consideration.
I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.
Joe
---------------------------------------------------------------------
Overall, this document is quite long and has many gratuitous digressions
which could easily be omitted. It is unnecessarily verbose and lengthy
for its topic. E.g., the architectural implications that stretch this
issue into network heterogeneity are a bit of a stretch, and the
discussion (and citation) for Newton's notion of momentum is unnecessary.
Blacklisting is noted in other environments in Sec 6, and noted as an
alternative for the DNS AAAA issue in a cursory fashion in Sec 7.3.7. It
should certainly be introduced and defined earlier, and included in the
alternatives discussed in Sec 8. Blacklisting provides a useful
alternative because it requires explicit action to inhibit, rather than
requiring explicit action to avoid, and the tradeoff between
blacklisting and whitelisting should be discussed in more detail.
The list of alternate solutions (Sec 8) might be placed much earlier
(Sec 2, after an intro), as it provides the background for the rest of
the discussion.
The document might also benefit from a brief discussion of how users are
rarely in control of their DNS, given hijacking that currently occurs in
ISPs. I.e., even when they could use a whitelisted recursive resolver,
that might be impossible due to current ISP practices.
Sec 6.2 notes that deployment of whitelisting might require an Internet
Draft; this should be replaced with "RFC" (presumably standards track or
BCP).
-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf