Hickory DNS
bluejekyll.github.io
bluejekyll.github.io
Since the title here doesn’t state so, this is a direct continuation of the work that’s been going on for the last 8 years on Trust-DNS. When Josh and the ISRG started discussing with me putting more direct effort behind the project there were some concerns about the Trust-DNS trademark. “Trust” and “DNS” being common words that appear together often when folks refer to their own DNS software or services. So then we started discussing a rebranding.
Over the next couple of weeks I’ll be applying the brand name to the repo and all the crates, etc., so please be patient as we perform some of the necessary tasks associated with this rebranding effort.
I’m personally really excited about ISRG’s involvement and their entire Prossimo project, and I’m hoping this opens a great new chapter for Hickory DNS.
DoQ? It's DNS over QUIC.
QUIC? Quick UDP Internet Connections (pronounced quick) is an experimental transport layer network protocol designed by Google.
Google? Is QUIC like AMP and Manifest v3, something Google created to maximize Google wealth & internet crappiness? I don't know.
Do you know if QUIC is awful or helpful? Ever play with DoQ?
The simple answer is that DoQ, and Quic, are more efficient at connection establishment when setting up a TLS connection it reduces the total round trips for TLS from 6 to 3, which is pretty assume for reducing latency.
While Google developed it, I don’t think there is anything inherent to it that makes using it any different that using TCP and/or TLS like people do today.
C: SYN -> S
S: SYN + ACK -> C
C: ACK -> S
C: Client hello -> S (no need for two separate packets, but almost everyone sends the no data ack)
S: Server hello, certificate, server hello done -> C
C: client key exchange, change cipher spec, finished, application data -> S
S: change cipher spec, finished, application data -> C
In theory, you could use tcp fast open to shave a round trip, and you can use TLS 1.3 early data to get to application data on the second round trip where there's a session to resume, if the client sent data is OK to replay.
I have small biz Unbound resolvers out there. For whatever reason I hadn't run into DoQ. Or QUIC for that matter. Not sure if that merits any chagrin.
I think Google products vary from helpful to harmful. Good for me is that HN folks often know how beneficial (or not) some G tech might be.
I'm good with it. It was a tiny bit annoying at first but I strongly support the intent behind it. Mozilla's override (at the resolver) is trivial to enact so I've nothing to complain about.
Quic is the transport that underlies HTTP/3.
While it started at Google, many others were involved in its design and deployment, including the browsers, web servers, and large parties like the CDNs.
1: Stream Control Transport Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
The entire point of "middleboxes" is to solve a problem on a network you control. The problem doesn't go away "because encryption". They're just going to find another way to do what they want, because the protocol gods refuse to add needed features. Whoever decided that this was going to solve the problem didn't spend more than 5 minutes thinking about it. It's actually creating more problems.