Just a few months ago there were a lot of buzz because IETF in expedited time frame (about one year) accepted DNS over HTTPS (DoH) as a standard (RFC-8484). The discussions about that are still going on because of its controversy. My personal opinion is that DoH is good for personal privacy (if you know how to use it and trust your DNS provider) but it is a security risk for enterprises. DNS over TLS (DoT) is a better alternative for enterprise customers only because it uses a well-defined TCP port but for personal privacy it is not good because of the same reason (easy to block).
Despite of the differences DoH and DoT basically solve the same issue — securing DNS communications. So a malicious actor cannot eavesdrop on unencrypted DNS traffic and use it to identify a weak link and for an attack. This was discussed a lot but looks like one topic was completely forgotten or not broadly covered — Response Policy Zones (RPZ) transfer.
RPZ/DNS Firewall is a security feature which is supported by several DNS servers: ISC Bind, PowerDNS, KnotDNS and products based on them. RPZ is easy to implement, support and very scalable with a minimal impact on performance, so that a DNS server can be included into organization security as an additional layer. Response Policy Zones can be locally maintained or downloaded from 3rd party providers like Infoblox, SURBL, Farsight etc. Standard DNS zone transfer protocol is used to deliver RPZ feeds. Usually DNS Zones are transmitted via TCP and signed by TSIG key so the content cannot be easily altered but it is unencrypted and this may potentially lead to worse problems. If a malicious actor intercept this traffic then blocked indicators (domains, IPs) are exposed and it is possible to bypass DNS security layer. DNS RPS (Response Policy Service) is a new ISC Bind feature which probably will address the issue but right now it is poorly documented and not supported by other DNS servers.
DoT and DoH RFCs do not limit kinds of requests and responses can be transferred over an encrypted channel so it is possible to leverage these standards for DNS zone transfers including RPZ feeds.
With this blogpost I'm glad to announce that ioc2rpz natively (no proxy or extra software required) supports DoT, so that RPZ feeds can be securely distributed over insecure channels/Internet. This is the first release (with DoT) so there are some limitations: single request per session and TLS 1.2 only are supported, DNS Notify and TLS PIN are not supported.
ioc2rpz.gui (a web interface) right now doesn't support DoT configuration (it is in the road map) but the configuration is really simple. A server checks a configuration and starts TLS listeners if the configuration contains a certificate (and a private key).
Despite of the differences DoH and DoT basically solve the same issue — securing DNS communications. So a malicious actor cannot eavesdrop on unencrypted DNS traffic and use it to identify a weak link and for an attack. This was discussed a lot but looks like one topic was completely forgotten or not broadly covered — Response Policy Zones (RPZ) transfer.
RPZ/DNS Firewall is a security feature which is supported by several DNS servers: ISC Bind, PowerDNS, KnotDNS and products based on them. RPZ is easy to implement, support and very scalable with a minimal impact on performance, so that a DNS server can be included into organization security as an additional layer. Response Policy Zones can be locally maintained or downloaded from 3rd party providers like Infoblox, SURBL, Farsight etc. Standard DNS zone transfer protocol is used to deliver RPZ feeds. Usually DNS Zones are transmitted via TCP and signed by TSIG key so the content cannot be easily altered but it is unencrypted and this may potentially lead to worse problems. If a malicious actor intercept this traffic then blocked indicators (domains, IPs) are exposed and it is possible to bypass DNS security layer. DNS RPS (Response Policy Service) is a new ISC Bind feature which probably will address the issue but right now it is poorly documented and not supported by other DNS servers.
DoT and DoH RFCs do not limit kinds of requests and responses can be transferred over an encrypted channel so it is possible to leverage these standards for DNS zone transfers including RPZ feeds.
With this blogpost I'm glad to announce that ioc2rpz natively (no proxy or extra software required) supports DoT, so that RPZ feeds can be securely distributed over insecure channels/Internet. This is the first release (with DoT) so there are some limitations: single request per session and TLS 1.2 only are supported, DNS Notify and TLS PIN are not supported.
ioc2rpz.gui (a web interface) right now doesn't support DoT configuration (it is in the road map) but the configuration is really simple. A server checks a configuration and starts TLS listeners if the configuration contains a certificate (and a private key).