[DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt

[Anne Bennett]

>> vernon and i would appreciate feedback from close reading by operators 
>> and implementers of rpz-as-it-exists-today. 

>> Htmlized:       https://tools.ietf.org/html/draft-vixie-dns-rpz-00

> So far, clear and well written!  I'll continue reading at section 6
> tomorrow...

Just more very minor nits:

6.  Producer Behavior

  "(DNS NOTIFY [RFC1996]"
    missing close parenthesis

  "each such server must be explicitly denoted in the master
  server's configuration"
    I'd suggest:
  "each such server must be explicitly listed in the master
  server's configuration as necessary to allow zone transfers
  from the stealth slave, as well to ensure that zone change
  notifications are sent to it"

  "Because DNS NOTIFY is a lazy protocol, it may be necessary
  to explicitly trigger the master server's "notify" logic
  after each update to the DNS RPZ."

    I'm puzzled, perhaps because I'm familiar with only ISC bind.
    Do the other nameservers not notify promptly on changes?


7.  History and Evolution

  "A more up to date description was in chapter 6"
    I'd suggest:
  "A more up to date description appeared in chapter 6 [...]
  as of YEAR"

  "The initial implementation and first patch adding it to
  BIND was written"
    *were* written

  "from FTP servers at redbarn.org and rhyolite.com 2010"
    starting in 2010?

  "required continuing support of the original encodings"
    perhaps better as:
  "required continuing to support the original encodings"
    or:
  "required continued support of the original encodings"

  "psuedo-TLDs"
    typo:
  "pseudo-TLDs"

  "and so that was the encoding for the NXDOMAIN action"
    I'd suggest:
  "and so that became the encoding for the NXDOMAIN action"

9.  Security Considerations

  "vulnerabilites"
    should be:
  "vulnerabilities"

    but I think that the whole sentence could be better expressed:
  "Nevertheless, RPZ does not exacerbate the existing
   vulnerability of recursive servers to falsified DNS data."

  "Moreover, DNSSEC (see RFC 4033 [RFC4033] and RFC 4034
  [RFC4034]) prevents changes to DNS data by RPZ."
    could then become:
  "However, the use of DNSSEC (see RFC 4033 [RFC4033] and
  RFC 4034 [RFC4034]) prevents such changes to DNS data by RPZ."

  "By default, DNS resolvers"
    ->
  "Therefore, by default, DNS resolvers"

  "When the common"
    ->
  "However, when the common"

  "RPZ using resolvers"
    ->
  "RPZ-using resolvers"

  "... ignore DNSSEC.  The result of "BREAK-DNSSEC" at DNS
  clients using DNSSEC is functionally similar to an RPZ
  NXDOMAIN policy action;"

    I'm not at all sure I understand the above sentence
    correctly, but if I do, then I suggest:

  "... ignore DNSSEC for RPZ-modified queries even if otherwise
  configured to use DNSSEC; thus, the result of such a configuration
  is functionally similar to an RPZ NXDOMAIN policy action:"

    ... and if I don't understand correctly, perhaps some other
    clarification would be in order?

Appendix A.  Examples

  The HTML-ized version incorrectly (I think) further indents
  lines starting with "; do not rewrite OK.DOMAIN.COM (so, PASSTHRU)".


Whew!  Well done, folks, it's nice to see RPZ being documented
more formally.



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285