[dns-operations] need ideas for selective proxying to defeat the economic poison pill built into DOH
Grant Taylor
gtaylor at tnetconsulting.net
Fri May 17 05:10:12 UTC 2019
On 5/16/19 9:58 PM, Mukund Sivaraman wrote:
> Hi Grant
Hi,
> 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.
I agree that what you describe is an ideal situation. But I don't
believe it's a required situation.
Rather I think that (at least) TCP clients will timeout shortly and
retransmit the SYN. Is relying on such client side retransmission
ideal, no. Would it function, I think so.
I feel like there might be some other hacks that could be done to help
avoid such retransmission. Specifically, have the firewall itself sniff
and potentially take action on incoming DNS reply traffic. (There is an
issue of which client is allowed to connect. Though there might be
options for this too.) It may also be possible to allow the outgoing
SYN, and filter on the incoming SYN+ACK reply. Thereby changing the
timing in the race condition to include the round trip time out the
Internet connection.
There may also be some possibility of queuing the outgoing SYN somewhere
to give the firewall a chance to be updated.
Remember how the first few pings might fail when using a dial-on-demand
system or when the layer 3 equipment needs to perform an ARP for the
layer 2 MAC address. ;-)
In short, I think there are some games that could be played to make this
function.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190516/c3389b84/attachment.bin>
More information about the dns-operations
mailing list