[dns-operations] need ideas for selective proxying to defeat the economic poison pill built into DOH
Fred Morris
m3047 at m3047.net
Thu May 30 02:33:17 UTC 2019
On further reflection, I observe that the effect of (successfully)
blocking access to an IP address is to render whatever service it offers
unusable (no warning message or other feedback is provided to the (ab)user).
Given that that's the case, then when I see traffic for an IP address I
haven't seen, I don't need to block it right away. I can wait whole
SECONDS, even, for the DNS response to show up in my tool. If it hasn't,
then I block it. Yep, that'll render web sites unusable. I don't even
need to block all addresses, all the time.
It's a question of your objective:
* Are you trying to prevent any traffic to an IP address which isn't the
subject of a DNS lookup (security)?
* Are you trying to prevent use of your network if the user doesn't
agree to do DNS lookups (policy)?
--
Fred Morris
On 5/16/19 8:58 PM, Mukund Sivaraman wrote:
>> On 5/16/19 12:37 PM, Witold Krecicki wrote:
>>> Latency - if we add the rule to iptables too late the user experience is
>>> much worse (been there, done that),
>> Would you please elaborate on "too late". Do you mean too many other rules
>> that get processed before the rule for dnsfire?
> If a path to the peer is not opened at the firewall before the DNS
> response is received by the client, the client may race ahead and
> attempt a SYN to the peer before the firewall is ready, which will get
> blocked.
>
> The resolver would have to synchronously ensure a hole has been punched
> in the firewall for the answer it is returning before returning the
> answer to the client.
>
More information about the dns-operations
mailing list