-- Leo's gemini proxy

-- Connecting to gemini.dimakrasner.com:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

DNS over Gemini (DoG)


First of all, we must admit that DoG doesn't sound like a super bad idea (and it's a much better acronym) compared to DoH, and I'm not saying this only because I'm a Puppy Linux developer:


https://en.wikipedia.org/wiki/DNS_over_HTTPS


One of my most useful projects is nss-tls: a caching DoH resolver that can be configured to replace the libc DNS resolver, with or without fallback to DNS on failure. This automagically "migrates" all applications that use the libc API (getaddrinfo(), gethostbyname(), etc') from the venerable, unencrypted DNS, to the encrypted DoH, while adding multiple layers of complexity (TCP, HTTP, connection pooling, etc'). In reality, it works very well and the overhead is minimal, thanks to caching, connection pooling and CDNs.


https://github.com/dimkr/nss-tls


(There are rare exceptions, though: for example, Chrome-based browsers use an internal resolver instead of using libc, so they control the cache, choose the DNS server and can use DoH independently of the system.)


One of the cool aspects of DoH, compared to DNS, is the simplicity of writing your own server. It's HTTP, so you can use things like web frameworks, auto-scaling, reverse proxies or load balancers. For example, I wrote dohli, a DoH server written in Go that uses DNS against a DNS server of your choice (with cache that respects the TTL), but responds with NXDOMAIN ("no such domain") if it's a malware or advertising domain:


http://github.com/dimkr/dohli

https://github.com/StevenBlack/hosts


(I use it with one of the DoH client apps as a system-wide ad blocker for my Android smartphone.)


It should be super easy to implement DoG: DoH puts a base64-encoded DNS query in the HTTP query and returns a DNS response in the response body. This can be easily translated to a Gemini URL that expects input (without the "?dns=") with TOFU instead of CA certificates and no connection pooling.


I believe DoG can work well, because the most important overhead-reducing tool in the nss-tls stack is the local cache (in nss-tls, nscd or both): nss-tls still works surprisingly well even without HTTP Keep-Alive, without connection pooling and without a nearby server.


Unsurprisingly, the first roadblock is dropping nss-tlsd's libsoup dependency and using a raw TLS socket, without CA verification 😑

-- Response ended

-- Page fetched on Fri May 10 13:11:35 2024