The DNS in Tor Onion Services
NOTE: This issue is created as a place to dump my ideas, this is not a complete proposal. It may even be entirely stupid, but I would like to prompt some discussion.
With that note of out the way, what the hell am I on about here? At the Tor meeting in Lisbon 2024 I was discussing with Jeremy (of Namecoin) about TLSA records for onion services. Given the (if I say so myself, successful) work I've done on CAA records (spec proposal 343-rend-caa) it seems natural to also put TLSA records in the onion service descriptor.
Given that, I thought, why are we trying to define something different for every DNS record type. Why not, instead, simply shove the entire DNS into Tor, so we only need to do this extension work once.
This raises a few important questions:
- am I sane?
- what problems would this cause?
- would this even work?
- how would this work?
- and most importantly: what security implications would this have?
My initial thought was to put the BIND Zone file format (RFC 1035, as extended) into the descriptor file. At first this seems the natural way to do it, however it creates some issues for extensibility. For every new DNS RR Type every part of the network that parses this will need to know how to parse the RR textual representation. It's therefore likely better for the future to instead store the wire-format of RRs in the descriptor, probably in some compressed binary (and then base64 encoded) blob to reduce the size of the descriptor. A DNS resolver could then serve new DNS types without having to know what they actually are.
Putting the whole DNS in Tor raises some semantic questions, such as (but not limited to, I've likely missed a lot):
- what is the purpose of A and AAAA records, if any purpose at all
- CNAMES; how do they work, same goes for DNAME?
- what do NS records even do?
- how do HTTPS records work for their IPv4 and IPv6 fields? (ECH etc would be useful without modification)
- PTR records are likely useless
For A and AAAA records, could a new RR be defined of some form of 'endpoint ID' that gets passed with the introduction message to direct the onion service which backing service should be connected. That is a method for ssh q@a.<address>.onion
and ssh q@b.<address>.onion
to go to different servers, by this new A like record.
Another possibility putting the entire DNS in Tor allows is transparent proxying to onion services on a network. A network could run a local authoritative DNS server for *.onion
, and answer to all queries from the DNS in the service descriptor except A/AAAA. For A/AAAA it can assign an ID and encode this ID inside a local routable address (e.g. within 10/8
). This address block is then routed to a Tor proxy that can undo this ID to onion service address conversion and transparently proxy TCP connections - and UDP once this is added to Tor. This would allow devices on this network to use onion services completely obliviously.
One final consideration is that of DNSSEC. Some protocols (e.g. DANE) require DNSSEC to function properly. My initial idea on this is to define every *.onion
as a DNSSEC TA, and put the TA public key in the descriptor (such that it is signed, and therefore trusted).
To conclude this semi brain dump: put the entire DNS in Tor. I think it'd work, please tell me how I did it wrong.