[HN Gopher] DNS over Dedicated QUIC Connections
___________________________________________________________________
DNS over Dedicated QUIC Connections
Author : mooreds
Score : 38 points
Date : 2022-05-14 17:18 UTC (2 days ago)
(HTM) web link (www.rfc-editor.org)
(TXT) w3m dump (www.rfc-editor.org)
| solarist wrote:
| So am I supposed now to do DPI in my home router? Will it ever be
| enough to block unwanted content in my network?
| walrus01 wrote:
| 1. don't put devices with untrusted operating systems on your
| home network in the first place
|
| 2. if you must, put them in a quarantine vlan
|
| a better question is why you have things in your home network
| that might be sending encrypted dns queries outside of your
| control, what software or OS is doing that?
| solarist wrote:
| I'm a naive person and believe any form of advertisement is
| intrusive. So by definition anything that wants to show me
| and my kids ads will eventually try to circumvent any filters
| in place.
| tick_tock_tick wrote:
| That has always and will continue to be the only way. Well that
| and only allowing whitelist traffic.
| simcop2387 wrote:
| In this case blocking outgoing traffic to port 853 would be
| enough, but it won't stop DNS over HTTP. I've not found a good
| way to deal with that one if you want to control things, other
| than requiring all devices support your CA and you inspect for
| it.
| dsr_ wrote:
| Things that do DNS over HTTP are asked to respect the use-
| application-dns.net canary. If use-application-dns.net
| queries are blocked by the local resolver, the thing should
| use the local resolver, unless there is a manual override by
| the human user.
| codedokode wrote:
| This is a bad idea. ISPs will use this to force users to
| send queries in plain text. There is no need for this
| feature.
|
| One might say that a corporation might need this. But why
| should we care about corporations? Let them use Internet
| Explorer that sends everything in plain text. Or they could
| configure using unencrypted DNS in group policy.
|
| Encrypted DNS should be indistinguishable from any other
| HTTPS traffic.
| ghotli wrote:
| First I've heard of this. Is this in a spec somewhere you
| happen to be aware of?
| yagibear wrote:
| It's mentioned in an expired Internet Draft
| https://www.ietf.org/archive/id/draft-schwartz-add-ddr-
| forwa... which refers to https://support.mozilla.org/en-
| US/kb/canary-domain-use-appli...
| ocdtrekkie wrote:
| So enterprise-class firewalls can presently identify and block
| the QUIC protocol entirely. (If you have such a firewall, I
| recommend this! Nothing supporting QUIC has no fallback.)
| Hopefully that level of intelligence will eventually make it
| down to at least prosumer-grade firewalls, but the folks who
| buy D-Link and Linksys stuff are probably out of luck.
| rektide wrote:
| It feels like such a huge missed opportunity that QUIC is just so
| bad at multiplexing different concerns. I get that the limitation
| that DoDQ runs on port 853 is in part a feature, that separating
| it's network traffic is in some ways/cases desireable, but that
| DoDQ can't also be useful- for an operator who wants to- over
| port 80, is as much a limitation of QUIC's intent/design as it is
| a conscious design decision made by the RFC; there's not really
| another way to do it, short of generating some new protocol
| signaling system. Rather than being a raft we can tie more
| concerns to, QUIC is a prototype we have to keep building yet
| more and more ships from the skeleton of. I wish QUIC were more
| ambitious, aimed to encapsulate more varied concerns by it's
| nature, rather than leaving each protocol to fork off the core.
|
| I keep seeing this wonderful flexible multicast new protocol
| (QUIC), but see these really big ways it limits what it wants to
| take on in really harmful ways. The unreliable datagrams spec,
| for example, punted entirely on multiplexing[1]. Every unreliable
| protocol that needs different "streams"/channels then has to go
| invent streams all over again, but there's no guarantee the
| different implementations will be compatible & able to share the
| one and only unreliable data-channel datagrams affords. This is
| easily witnessable in MASQUE[2].
|
| Ideally I'd like to see some kind of standard for declaring
| protocol, so different streams of different protocols can "just
| work" over a shared QUIC connection. And I'd like to see streams
| brought to datagrams, with perhaps one shared/default "global"
| (per-connection) stream alike what we have now. There's so much
| good protocol work here, but we keep being just short of making
| it easy to layer things in; so close, but falling in critical
| areas for lack of ambition.
|
| [1] https://quicwg.org/datagram/draft-ietf-quic-
| datagram.html#na...
|
| [2] https://blog.cloudflare.com/unlocking-quic-proxying-
| potentia... https://news.ycombinator.com/item?id=30744739 (4
| points, 57d ago, 2 comments)
| westurner wrote:
| > Abstract: _This document describes the use of QUIC to provide
| transport confidentiality for DNS. The encryption provided by
| QUIC has similar properties to those provided by TLS, while QUIC
| transport eliminates the head-of-line blocking issues inherent
| with TCP and provides more efficient packet-loss recovery than
| UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS
| over TLS (DoT) specified in RFC 7858, and latency characteristics
| similar to classic DNS over UDP. This specification describes the
| use of DoQ as a general-purpose transport for DNS and includes
| the use of DoQ for stub to recursive, recursive to authoritative,
| and zone transfer scenarios._
|
| > [...] _DNS over HTTPS (DoH) [RFC8484] can be used with HTTP /3
| to get some of the benefits of QUIC. However, a lightweight
| direct mapping for DoQ can be regarded as a more natural fit for
| both the recursive to authoritative and zone transfer scenarios,
| which rarely involve intermediaries. In these scenarios, the
| additional overhead of HTTP is not offset by, for example,
| benefits of HTTP proxying and caching behavior._
| [deleted]
| egberts1 wrote:
| Better to use a different port number than 853, for DNS-over-
| QUIC.
| Animats wrote:
| Why is parallel delivery over multiple streams an issue for DNS?
| Is the idea to maintain a persistent connection to a DNS server
| and keep sending requests over that connection? That means the
| DNS server has a permanent connection to track your network
| activity, which Google would probably like.
| rektide wrote:
| Performance. Making every network-element, every hop, have to
| add something to the routing table is slow. QUIC is either 1 or
| 0-RTT encryption, depending on if there's existing contact
| (irrc), so I guess we can't argue encryption delays matter
| much. There's other abstract concerns though- having multiple
| short-lived connections in your OS and routing tables consumes
| resources- minimizing resource consumption is a decent goal.
|
| I don't know how long the "connection" is expected to remain
| around. It could be long lived. QUIC is over UDP, and
| connection becomes more a QUIC concept & pattern of use than
| otherwise. But I don't see how this is worse than what we do
| now, which involves an ongoing long dialog with one or two
| select dns servers. I guess one could say there's some
| ambiguity at the moment, now, about who exactly a request is
| coming from, if you allow for NAT, and that starts to go away
| some here. It may indeed be an ok idea to limit the lifetime of
| these QUIC connections, but you'd probably need to start taking
| the 1-RTT latency hit for each new connection to really reap a
| privacy gain- pretend you had never talked to the server
| before. The spec notes this[1] & mentions the speed vs privacy
| trade off.
|
| [1] https://www.rfc-editor.org/rfc/rfc9250.html#name-session-
| res...
| phh wrote:
| Uh sorry, what? You say ""your OS"" so I'm guessing you mean
| an eyeball device. Routing tables (well, it's just knowing
| which pid bound which socket really) on eyeball devices is
| pretty much free at the order of magnitude of a standard
| website where 99.99% of the CPU and RAM is spent in the
| browser. I don't even understand what kind of resource we
| would be talking about here?
|
| I'm guessing I'm missing something, though I can't see what,
| could you help me?
| fanf2 wrote:
| I deployed DNS-over-TLS on Cambridge University's resolvers
| in late 2018, and at that time Android already had a superb
| implementation, that respected the DNS server's advertised
| connection idle times, and used TLS session caching to make
| reconnection faster.
|
| IIRC an idle time of about 10 seconds seemed reasonable: long
| enough to be used for all the DNS requests even from a slow
| web page, but not so long that the server spends ages keeping
| state that will never be reused.
| bogomipz wrote:
| >"There's other abstract concerns though- having multiple
| short-lived connections in your OS and routing tables
| consumes resources- minimizing resource consumption is a
| decent goal."
|
| I'm not understanding this. Your OS's network stack would
| just see these destinations as not being part of the local
| network and send these UDP packets to the configured default
| route. Why would there be a need to create a route?
| exabrial wrote:
| For the love of all that is holy... DNS should be UDP (or eqiv),
| as most building block protocols of the internet. _that doesn't
| mean it needs to be unencrypted_. Wasn't there DNSCurve a thing
| at one point that was the best of all worlds?
| bogomipz wrote:
| DNS has always supported TCP. RFC 1034(1987) made it a
| requirement. DNS uses TCP when replies exceed 512 bytes(barring
| EDNS0.) DNS also uses TCP for zone transfers. There's even a
| bit called the TC(truncate) bit which when set in a response
| informs the client to use TCP.
| tssva wrote:
| DNS has always supported UDP and TCP. Traditionally queries
| used UDP and transfers TCP but this wasn't a requirement of the
| protocol. With the advent of EDNS and large responses such as
| those when DNSSEC is involved TCP was increasing being used for
| queries even before DoT or DoH.
|
| QUIC is UDP based so by being able to handle large responses
| DoQ reduces the need to use TCP and brings your vision of a UDP
| only DNS closer to fruition.
| 1vuio0pswjnm7 wrote:
| CurveDNS, an implementation of a dnscruve forwarder, works
| great. I use it on the home network. To see an example on the
| internet, try x=$(dq -a a ianix.com 192.5.6.30
| |sed -n '/authority/{s/.* NS //;s/\..*//p;q;}') dq -a -k
| $x a ianix.com 104.207.143.9
|
| dnscurve comes from the same author as the underlying
| encryption used in dnscurve and QUIC (and countless other
| solutions), and both NaCl and dnscurve predated QUIC. Today,
| QUIC looks overengineered and has too many privacy issues
| compared to the original, IMHO. The author of NaCl and dnscurve
| was not interested in personal data mining and selling
| advertising services, unlike the corporations behind QUIC. Oh
| well.
|
| https://github.com/curvedns/curvedns
| tialaramex wrote:
| Well, it was the Daniel Bernstein solution, so I'm sure
| _Bernstein_ thought it was the best of all worlds but the rest
| of us not so much.
|
| There are already several other protocols you can ask/ answer
| DNS queries over.
| zaik wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=31347478
___________________________________________________________________
(page generated 2022-05-16 23:01 UTC)