DNS over Dedicated QUIC Connections(rfc-editor.org)
rfc-editor.org
DNS over Dedicated QUIC Connections
https://www.rfc-editor.org/info/rfc9250
14 comments
Do we have more protocols for dns than commonly used dns record types yet? There’s been quite a proliferation recently. :)
He who controls the DNS controls the internet.
DNS over HTTPS uses TCP-based http/2, which is less efficient than UDP-based QUIC (aka http/3).
> DNS over HTTPS uses TCP-based http/2
DoH (ietf rfc 8484) recommends http/2 as a minimum, http/3 is a valid DoH transport.
> which is less efficient
What kind of efficiency are you referencing? This is not a clear cut issue.
> UDP-based QUIC (aka http/3)
The linked rfc uses only the quic transport, not http/3.
DoH (ietf rfc 8484) recommends http/2 as a minimum, http/3 is a valid DoH transport.
> which is less efficient
What kind of efficiency are you referencing? This is not a clear cut issue.
> UDP-based QUIC (aka http/3)
The linked rfc uses only the quic transport, not http/3.
Can't wait for Paul Vixie's† take on this. :)
† He's a co-founder of Internet Systems Consortium (ISC).
† He's a co-founder of Internet Systems Consortium (ISC).
DoQ uses the DoT port, so I assume he'll approve of it; his objection to DoH was that it's designed to blend in with HTTPS traffic, and is difficult for network operators to filter.
Regardless of what the standard says, though, this is going to end up running over 443/udp from browsers, or it's not really going to run anywhere at all.
Regardless of what the standard says, though, this is going to end up running over 443/udp from browsers, or it's not really going to run anywhere at all.
The fact that this requires a dedicated quic connection seemed like a huge turn off to me. As an oine service I'd rather be able to manage & juggle different protocols multiplexed onto a single quic connection as I see fit, rather than be subject to networks trying to apply their own smarts & priorities. I think I can help my users better than network operators in the middle will do.
> his objection to DoH was that it's designed to blend in with HTTPS traffic, and is difficult for network operators to filter.
Why's that a bad thing?
Why's that a bad thing?
From a presentation he's done on DoH (he's done a few):
> 2. DoH creates a new class of exfiltration risks
[…]
> When DNS traffic goes through the HTTPS port, it becomes completely indistinguishable from web traffic, or as Paul said, “paints us all with the same brush.” It is this lack of visibility where the trouble happens. Consider a CISO who wants to use DNS as a strategy to protect their network. Or consider a network team who need to block or sinkhole traffic. With DoH, that’s not possible.
> Since DoH changes the security perimeter and controls that were once possible with conventional DNS, this a potential vulnerability that bad actors can exploit. Paul’s biggest concern is “every botnet from now on is going to be coded to use DoH.” That will cause headaches for everyone in a company’s IT organization.
> Most quotable moment: “What we’ve done here is to create a new class of exfiltration risk that we can expect every intruder whether hardware, software or [meetware 00:56:41] is going to be using “ – Paul Vixie
* https://bluecatnetworks.com/blog/3-takeaways-from-the-dns-ov...
Vixie has been doing DNS since ~1998, wrote/maintained BIND 8, co-founded ISC (which maintains BIND 9 and DHCPd), and a bunch of other Internet-y stuff such that he's in the Internet Hall of Fame:
* https://www.internethalloffame.org/inductees/paul-vixie
See also "DoH Policy Conference - The Consequences of Encrypting DNS":
* https://www.youtube.com/watch?v=9CKxIHSlfgg
From some BSD conferences:
* https://www.youtube.com/watch?v=ZxTdEEuyxHU
* https://www.youtube.com/watch?v=8SJorQ9Ufm8
> 2. DoH creates a new class of exfiltration risks
[…]
> When DNS traffic goes through the HTTPS port, it becomes completely indistinguishable from web traffic, or as Paul said, “paints us all with the same brush.” It is this lack of visibility where the trouble happens. Consider a CISO who wants to use DNS as a strategy to protect their network. Or consider a network team who need to block or sinkhole traffic. With DoH, that’s not possible.
> Since DoH changes the security perimeter and controls that were once possible with conventional DNS, this a potential vulnerability that bad actors can exploit. Paul’s biggest concern is “every botnet from now on is going to be coded to use DoH.” That will cause headaches for everyone in a company’s IT organization.
> Most quotable moment: “What we’ve done here is to create a new class of exfiltration risk that we can expect every intruder whether hardware, software or [meetware 00:56:41] is going to be using “ – Paul Vixie
* https://bluecatnetworks.com/blog/3-takeaways-from-the-dns-ov...
Vixie has been doing DNS since ~1998, wrote/maintained BIND 8, co-founded ISC (which maintains BIND 9 and DHCPd), and a bunch of other Internet-y stuff such that he's in the Internet Hall of Fame:
* https://www.internethalloffame.org/inductees/paul-vixie
See also "DoH Policy Conference - The Consequences of Encrypting DNS":
* https://www.youtube.com/watch?v=9CKxIHSlfgg
From some BSD conferences:
* https://www.youtube.com/watch?v=ZxTdEEuyxHU
* https://www.youtube.com/watch?v=8SJorQ9Ufm8
He's an authority on the DNS, but that doesn't mean he's right about everything to do with it. He's an advocate for DNSSEC, for instance, which is a fiasco. In this instance, his concern about DoH enabling malware or closed-source devices is incoherent (none of these bugbears even need to use DNS at all if they don't want to). The concern DoH addresses, meanwhile, is not abstract: if you're in the US on a major ISP, it's almost certain that your ISP is monetizing your DNS lookups.
"need to block or sinkhole traffic. With DoH, that’s not possible"
Why not? You can't hide the IP's and you can do your own reverse lookup.
That will block some false positives from shared IP's, but if you're even doing this at all then you don't care about that.
Why not? You can't hide the IP's and you can do your own reverse lookup.
That will block some false positives from shared IP's, but if you're even doing this at all then you don't care about that.
For Paul's take, ref: https://archive.is/MbQ79 (discussing "political nature" of DoH with Peter Lowe).
It's not, and he's wrong.
If you need encrypted DNS and you have to do it over udp, you will have to use doq or doh3, both of which contain session state on both ends points. We thought of dns over dtls but it just wasn't more efficient than dot, even though dtls and dot also contain some session state.