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

[Eric Ziegast]

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

I'm not an implementor, but I did read it and have feedback...

1. Precedence....  Y'all say:

     Name Length

     Among applicable QNAME or NSDNAME policies within a DNS RPZ,
     choose the policy that matches the smallest name.

   I might introduce this
     "more-specific names have preference over less-specific names",
   or related just to wildcards....
     "specific matches have preference over a wildcard match".

   Eg: I might want to pass-through TCL.TK and *.TCL.TK,
       but still point *.TK through a walled garden.


2. I don't understand what "qname-wait-recurse" in the
   Security Considerations section is.  Is that a specific
   option/implementation in BIND?  Does that sentence need
   need rephrasing?

3. Forwarders....  Y'all state:

      RPZ merely formalizes and facilitates modifying DNS data on
      its way from DNS authority servers to clients.

   I think this might need some elaboration.  In it's simplest
   form, RPZ is a technology utilized on a recursive server to
   modify answers sent to its clients.  The communication path
   between the recursive server and authoritative servers is
   assumed to be clear.

   What if a recursive nameserver is a client of another
   recursive server?  If the recursive server is a forwarder
   to another recursive server, can it modify responses?
   What if the upstream recursive server also uses RPZ and
   modifies answers?  This could get pretty confusing for
   debugging.  Having an SOA record in the authority section
   available might help, but I'd like to see a discussion about
   practical implementation including forwarders.


4. DNSSEC vs RPZ....  I see:

     By default, policies are applied only on DNS requests that ask for
     recursion (RD=1) and which either do not request DNSSEC metadata
     (DO=0) or for which no DNSSEC metadata exists.

   I wonder if there might be a specific policy option or software
   option for overriding this behavior.  For example, if the a-holes
   serving malware via GMAI <dot> COM signs their domain in DNSSEC,
   an RPZ-enabled nameserver can't avoid it, right?


--
Eric Ziegast