DNS-over-HTTP/3

Support for DoH https3. https2 is already supported.

https-dns-proxy already supports https3 if it is supported in cURL.

1 Like

Support for HTTP/3 in https-dns-proxy package: https://docs.openwrt.melmac.net/https-dns-proxy/

2 Likes

dnsproxy doh3 GitHub - AdguardTeam/dnsproxy: Simple DNS proxy with DoH, DoT, DoQ and DNSCrypt support

packages/net/dnsproxy at master · openwrt/packages · GitHub


# For documents, please see https://github.com/AdguardTeam/dnsproxy#usage

config dnsproxy 'global'
	option enabled '1'
	option listen_addr '127.0.0.1'
	option listen_port '5353'
	option log_file ''
	option all_servers '0'
	option fastest_addr '0'
	option insecure '0'
	option ipv6_disabled '1'
	option max_go_routines ''
	option rate_limit ''
	option refuse_any '0'
	option udp_buf_size '2500000'
	option verbose '0'

config dnsproxy 'bogus_nxdomain'
	list ip_addr ''

config dnsproxy 'cache'
	option enabled '1'
	option cache_optimistic '1'
	option size '655350'
	option min_ttl ''
	option max_ttl ''

config dnsproxy 'dns64'
	option enabled '0'

config dnsproxy 'edns'
	option enabled '0'
	option edns_addr ''

config dnsproxy 'servers'
	list bootstrap '1.1.1.1:53'
	list fallback 'https://dns.cloudflare.com/dns-query'
	list upstream 'h3://security.Cloudflare-dns.com/dns-query'

dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option ednspacket_max '1232'
	option rebind_protection '0'
	option noresolv '1'
	option localuse '1'
	option filter_aaaa '1'
	option allservers '1'
	option nonegcache '1'
	option cachesize '2500'
	option confdir '/tmp/dnsmasq.d'
	list server '/pool.ntp.org/1.1.1.1'
	list server '/time.cloudflare.com/1.1.1.1'
	list server '127.0.0.1#5353'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

rc.local

/sbin/sysctl -w net.core.rmem_max=2500000

Test https://quic.nginx.org

3 Likes

As mentioned above, better use

/sbin/sysctl -w net.core.rmem_max=2500000

and leave default UDP buffer size

option udp_buf_size ' '
2 Likes

Test https://quic.nginx.org

It tests your browser if it could download resources via QUIC. How does it test dns-over-quic?

PiHole on a LAN would no longer be able to do DNS-level blocking (or rather, redirecting to a DNS-resolved "black hole" of 0.0.0.0), if DNS-over-HTTP/3 goes running past it, correct?

To allow HTTP/3 whatsoever is to launder the use of DNS-over-HTTP/3 along with it, right? This is to say, there would be no way for OpenWRT, to know the difference between a DNS query, and normal HTTP traffic, since it's all necessarily TLS-encrypted, right?

UDP@53 wasn't slow enough, we need to slower DNS down by using more and more abstraction layers :joy:
HTTP/3 uses userspace implemented congestion control on slow routers. Essentially all you get from in-kernel TCP but implemented in userspace and additional overhead of HTTP. It's like switching back to userspace OpenVPN in times of WIreguard.

QUIC runs over port 443 (UDP).

I still wonder why people use DNS-over-HTTPS on routers if it breaks Encrypted Client Hello (former ESNI) in browsers. Essentially exposing unencrypted SNI to everyone in the middle. You can test it here: https://tls-ech.dev/

1 Like

This is why DoH/3 is less block-resistant than DoH.

ECH is basically useless until it becomes mandatory.
And even then it cannot secure DNS traffic system-wide.

1 Like

Can you elaborate on this?

ECH has got nothing to do with DNS security itself. But it relies on DNS security to get that key. This is exactly why they mandate encryption.

Mandatory to what? Server support is a bit higher than zero, that's true. But it is up to client if it uses it or not.

A compromised hotspot can block transit 443/UDP traffic forcing DoH/3 clients running in opportunistic mode to regress to potentially less secure options.

To be clear, people running DoH/DoT on their router want to protect all DNS traffic traversing the router, and ECH cannot help with that.

Mandatory for the HTTP/X specification for better server support.

But they expose SNI... if you run it directly to your browser SNI is encrypted.

Any opportunistic mode is vulnerable to this. It's not a problem of protocol itself. UDP (at least in my network) is already more than 50 percent of all connections. Better hide what you want to hide in UDP trafic these days.

It should be fine as long as it fits personal threat and trust model.

This particular attack is still easier to implement compared to DoH blocking.

Maybe, assuming that upstream does not restrict UDP traffic and considering not just data integrity, but also privacy and performance.

I believe these two contradict each other. You hide DNS but don't care about SNI?

I use DoT for data integrity of all DNS traffic.
Then I use own VPN on a VPS for privacy.

Not really, at least in my threat model.
I trust my DoT and VPS providers.

so about perf what is better dns-over-tls or dna-over-http/3 ?