[HN Gopher] Hickory DNS
___________________________________________________________________
Hickory DNS
Author : ctz
Score : 51 points
Date : 2023-10-05 15:49 UTC (7 hours ago)
(HTM) web link (bluejekyll.github.io)
(TXT) w3m dump (bluejekyll.github.io)
| bluejekyll wrote:
| Nice to see this here, also see the cross post on the Prossimo
| Blog (same just more official looking):
| https://www.memorysafety.org/blog/announcing-hickory-dns/
|
| 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.
| WarOnPrivacy wrote:
| _The Hickory DNS project supports DNSSEC, DoT, DoH, and DoQ._
|
| 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?
| bluejekyll wrote:
| I suppose it also depends on your position on DoH as well, as a
| I know some folks don't like the idea of clients avoiding local
| DNS resolvers when using it.
|
| 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.
| toast0 wrote:
| Isn't TCP + TLS, with false start or TLS 1.3 also three round
| trips?
|
| 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.
| bluejekyll wrote:
| Yes I think you're correct with pre established
| connections, etc, TLS 1.3, there are definitely
| efficiencies there.
| aidenn0 wrote:
| QUIC is very useful. It's basically the 50% of SCTP[1] needed
| for HTTP/3, with mandatory encryption and delivered over UDP so
| that middleboxes don't freak out over it.
|
| 1: Stream Control Transport Protocol
| https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
| o11c wrote:
| Note that the actual SCTP is flawed in several ways, even
| ignoring the middlebox problem and tooling problems.
| throwawaaarrgh wrote:
| I don't understand why anyone imagines "middleboxes" (there's
| an overloaded term) won't implement QUIC, drop connections
| that don't use their CA cert, and then fuck with the
| connection by mitm. ISPs might not in the west, but they sure
| as fuck will in less liberal societies, and every corporate
| network will eventually.
|
| 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.
| aidenn0 wrote:
| Well it definitely makes it so middleboxes are highly
| unlikely to _misinterpret_ QUIC as anything pre-existing.
| Plenty of things will notice SCTP (whether or not
| encapsulated in UDP) and muck things up (or just drop
| everything).
| mcpherrinm wrote:
| Dns over Quic is RFC 9250. Quic is RFC 9000.
|
| 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.
___________________________________________________________________
(page generated 2023-10-05 23:01 UTC)