EDNS key tag for selecting a DNS filter
Some service providers would like to offer a premium DNS filtering service. The filters will be applied only to queries from customers who subscribe (and presumably also pay extra). These filters could include pornography, malware, gambling - whatever the service provider can create a custom filter for.
A local DNS proxy on the customer premises could add some additional information ('key tag') to queries that should be given the premium filtering treatment, before forwarding to the resolver at the ISP. The proxy or forwarder could be a BIND resolver, or a third party (for example, DNSMasq or other open source software running in a home gateway). It is possible that in some cases, the user might wish to apply this code only to specific queries, such as those coming from some subset of clients. This could perhaps be specified by an ACL.
The receiving resolver would match the additional information (presumably an EDNS key tag) to either a BIND view, or a Response Policy Zone (RPZ). (It would be preferable if this solution did not require views.) The operator might also need some statistics to show how many queries were being received and answered with each key tag.
Design a custom EDNS option that can carry enough information to identify a filtering policy. It is hard to see how you would ever need more than 3 digits for this, but some operators might use the tag to identify an individual customer, in which case they would presumably need several more digits.
Implement a method to configure a mapping of these EDNS options in BIND to RPZ filters. We would need many options per RPZ filter, so maybe add the options to a list of filters?
BIND should enforce the policy indicated by the key tag. This filter should be applied (?) first or last, along with any other filters that match the response.
The EDNS tags should be ignored by resolvers that are not configured to understand them.
Contribute a corresponding feature to DNSMASQ to add the EDNS option text in a home gateway. We could sponsor Simon Kelley to do it. Alternatively, we could implement our option to interoperate with the feature already available in DNSMASQ (to overload the EDNS with a 'CPE ID')
- Is the DNSMASQ CPE ID the right option to use, or should we come up with another one?
- How should this filter applied based on EDNS interact with other RPZ policy enforcement on the same server?
- Do we need the ability for BIND to ADD this EDNS extension, or only to accept it?
- The EDNS option will arrive at the BIND server attached to a query, and the RPZ is applied to a response. Is there a problem associated with knowing that a particular response should have a particular EDNS tag?
Links / references
See the related issue #826