[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