> If the answer is too big for UDP, DNS falls back to TCP and this fall-back is used more often these days. With the emergence of DNSSEC and TXT records, large answers are more common than they used to be.
And the wonderful issues that can come with it sometimes. Although I suspect much less now that large responses are more common.
Back in the day a very popular registrar that included DNS service would have random issues with the size of DNS response when it switched over to TCP, returning servfail instead of answer.
I'm guessing it was a load balanced cluster and some of the servers were broken. We reported the issue a few times but never heard back, as expected.
I ran a survey in 2017 and found that around 0.1% of the DNS servers we poked at would negotiate TFO and of those around 94% were Google's. It might be interesting to take another look at the deployment numbers at some point.
The author complains about slow adoption, lack of documentation and incomplete implementations of TFO.
But RFC7413 which describes TFO (https://datatracker.ietf.org/doc/html/rfc7413) still has an experimental status. This thing is not expected to be widely supported or work as production-quality feature, yet:
> Status of This Memo
> This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
For a dns server this is irrelevant, but what impact do these cookies have on privacy if I'd use it while browsing? And how long are these cookies meant to be valid for? To have a speed-up effect, it needs to be long enough to cover two separate website visits, but to preserve privacy you might argue the requirement is exactly the opposite.
I would be curious if anyone knows if a scheme like Zcash was considered. No, not another shitcoin, it's from 1983 and uses RSA blind signatures:
> Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify. In this case, the signer's response is first "un-blinded" prior to verification in such a way that the signature remains valid for the un-blinded message.
I guess the issue would be too large signature sizes are needed for RSA, and that the verification operation is asymmetrically slower than what a client has to do, leading to a denial of service attack? Maybe the server could have (configurably) a per-IP limit of, for example, 4 opens per 20 seconds (bursty) and a global limit of 10% of CPU time as measured over 10 seconds. Above those limits, clients just have to do a 3WHS as usual or re-use connections if the protocol allows (http does).
I'm probably overthinking this but without blind signatures, it seems like no browser would enable it for privacy reasons. Technically it's illegal to use this for tracking without a reason (such as user consent or fraud protection or so), but that won't stop everyone from doing it.
Has anyone seen a good code example of sending server response data in a SYN+ACK packet on Linux? Last time I tried it didn't seem to work - I could only get data in the client's SYN, the server sends an empty SYN+ACK. Perhaps I'm mistaken in what Fast Open is mean to allow.
I don't think TCP_DEFER_ACCEPT does that - "Allow a listener to be awakened only when data arrives on" it just changes the timing of accept()? What you describe sounds more like TCP_CORK, but I don't think that'll work.
Looking a bit more at the network stack perhaps the SYN+ACK is sent straight from the SYN handler with no chance for userspace to pack any data in.
I wonder why client and server software needs to opt-in to TFO and it isn't just handled transparently by the kernel? Perhaps with a sysctl flag to enable or disable it globally.
On the client side, unless the client knows about TFO it's not going to be set up to send data with the initial connection - it's going to use the standard BSD sockets flow of connect(); send();. To usefully use TFO you need to replace the connect() with a sendto() using MSG_FASTOPEN that requests sending of the data you want to send with the SYN.
I did not know that was a thing!
https://serverfault.com/questions/698251/how-does-the-dns-pr...