From paul at redbarn.org Tue Oct 11 18:54:54 2016 From: paul at redbarn.org (Paul Vixie) Date: Tue, 11 Oct 2016 11:54:54 -0700 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> Message-ID: <57FD357E.3070507@redbarn.org> this is an attempt to document the rpz system as it exists today. it specifies nothing new, since adding more new stuff ought to wait until there is an agreement on the starting conditions. vernon and i would appreciate feedback from close reading by operators and implementers of rpz-as-it-exists-today. either here, or on the ietf DNS related mailing list shown below. thanks! paul -------------- next part -------------- An embedded message was scrubbed... From: internet-drafts at ietf.org Subject: New Version Notification for draft-vixie-dns-rpz-00.txt Date: Tue, 11 Oct 2016 11:43:34 -0700 Size: 2434 URL: From anne at encs.concordia.ca Tue Oct 11 21:36:03 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Tue, 11 Oct 2016 17:36:03 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: Your message of Tue, 11 Oct 2016 11:54:54 PDT References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> Message-ID: <6777.1476221763@vindemiatrix.encs.concordia.ca> > 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 2. Zone Format "can be transferred between servers DNS" should be "can be transferred between DNS servers" 4. Policy Triggers "and answer truthfull requests from a client at 2001:2::3" should be "and give truthful answers to requests from a client at 2001:2::3" "use whatever NS RRsets that are in their caches" should be "use whatever NS RRsets are in their caches" or "use the NS RRsets that are in their caches" "all of the IP address for all the named servers" should be "all of the IP addresses for all the named servers" "use whatever A or AAAA RRsets that are in their caches" should be "use whatever A or AAAA RRsets are in their caches" or "use the A or AAAA RRsets that are in their caches" "imaginitive" should be "imaginative" 5. Subscriber Behavior "They can only be searched in a recursive server's own storage" should be "They can be searched only in a recursive server's own storage" "By default, policies are applied only [...] for which no DNSSEC metadata exists." add: "This default can be overridden; see section 9 below." I don't understand what you mean by "smallest name" and "smallest IP address". Perhaps an example would help? So far, clear and well written! I'll continue reading at section 6 tomorrow... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285 From ziegast at fsi.io Tue Oct 11 22:44:10 2016 From: ziegast at fsi.io (Eric Ziegast) Date: Tue, 11 Oct 2016 15:44:10 -0700 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <57FD357E.3070507@redbarn.org> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> Message-ID: <57FD6B3A.5050809@fsi.io> 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 COM signs their domain in DNSSEC, an RPZ-enabled nameserver can't avoid it, right? -- Eric Ziegast From nudgemac at fastmail.fm Wed Oct 12 10:55:18 2016 From: nudgemac at fastmail.fm (=?utf-8?Q?=E2=86=AA=EF=B8=8E=F0=9F=9A=80nudge?=) Date: Wed, 12 Oct 2016 12:55:18 +0200 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <57FD357E.3070507@redbarn.org> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> Message-ID: <1476269718.124422.753463321.36DEED1C@webmail.messagingengine.com> Hello Paul, I'd still like to have the ability to tell TTL lies. Maybe a Time To Die TTD option could be added ? thanks Ian On Tue, 11 Oct 2016, at 20:54, Paul Vixie wrote: > this is an attempt to document the rpz system as it exists today. it > specifies nothing new, since adding more new stuff ought to wait until > there is an agreement on the starting conditions. > > vernon and i would appreciate feedback from close reading by operators > and implementers of rpz-as-it-exists-today. either here, or on > the ietf > DNS related mailing list shown below. > > thanks! > > paul > _________________________________________________ > DNSfirewalls mailing list > DNSfirewalls at lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/dnsfirewalls > Email had 1 attachment: > * New Version Notification for draft-vixie-dns-rpz-00.txt.eml 2k > (message/rfc822) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ray at isc.org Wed Oct 12 11:05:50 2016 From: ray at isc.org (Ray Bellis) Date: Wed, 12 Oct 2016 12:05:50 +0100 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <57FD357E.3070507@redbarn.org> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> Message-ID: <31453102-4279-7834-55be-d1d52657140b@isc.org> On 11/10/2016 19:54, Paul Vixie wrote: > vernon and i would appreciate feedback from close reading by operators > and implementers of rpz-as-it-exists-today. either here, or on the ietf > DNS related mailing list shown below. As previously discussed off-list, we think there's a use case for providing pass-thru / override on a per-RR basis. At the moment if there's a record for a particular RRtype in RPZ then this overrides the real answer, but you then get NODATA for the RRtypes that don't exist in the RPZ zone. Whilst this could potentially be achieved by having the DNS server support falling-through to a second RPZ zone if the first RPZ lookup results in a NODATA response, we'd rather see a standardised RR-based method to achieve this within a singe RPZ. Ray From paul at redbarn.org Wed Oct 12 12:36:17 2016 From: paul at redbarn.org (Paul Vixie) Date: Wed, 12 Oct 2016 05:36:17 -0700 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <1476269718.124422.753463321.36DEED1C@webmail.messagingengine.com> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> <1476269718.124422.753463321.36DEED1C@webmail.messagingengine.com> Message-ID: <57FE2E41.90406@redbarn.org> ???nudge wrote: > Hello Paul, > > I'd still like to have the ability to tell TTL lies. Maybe a Time To Die > TTD option could be added ? > > thanks > > Ian we're in feature freeze while we document what's in the field today. the time will come when discussion of new features will be welcomed. right now the ask is, please look at the draft document, and tell us what we said wrong, didn't say, or shouldn't've said. -- P Vixie From paul at redbarn.org Wed Oct 12 12:38:16 2016 From: paul at redbarn.org (Paul Vixie) Date: Wed, 12 Oct 2016 05:38:16 -0700 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <31453102-4279-7834-55be-d1d52657140b@isc.org> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> <31453102-4279-7834-55be-d1d52657140b@isc.org> Message-ID: <57FE2EB8.7080005@redbarn.org> Ray Bellis wrote: > On 11/10/2016 19:54, Paul Vixie wrote: > >> vernon and i would appreciate feedback from close reading by operators >> and implementers of rpz-as-it-exists-today. either here, or on the ietf >> DNS related mailing list shown below. > > As previously discussed off-list, we think there's a use case for > providing pass-thru / override on a per-RR basis. and i agree, as i did off-list, that this sound useful. however, we'd like to get the existing spec clean and clear so we have something to build upon. > > At the moment if there's a record for a particular RRtype in RPZ then > this overrides the real answer, but you then get NODATA for the RRtypes > that don't exist in the RPZ zone. > > Whilst this could potentially be achieved by having the DNS server > support falling-through to a second RPZ zone if the first RPZ lookup > results in a NODATA response, we'd rather see a standardised RR-based > method to achieve this within a singe RPZ. yes, agreed. -- P Vixie From ray at isc.org Wed Oct 12 12:38:55 2016 From: ray at isc.org (Ray Bellis) Date: Wed, 12 Oct 2016 13:38:55 +0100 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <57FE2EB8.7080005@redbarn.org> References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> <31453102-4279-7834-55be-d1d52657140b@isc.org> <57FE2EB8.7080005@redbarn.org> Message-ID: On 12/10/2016 13:38, Paul Vixie wrote: > and i agree, as i did off-list, that this sound useful. however, we'd > like to get the existing spec clean and clear so we have something to > build upon. Understood :) Ray From anne at encs.concordia.ca Wed Oct 12 21:05:15 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Wed, 12 Oct 2016 17:05:15 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: Your message of Tue, 11 Oct 2016 17:36:03 EDT References: <147621141428.31971.49025872322484428.idtracker@ietfa.amsl.com> <57FD357E.3070507@redbarn.org> <6777.1476221763@vindemiatrix.encs.concordia.ca> Message-ID: <16611.1476306315@vindemiatrix.encs.concordia.ca> >> 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 From vjs at rhyolite.com Wed Oct 12 21:18:19 2016 From: vjs at rhyolite.com (Vernon Schryver) Date: Wed, 12 Oct 2016 21:18:19 GMT Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <16611.1476306315@vindemiatrix.encs.concordia.ca> Message-ID: <201610122118.u9CLIJ7l073294@calcite.rhyolite.com> > To: dnsfirewalls at lists.redbarn.org > From: Anne Bennett > Just more very minor nits: thanks! I think they are not merely minor. > "... 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? The idea is that any changes by anything including RPZ break DNSSEC verification. Connecting to web page using an A RRset that has DNSSEC records but that has been modified by RPZ seems likely to result in the browser showing something like "could not resolve www.example.com; try again?" Do you have a suggestion a better way to say that? > The HTML-ized version incorrectly (I think) further indents > lines starting with "; do not rewrite OK.DOMAIN.COM (so, PASSTHRU)". Unless there is something I could do in the XML source, I think that's an issue for maintainers of xml2rfc. thanks again, Vernon Schryver vjs at rhyolite.com From anne at encs.concordia.ca Thu Oct 13 01:28:33 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Wed, 12 Oct 2016 21:28:33 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: Your message of Wed, 12 Oct 2016 21:18:19 GMT References: <201610122118.u9CLIJ7l073294@calcite.rhyolite.com> Message-ID: <24688.1476322113@vindemiatrix.encs.concordia.ca> Vernon, >> "... 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? > > The idea is that any changes by anything including RPZ break DNSSEC > verification. Connecting to web page using an A RRset that has DNSSEC > records but that has been modified by RPZ seems likely to result in > the browser showing something like > "could not resolve www.example.com; try again?" > > Do you have a suggestion a better way to say that? Possibly not without exposing to the world my woefully inadequate understanding of DNSSEC. :-/ My understanding from the document was that RPZ is usually implemented by the recursive resolver, so if that name server is also configured to "BREAK-DNSSEC", it would return a modified RRset regardless of the fact that this result would not match the DNSSEC signature. I had assumed that the querying client was *not* the entity doing DNSSEC validation, and that this client would therefore meekly accept the modified result sent by the resolving nameserver. Am I mistaken? Does the querying client receive the result RRset *and* the DNSSEC signature, and *itself* check the validity? If so, then perhaps: Therefore, by default, DNS resolvers using RPZ avoid modifying DNS results when DNSSEC signatures are available and are requested by the DNS client. However, when the common "BREAK-DNSSEC" configuration setting is used, RPZ-using resolvers do modify query results, even when this renders them DNSSEC-invalid. In such a case, a querying client which checks DNSSEC will ignore the invalid result, and will effectively be blocked from malefactor domains; this behaviour is functionally similar to that caused by an RPZ NXDOMAIN policy action. There may be a less wordy way to say it, but if I've understood correctly this time, perhaps that's more clear? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285 From vjs at rhyolite.com Thu Oct 13 04:26:05 2016 From: vjs at rhyolite.com (Vernon Schryver) Date: Thu, 13 Oct 2016 04:26:05 GMT Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt In-Reply-To: <24688.1476322113@vindemiatrix.encs.concordia.ca> Message-ID: <201610130426.u9D4Q55u024352@calcite.rhyolite.com> > To: Vernon Schryver > cc: dnsfirewalls at lists.redbarn.org > From: Anne Bennett > My understanding from the document was that RPZ is usually > implemented by the recursive resolver, so if that name server is > also configured to "BREAK-DNSSEC", it would return a modified > RRset regardless of the fact that this result would not match > the DNSSEC signature. I had assumed that the querying client > was *not* the entity doing DNSSEC validation, and that this > client would therefore meekly accept the modified result sent > by the resolving nameserver. Given your assumption, that's right. My assumption is that the querying client is doing DNSSEC validation or at least expecting the DO bit to be set. Which assumption is right depends on the client. > Am I mistaken? Does the querying client receive the result > RRset *and* the DNSSEC signature, and *itself* check the > validity? That depends on the client. There are also the DO and CD bits. Please see https://tools.ietf.org/html/rfc4035#section-3.2.1 https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers When rpz changes a response, BIND9 pretends that the DO bit was off in the request including not copying it to the response. (or is it the CD bit?--I forget). In any case, RPZ is not affected as long as DNS clients don't do their own validating, don't pay attention to the header bits, or believe whatever the recursive server says, whether rewritten with RPZ to block network abuse or adjusted to improve the user experience with interesting offers or block things contrary to national interest, civil harmony, or religious piety. Or defend against attacks on DNS data by men in the middle. > If so, then perhaps: > > Therefore, by default, DNS resolvers using RPZ avoid > modifying DNS results when DNSSEC signatures are available > and are requested by the DNS client. However, when > the common "BREAK-DNSSEC" configuration setting is used, > RPZ-using resolvers do modify query results, even when this > renders them DNSSEC-invalid. In such a case, a querying > client which checks DNSSEC will ignore the invalid result, > and will effectively be blocked from malefactor domains; > this behaviour is functionally similar to that caused by > an RPZ NXDOMAIN policy action. > > There may be a less wordy way to say it, but if I've understood > correctly this time, perhaps that's more clear? Those words are fine with me. Does anyone have a supporting view or some other words? thanks, Vernon Schryver vjs at rhyolite.com From paul at redbarn.org Fri Oct 21 11:16:56 2016 From: paul at redbarn.org (P Vixie) Date: Fri, 21 Oct 2016 11:16:56 +0000 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: <147704006933.23736.7522166523213374011.idtracker@ietfa.amsl.com> References: <147704006933.23736.7522166523213374011.idtracker@ietfa.amsl.com> Message-ID: Second edition. Thanks for all the feedback, everybody. Care to have another look? -------- Original Message -------- From: internet-drafts at ietf.org Sent: October 21, 2016 4:54:29 AM EDT To: Paul Vixie , Vernon Schryver Subject: New Version Notification for draft-vixie-dns-rpz-01.txt A new version of I-D, draft-vixie-dns-rpz-01.txt has been successfully submitted by Vernon Schryver and posted to the IETF repository. Name: draft-vixie-dns-rpz Revision: 01 Title: Response Policy Zones Document date: 2016-10-18 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-vixie-dns-rpz-01.txt Status: https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/ Htmlized: https://tools.ietf.org/html/draft-vixie-dns-rpz-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-vixie-dns-rpz-01 Abstract: This document describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for processing the contents of such response policy zones (RPZ) inside recursive name servers. These "DNS Firewalls" are widely used in fighting Internet crime and abuse. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne at encs.concordia.ca Fri Oct 21 16:44:09 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Fri, 21 Oct 2016 12:44:09 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: Your message of Fri, 21 Oct 2016 11:16:56 -0000 References: <147704006933.23736.7522166523213374011.idtracker@ietfa.amsl.com> Message-ID: <1475.1477068249@vindemiatrix.encs.concordia.ca> > Second edition. Thanks for all the feedback, everybody. Care to have another look? > Htmlized: https://tools.ietf.org/html/draft-vixie-dns-rpz-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vixie-dns-rpz-01 Typo: overriden -> overridden I still find the "Name Length" section confusing. I looked at section 6.1 of RFC 4034, which defines a "canonical ordering", but doesn't use the terminology "smaller" or "bigger". Also, I don't think that "a label that is a prefix of a second label" correctly expresses what I'm pretty sure is meant. For example, "x.y" is a prefix of "x.y.z", and I'm sure that we *don't* mean to compare those, but rather we want to compare "x.y.z" and "y.z", neither of which "is a prefix of" the other, but one of which results from adding a prefix to the other. So I'd like to propose something like: [...] choose the policy that matches the most specific domain name. For example, "x.y.z" is more specific than "y.z". Having proposed the above, though, I have two questions: - Should "BLAH.y.z" not be considered more specific (and a better match) than the wildcard "*.y.z", regardless of whether the asterisk sorts lexicographically before or after "BLAH"? - Are there any other cases where names of equal specificity could both match a QNAME or NSDNAME policy? If not, we could avoid the complexity of referring to and summarizing the canonical sort order at all. I'm afraid that the "Prefix Length" and "Tie Breaker" sections are still obscure to me. :-( Can you show some examples? "Acknowledgements": thank you, and a period is needed at the end of the sentence. :-) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285 From vjs at rhyolite.com Fri Oct 21 17:14:49 2016 From: vjs at rhyolite.com (Vernon Schryver) Date: Fri, 21 Oct 2016 17:14:49 GMT Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: <1475.1477068249@vindemiatrix.encs.concordia.ca> Message-ID: <201610211714.u9LHEn8Z006822@calcite.rhyolite.com> > To: dnsfirewalls at lists.redbarn.org > From: Anne Bennett > Typo: overriden -> overridden thanks. > I still find the "Name Length" section confusing. I looked at > section 6.1 of RFC 4034, which defines a "canonical ordering", > but doesn't use the terminology "smaller" or "bigger". Also, > I don't think that "a label that is a prefix of a second label" > correctly expresses what I'm pretty sure is meant. For example, > "x.y" is a prefix of "x.y.z", and I'm sure that we *don't* > mean to compare those, but rather we want to compare "x.y.z" > and "y.z", neither of which "is a prefix of" the other, but > one of which results from adding a prefix to the other. > > So I'd like to propose something like: > > [...] choose the policy that matches the most specific > domain name. For example, "x.y.z" is more specific than "y.z". I tried to say something shorter and less formal than section 6.1 of RFC 4034, but that DNSSEC "Canonical DNS Name Order" is what is going on. Would it be better say no more than "DNSSEC canonical name order; see section 6.1 of RFC 4034"? Or copy the RFC 4034 text? > Having proposed the above, though, I have two questions: > > - Should "BLAH.y.z" not be considered more specific (and > a better match) than the wildcard "*.y.z", regardless of > whether the asterisk sorts lexicographically before or after > "BLAH"? Those trigger precedence rules were less about specificity than making the rpz results well defined in the mathematical sense or deterministic in the computer science sense. The domain names from the triggering requests instead of the triggers themselve are what are being ordered. There are no wildcards in request QNAMEs or among relevant NS domains. > - Are there any other cases where names of equal specificity > could both match a QNAME or NSDNAME policy? If not, we > could avoid the complexity of referring to and summarizing > the canonical sort order at all. There is only one qname (in each CNAME resolution iteration), and so there can't be 2 domain names matching a single QNAME rule. However, there are usually many NS names and the choice among them must be deterministic for a constant set of NS domain names. (The set of NS domain names for a target domain name are not constant, especially for the sort of requests that rpz should rewrite). vjs From anne at encs.concordia.ca Fri Oct 21 19:52:27 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Fri, 21 Oct 2016 15:52:27 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: Your message of Fri, 21 Oct 2016 17:14:49 GMT References: <201610211714.u9LHEn8Z006822@calcite.rhyolite.com> Message-ID: <4362.1477079547@vindemiatrix.encs.concordia.ca> This turns out to be more complicated than I thought! First, let me back up one subsection to "Within An RPZ", and point out that only four of the five trigger types are mentioned; we should add a sentence fragment to situate the precedence of "Client IP address". And "IP policies" should be "Response IP address policies", I think, to differentiate them from "Client IP address policies". >> I still find the "Name Length" section confusing. I looked at >> section 6.1 of RFC 4034, which defines a "canonical ordering", >> but doesn't use the terminology "smaller" or "bigger". > I tried to say something shorter and less formal than section 6.1 > of RFC 4034, but that DNSSEC "Canonical DNS Name Order" is what is > going on. Would it be better say no more than "DNSSEC canonical > name order; see section 6.1 of RFC 4034"? Or copy the RFC 4034 text? I don't think I'd copy the entire RFC 4034 text (it's rather long), but since it's necessary to refer to that sort order, then since RFC 4034 doesn't define "smaller", we might have to resort to "the one that comes last" in that sort order. (When I think of sort orders, numbers usually come to mind, and we generally sort numbers "smallest first", which is the opposite, I think, of what you mean by "smallest" in the above context, which is why I'd avoid using "size" to refer to a position in the Canonical DNS Name Order.) >> Having proposed the above, though, I have two questions: >> >> - Should "BLAH.y.z" not be considered more specific (and >> a better match) than the wildcard "*.y.z", regardless of >> whether the asterisk sorts lexicographically before or after >> "BLAH"? > > Those trigger precedence rules were less about specificity than > making the rpz results well defined in the mathematical sense > or deterministic in the computer science sense. Sure, but the algorithm wasn't selected arbitrarily, and the proposal of text which mentions a "prefix" (not to mention the title "Name Length") very much suggested to me that in general, specificity is what was wanted (which IMHO would only make sense). And if I understand RFC 4034 correctly, domain names where one name is "prefix.another" will indeed sort "most specific last". Hmm, having gone over this several times now, I begin to understand where some of my confusion comes from... > The domain names from the triggering requests instead of the triggers > themselve are what are being ordered. There are no wildcards in > request QNAMEs or among relevant NS domains. Hang on, the text that introduces the list of precedence rules states: It is possible for more than one policy trigger among the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ various DNS RPZs connected to the name server's control plane to match a given DNS query or DNS response. The precedence ^^^^^^^^ rules for multiple matches are as follows: ^^^^^^^^^^^^^^^^^^^^ ... which I interpreted as: the "matches" that have to be ordered by precedence are indeed the triggers (RRset owner names). But now that I re-re-re-read (!) more carefully, the text above also mentions "a given DNS query" *or* "DNS response". In fact, *both* (triggers and responses) can result in multiple matches. That is, while a query or a client IP address is a single entity, it can match multiple policies. But for the other three trigger types, we can have multiple responses, each of which could in turn match multiple triggers. So I think we need to clarify this somehow. Perhaps if we worked through an example, I would understand more clearly what is wanted, and might be able to suggest text which would be clearer, at least to me. Say we had these policies (all in the same RPZ), which I show in Canonical DNS Name Order): *.dom.ain.rpz-nsdname CNAME walled-garden-a.example.net. ns4.aaa.dom.ain.rpz-nsdname CNAME walled-garden-b.example.net. *.bbb.dom.ain.rpz-nsdname CNAME walled-garden-c.example.net. ns3.bbb.dom.ain.rpz-nsdname CNAME walled-garden-d.example.net. and we queried for the A record for "bad.example.com", where "example.com" had NS records "ns1.example.com", "ns2.dom.ain", "ns3.bbb.dom.ain", and "ns4.aaa.dom.ain". In this case, three of the four NS records match policy rules, and at least one of them matches two policy rules (possibly two of them, *see below). Here I show the actual NS records (responses) in Canonical DNS Name Order, then each group of matches itself in Canonical DNS Name Order: ns4.aaa.dom.ain matches *.dom.ain.rpz-nsdname (?) ns4.aaa.dom.ain and matches ns4.aaa.dom.ain.rpz-nsdname ns3.bbb.dom.ain matches *.dom.ain.rpz-nsdname (?) ns3.bbb.dom.ain and matches *.bbb.dom.ain.rpz-nsdname ns3.bbb.dom.ain and matches ns3.bbb.dom.ain.rpz-nsdname ns2.dom.ain matches *.dom.ain.rpz-nsdname ns1.example.com no match So the last match among the responses is "ns2.dom.ain", but the last match match among the triggers is "ns3.bbb.dom.ain"; which should take precedence? * ... which brings up that (a) in the QNAME section, it could be clarified whether "*.DOMAIN.COM" triggers on queries to "foo.bar.domain.com" in addition to "bar.domain.com", and (b) I had assumed that wildcards would work for NSDNAME triggers if they work for QNAME triggers, but the text doesn't mention them, so I'm probably wrong to make that assumption. I think it's a natural assumption to make, though, so if wildcards don't work for NSDNAME triggers, it might be worth mentioning that specifically. I hope this is helping more than hindering.... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285 From vjs at rhyolite.com Fri Oct 21 20:58:43 2016 From: vjs at rhyolite.com (Vernon Schryver) Date: Fri, 21 Oct 2016 20:58:43 GMT Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: <4362.1477079547@vindemiatrix.encs.concordia.ca> Message-ID: <201610212058.u9LKwht8036079@calcite.rhyolite.com> > From: Anne Bennett > I don't think I'd copy the entire RFC 4034 text (it's rather > long), but since it's necessary to refer to that sort order, > then since RFC 4034 doesn't define "smaller", we might have > to resort to "the one that comes last" in that sort order. So you prefer replacing "smaller" and "larger" with something about "earlier" and "later in the DNSSEC canonical order"? And similarly for "smallest" and "largest"? To me "early" sounds fuzzy and a little informal. What I mean by "smallest" is "first in the well order of all triggers hit by this DNS request as defined by blah de blah" and similarly for "largest", "smaller, and "larger" https://www.google.com/search?q=well+order https://en.wikipedia.org/wiki/Well-order Perhaps the only relevant substance of "well order" is that you can count all possible domains or any subset of domains by associating each with an integer. > (When I think of sort orders, numbers usually come to mind, and we > generally sort numbers "smallest first", which is the opposite, > I think, of what you mean by "smallest" in the above context, > which is why I'd avoid using "size" to refer to a position in > the Canonical DNS Name Order.) I might not understand, because the string "size" does not appear in the draft. I know I don't get "opposite". The RFC 4034 DNSSEC order is merely: 1. re-order the labels, eg. www.example.com -> com.example.www 2. ASCII lexical order but with "." replaced by 0x00 > That is, while a query or a client IP address is a single > entity, it can match multiple policies. But for the other > three trigger types, we can have multiple responses, each of > which could in turn match multiple triggers. That's the purpose of the precedence rules. Given the set of of all rules that triggered by a DSN response, consistently pick one. The choice should 1. be easy to implement 2. facilitate stopping early It's not a coincidence that prefering client-IP to qname to IP to NS to NSIP means that if you get a qname hit in the first policy zone, then you quit immediately and don't need to recurse to find the A RRs to check for IP triggers. 3. make a little intuitive sense, even if only post hoc > Say we had these policies (all in the same RPZ), which I show > in Canonical DNS Name Order): > > *.dom.ain.rpz-nsdname CNAME walled-garden-a.example.net. > ns4.aaa.dom.ain.rpz-nsdname CNAME walled-garden-b.example.net. > *.bbb.dom.ain.rpz-nsdname CNAME walled-garden-c.example.net. > ns3.bbb.dom.ain.rpz-nsdname CNAME walled-garden-d.example.net. > > and we queried for the A record for "bad.example.com", where > "example.com" had NS records "ns1.example.com", "ns2.dom.ain", > "ns3.bbb.dom.ain", and "ns4.aaa.dom.ain". In this case, > three of the four NS records match policy rules, and at least > one of them matches two policy rules (possibly two of them, > *see below). Here I show the actual NS records (responses) > in Canonical DNS Name Order, then each group of matches itself > in Canonical DNS Name Order: > > ns4.aaa.dom.ain matches *.dom.ain.rpz-nsdname (?) > ns4.aaa.dom.ain and matches ns4.aaa.dom.ain.rpz-nsdname > > ns3.bbb.dom.ain matches *.dom.ain.rpz-nsdname (?) > ns3.bbb.dom.ain and matches *.bbb.dom.ain.rpz-nsdname > ns3.bbb.dom.ain and matches ns3.bbb.dom.ain.rpz-nsdname > > ns2.dom.ain matches *.dom.ain.rpz-nsdname > > ns1.example.com no match > > So the last match among the responses is "ns2.dom.ain", but > the last match match among the triggers is "ns3.bbb.dom.ain"; > which should take precedence? In normal DNS matching, wildcards are ignored when there is a specific match, and so the first 3 wildcard triggers are implicitly excluded while ns4.aaa.dom.ain and ns3.bbb.dom.ain are being sought in the policy zone database. The DNSSEC canonical order puts ns4.aaa.dom.ain < ns3.bbb.dom.ain < ns2.dom.ain ain.dom.aaa.ns4 < ain.dom.bbb.ns3 < ain.dom.ns2 ain.dom.aaa < ain.dom.bbb < ain.dom.ns2 and so the winning rule is trigger by ns4.aaa.dom.ain > * ... which brings up that (a) in the QNAME section, it could > be clarified whether "*.DOMAIN.COM" triggers on queries to > "foo.bar.domain.com" in addition to "bar.domain.com", and (b) > I had assumed that wildcards would work for NSDNAME triggers > if they work for QNAME triggers, but the text doesn't mention > them, so I'm probably wrong to make that assumption. I think > it's a natural assumption to make, though, so if wildcards > don't work for NSDNAME triggers, it might be worth mentioning > that specifically. I agree that there should be text somewhare saying that the fundamental trigger lookup scheme is the familiar DNS matching scheme including the odd but unavoidable oddities of zone wildcards. That is why rules are usually doubled, as in having both example.com and *.example.com to catch both example.com and any child of example.com. vjs From anne at encs.concordia.ca Mon Oct 24 22:20:54 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Mon, 24 Oct 2016 18:20:54 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: Your message of Fri, 21 Oct 2016 20:58:43 GMT References: <201610212058.u9LKwht8036079@calcite.rhyolite.com> Message-ID: <9535.1477347654@vindemiatrix.encs.concordia.ca> Vernon, >> I don't think I'd copy the entire RFC 4034 text (it's rather >> long), but since it's necessary to refer to that sort order, >> then since RFC 4034 doesn't define "smaller", we might have >> to resort to "the one that comes last" in that sort order. > > So you prefer replacing "smaller" and "larger" with something about > "earlier" and "later in the DNSSEC canonical order"? And similarly > for "smallest" and "largest"? Yes, something like that. > To me "early" sounds fuzzy and a little informal. If RFC 4034 section 6 used terms such as "smaller" and "larger" I'd have no issue, but the only language I can find in that section is: - "example" sorts first, followed by names ending in "a.example" - the absence of an octet sorts before a zero octet So we have first (last), and before (after). The best match I can think of to that language is earlier/later, but perhaps someone else has an idea for something better. I don't think that "smaller/larger" is clear in this context, or at least, it wasn't to me. >> That is, while a query or a client IP address is a single >> entity, it can match multiple policies. But for the other >> three trigger types, we can have multiple responses, each of >> which could in turn match multiple triggers. > > That's the purpose of the precedence rules. Given the set of of > all rules that triggered by a DSN response, consistently pick one. All rules triggered by a DNS *response*, okay. I think that here: > I agree that there should be text somewhare saying that the fundamental > trigger lookup scheme is the familiar DNS matching scheme including > the odd but unavoidable oddities of zone wildcards. That is why > rules are usually doubled, as in having both example.com and > *.example.com to catch both example.com and any child of example.com. ... you're pointing out that during a lookup, the familiar DNS matching scheme scheme applies, but when a lookup results in multiple answers that themselves require further lookups, then those answers are sorted in DNSSEC canonical order, and processing continues on them (depth first?) until a match occurs. I'm re-reading the entire draft to try to understand this idea of precedence of matches versus "familiar scheme" lookups, and to see if there's any text I could suggest to make it easier for the first-time reader to understand it. This re-reading is bringing up more comments and questions, which I'll send separately. Meanwhile, I want to keep track of your answer to my example; I'll come back and work through it again once I've finished my re-reading. The rest is just a quote of the example; you can stop reading here. >> Say we had these policies (all in the same RPZ), which I show >> in Canonical DNS Name Order): >> >> *.dom.ain.rpz-nsdname CNAME walled-garden-a.example.net. >> ns4.aaa.dom.ain.rpz-nsdname CNAME walled-garden-b.example.net. >> *.bbb.dom.ain.rpz-nsdname CNAME walled-garden-c.example.net. >> ns3.bbb.dom.ain.rpz-nsdname CNAME walled-garden-d.example.net. >> >> and we queried for the A record for "bad.example.com", where >> "example.com" had NS records "ns1.example.com", "ns2.dom.ain", >> "ns3.bbb.dom.ain", and "ns4.aaa.dom.ain". In this case, >> three of the four NS records match policy rules, and at least >> one of them matches two policy rules (possibly two of them, >> *see below). Here I show the actual NS records (responses) >> in Canonical DNS Name Order, then each group of matches itself >> in Canonical DNS Name Order: >> >> ns4.aaa.dom.ain matches *.dom.ain.rpz-nsdname (?) >> ns4.aaa.dom.ain and matches ns4.aaa.dom.ain.rpz-nsdname >> >> ns3.bbb.dom.ain matches *.dom.ain.rpz-nsdname (?) >> ns3.bbb.dom.ain and matches *.bbb.dom.ain.rpz-nsdname >> ns3.bbb.dom.ain and matches ns3.bbb.dom.ain.rpz-nsdname >> >> ns2.dom.ain matches *.dom.ain.rpz-nsdname >> >> ns1.example.com no match >> >> So the last match among the responses is "ns2.dom.ain", but >> the last match match among the triggers is "ns3.bbb.dom.ain"; >> which should take precedence? > > In normal DNS matching, wildcards are ignored when there is a > specific match, and so the first 3 wildcard triggers are implicitly > excluded while ns4.aaa.dom.ain and ns3.bbb.dom.ain are being sought > in the policy zone database. > > The DNSSEC canonical order puts > ns4.aaa.dom.ain < ns3.bbb.dom.ain < ns2.dom.ain > ain.dom.aaa.ns4 < ain.dom.bbb.ns3 < ain.dom.ns2 > ain.dom.aaa < ain.dom.bbb < ain.dom.ns2 > and so the winning rule is trigger by ns4.aaa.dom.ain Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285 From anne at encs.concordia.ca Mon Oct 24 23:13:28 2016 From: anne at encs.concordia.ca (Anne Bennett) Date: Mon, 24 Oct 2016 19:13:28 -0400 Subject: [DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt In-Reply-To: Your message of Mon, 24 Oct 2016 18:20:54 EDT References: <201610212058.u9LKwht8036079@calcite.rhyolite.com> <9535.1477347654@vindemiatrix.encs.concordia.ca> Message-ID: <10221.1477350808@vindemiatrix.encs.concordia.ca> I wrote: > I'm re-reading the entire draft to try to understand this idea of > precedence of matches versus "familiar scheme" lookups, and to see if > there's any text I could suggest to make it easier for the first-time > reader to understand it. This re-reading is bringing up more comments > and questions, which I'll send separately. Section 2: express policy triggers or characteristics of DNS response that require action => express policy triggers, which are characteristics of a DNS query or response, that require action. To "All POLICY described here...", prepend: The format of RPZs has undergone several revisions since work began (see section 7). Section 7: To the paragraph that ends in "required continuing support of the original encodings", add a few brief sentences summarizing the formats, e.g.: The initial specification ("format 1") contained only [list the triggers and actions]. Format 2, issued [date], added/modified [list the changes]. Format 3 ([date]) added/modified [list the changes]. Section 3: for research into attackers and debugging => for research into attackers and for debugging The PASSTHRU action [...] overrides lower precedence policies This mention of precedence seems out of the blue, and it's not clear at this point in the document what might be meant by "lower precedence policies". Do you mean that PASSTHRU is usually intended to override other policies, so the writer of the policies needs to make sure to place the PASSTHRU at a higher precedence level? If it's the case not that PASSTHRU itself is special (IIRC, nowhere else does the "action" part of a policy figure in the determination of precedence), but rather that the PASSTHRU should be written such that it sorts at a higher precedence than the record it overrides, I'd suggest replacing that sentence with: The PASSTHRU action is intended to override other (usually more general) policies, so it should be written such that it appears at a higher precedence than the policies it must override; see Section XXX for precedence rules. because the CNAME target name will not be the root (.), root wildcard (*.), or be a subdomain of a top level domain that starts with "rpz-". => because the CNAME target name will not be the root (.), nor the root wildcard (*.), nor be a subdomain of a top level domain that starts with "rpz-". Section 4: (change first two paragraphs to:) There are five types of RPZ triggers, and they are encoded by RRset owner names in an RPZ. Two of the types of policy trigger are based on characteristics of the DNS query: QNAME, and Client IP address. They are independent of cache contents or recursion results. The other three types of triggers are based on target data (RDATA): they are Response IP address, NSDNAME, and NSIP. Those policies are conceptually applied after recursion, so that the recursive DNS resolver's cache contains either nothing or "truth", even if this truth is hidden by current policy. If the policy changes, the original data is available for processing under the changed policy. Also, I'd change the order of the list of triggers to have the two query-based ones come before the three response-based ones, so: QNAME Client IP address IP address NSDNAME NSIP I think that explicitly making the distinction between query-based and response-based triggers will help us later with the precedence rules. Section 5: I think that this section contains these basic categories of information, which should perhaps be re-ordered a bit and placed in subsections: 5.1 Loading the zones Paragraphs 1, 5, and 6 5.2 Using the zones Paragraphs 7, 9 (the last one, after the precedence material) 5.3 Authority of modified responses Paragraph 4 5.4 Applying the policies Paragraphs 2, 3, a new paragraph to cover the order of operations (in particular, when "familiar DNS scheme" applies (with wildcards), and when precedence rules must be invoked), plus part of paragraph 8. 5.5 Precedence of policies The precedence material starting at "RPZ ordering". My feeling is that if we re-order and categorize this way, it should make it more possible to untangle the confusion (or at least, *my* confusion!) with respect to the order of queries, and the application of the precedence rules. What do you think? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne at encs.concordia.ca +1 514 848-2424 x2285