{"id":13552517,"url":"https://github.com/alecmuffett/dohot","last_synced_at":"2025-04-03T03:32:01.873Z","repository":{"id":47140076,"uuid":"276821911","full_name":"alecmuffett/dohot","owner":"alecmuffett","description":"DoHoT: making practical use of DNS over HTTPS over Tor","archived":false,"fork":false,"pushed_at":"2021-11-18T03:53:07.000Z","size":1108,"stargazers_count":234,"open_issues_count":3,"forks_count":11,"subscribers_count":19,"default_branch":"master","last_synced_at":"2024-12-06T19:11:47.290Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/alecmuffett.png","metadata":{"files":{"readme":"README-2020.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-07-03T06:11:24.000Z","updated_at":"2024-12-06T06:22:39.000Z","dependencies_parsed_at":"2022-09-07T15:23:33.034Z","dependency_job_id":null,"html_url":"https://github.com/alecmuffett/dohot","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alecmuffett%2Fdohot","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alecmuffett%2Fdohot/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alecmuffett%2Fdohot/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alecmuffett%2Fdohot/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/alecmuffett","download_url":"https://codeload.github.com/alecmuffett/dohot/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246933421,"owners_count":20857049,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T12:02:05.486Z","updated_at":"2025-04-03T03:31:56.844Z","avatar_url":"https://github.com/alecmuffett.png","language":"Shell","readme":"# DoHoT: making practical use of DNS over HTTPS over Tor\n\nThis is the first document for a new project called `DoHoT` DNS, which I\nhope will grow to help people recoup some privacy in places where they\nhave previously not considered it lacking.\n\n## News/Updates\n\n### 2020/11/02\n\nMeasuring 1.26 million requests to my DoHoT server since July 14th,\nwith a [revised configuration](dnscrypt-proxy.toml)\nper this repository; practical client-side latency analysis is as follows:\n\n* min: 0\n* max: 10726\n* count: 1261084\n* mean: 466.60\n* median: 268\n* median_low: 268\n* median_high: 268\n* median_grouped: 267.57\n* mode: 0\n* stdev: 752.24\n* variance: 565862.02\n* pstdev: 752.24\n* pvariance: 565861.57\n* p1: 0\n* p10: 0\n* p20: 0\n* p25: 0\n* p30: 0\n* p33: 125\n* p40: 183\n* p50: 268\n* p60: 408\n* p66: 474\n* p70: 519\n* p75: 587\n* p80: 683\n* p90: 1112\n* p95: 1531\n* P99: 3686\n\n#### Highlights\n\n* 30% of requests are served from cache\n* 50% of requests are served in less than 270ms\n* 68% of requests are served in less than 500ms (not shown)\n* 90% of requests are served in less than 1200ms\n* 99% of requests are served in less than 3700ms\n* the configuration enforces a timeout of 10000ms; this is rarely reached\n\n### 2020/07/14\n\nI have updated the repo to cite DNSCrypt-Proxy (DNSCP) version\n`2.0.44` by default, and to use the standard configuration files for\nall DoH servers. Also there has been some general configuration\ncleanup - mostly to use DNSCP defaults for timeouts and keepalives -\nand better documentation.\n\n## TL;DR\n\nI set up a DNS stub resolver using *DNS over HTTPS over Tor* at home.\nFor four months - during the UK COVID-19 lockdown / shelter-in-place -\nmy partner and I have lived with it exclusively.  It has worked so\nwell that we haven't noticed any practical change in our internet\nservice experience.\n\n## Goals\n\nWhat I seek with this project is to explain, to encourage, and to\nsimplify adoption of DNS over HTTPS over Tor.\n\n## Disclaimers\n\n* Likely none of this is new.\n* I probably describe nothing that is novel.\n* Other people will have done this before, and are probably doing it\n  now, although arguably from a base of less experience than myself\n  regarding Tor and performance tuning.\n* None of the software I describe has been written by me, but instead\n  has been written by people cleverer and more dedicated than I.\n* DNS experts will almost certainly describe the latency figures that\n  I publish here as \"excessively slow\", \"impractical\", or\n  \"unusable\". I firmly disagree, at least for the domestic or\n  individual user, and I present several months' worth of both numbers\n  and \"24x7 lived experience\" to back up my perspective.\n\n## The Experiment\n\nFor more than four months my home - excluding a small\n[extranet](https://en.wikipedia.org/wiki/Extranet) - has gone utterly\n\"DNS Dark\", so that absolutely no `Do53` traditional UDP or TCP DNS\ntraffic has come from my house.\n\nThis has been during the period of the COVID-19 \"lockdown\" so my\ndomestic network use has greatly increased in this time: streaming\nNetflix \u0026 Amazon Prime, work videoconferencing over Microsoft Teams\nand Google Meet, home banking, shopping, family video over Facebook\nPortal, etc; desktops, laptops, mobile devices, tablets, IoT... the\ninternet has been a critical resource for life, and yet no traditional\nDNS traffic has left my home since February.\n\nTo fulfil the actual need for IP address resolution, I set up a\nRaspberry Pi as a home DNS server - in much the same manner that I\nhave previously operated a [Pi-Hole Ad-Blocker](https://pi-hole.net) -\nexcept on this occasion:\n\n* I configured a `dnscrypt-proxy` resolver listening to port 53\n* set the resolver to exclusively use `DoH` for upstream resolution\n* configured `DoH` to use only the SOCKS5 interface provided by a local `tor` daemon\n* advertised that resolver using DHCP on my home network, and finally...\n* set my firewall to block all network egress to ports 53 \u0026 853, TCP \u0026 UDP\n  * except for permitting the resolver itself to have just enough port 53 access to bootstrap\n\n## Experiment Results Summary\n\nAlmost all of the documentation that I have read - including some\namongst the `dnscrypt-proxy` source code - has told me that `DoHoT`\nwould be laggy, unlivably slow, and a bad idea.  I cannot\nagree. Although DNS-query latency figures have been somewhat inflated,\nmy actual experience of internet usage has been \"business as usual\".\n\nIt's helpful that every four hours `dnscrypt-proxy` prints a summary\nof upstream request latency amongst the loadbalanced pool of resolvers\nthat it is using, and I shall present the statistics for the entirety\nof June 2020, plus a little bit of May and July.\n\nThe headline stats are:\n\n![196 lowest-latency DoHoT fetches from 3 DoH providers, June 2020](img/june-2020.png)\n\n* a pool of 3 `DoH` providers for the initial experiment: A, B, and C\n* 196 data points from May 31st to July 2nd\n* p50 / median request lowest-latency: 193ms\n* p90 request lowest-latency: 372ms\n* p95 request lowest-latency: 425ms\n* max request lowest-latency: 815ms\n\n![sorted distribution of DoHoT fetches from 3 DoH providers, June 2020](img/lowest-latency.png)\n\nManual spot-testing from my extranet suggests that resolution of\n`.com` names that are not in my ISP's upstream resolver cache will\ntake 140 to 170ms to be resolved via `Do53`, and that resolution of a\ndomain in `.cn` can take 670ms.  These numbers are ad-hoc, but I find\nit reassuring that the best-case times for `DoHoT` are in the same\nballpark as survivable normal/worst-case times for `Do53`.\n\n## Why DoHoT?\n\nThe DNS protocol is more than 40 years old, was never designed for\nprivacy, and is broadly instrumented - i.e.: logged, sold, spied-upon,\nand interfered-with - by:\n\n1. Cafes, Hotels, Aircraft, and other \"captive portals\"\n2. Internet Service Providers (ISPs)\n3. The upstream peers and bearer-providers for ISPs\n4. Partner-companies to the above, which monetise the ability to\n   control, manipulate and track DNS results\n5. Nation-state Governments which want to exert control upon peoples'\n   access to information\n\nAs I have written\n[elsewhere](https://medium.com/@alecmuffett/why-every-privacy-activist-should-embrace-dns-over-https-a361e727657f)\nthe launch of the `DoH` protocol presents a marvellous opportunity;\nthe protocol itself has been represented as rather\n[contentious](https://www.theregister.co.uk/2019/09/24/mozilla_backtracks_doh_for_uk_users/)\nbut a careful reading of some of the more\n[critical](https://www.eset.com/blog/business/the-battle-for-dns-and-data/)\n[coverage](https://www.theregister.co.uk/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_feature_becomes_a_standard/)\nsuggests that the criticisms tend to come from people or organisations\nin categories 2 through 5 above, perhaps concerned that\nincreased DNS privacy may impact their business models, revenue,\nincome, or their quiet \"obligations\" to nation-state security\nservices.  as if people being enabled with privacy would somehow be\n\"their fault\".\n\n### DoH as an Opportunity\n\nSome critics ignore the \"first mile\" transport-security benefits of\n`DoH` and instead [frame the concerns](https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/)\nby complaining about problems that `DoH` doesn't actually address; for\ninstance:\n\n[ZDnet article](https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/):\n\u003e The response to DoH's anointment as a major privacy-preserving\n\u003e solution has been downright acid, in some cases. Critics have taken\n\u003e a jab at the protocol on different plains, which we'll try to\n\u003e organize and categorize below:\n\u003e\n\u003e * DoH doesn't actually prevent ISPs user tracking\n\u003e * DoH creates havoc in the enterprise sector\n\u003e * DoH weakens cyber-security\n\u003e * DoH helps criminals\n\u003e * DoH shouldn't be recommended to dissidents\n\u003e * DoH centralizes DNS traffic at a few DoH resolvers\n\nThe cited criticisms are not reasonable because the concerns that are\nraised are generally not for `DoH` to fix:\n\n#### \"DoH doesn't actually prevent ISPs user tracking\"\n\n`DoH` was never meant as a wholesale \"cure\" for ISP user-tracking;\nit's meant to reduce DNS observation, tampering, and interference.\n\n#### \"DoH creates havoc in the enterprise sector\"\n\nI have worked in the \"enterprise sector\" since 1992; I am sorry to be\nglib but this equally glib claim is nonsense.\n\n#### \"DoH weakens cyber-security\"\n\nAgain this is a vague concern - DoH weakens what aspects of security,\nhow, for whom, and to what compensating benefits, to whom? - but also\nit should be noted that the prime weaknesses in cybersecurity are\n\"users\" and \"software\" yet we are somehow content to have more of both\nof those?\n\n#### \"DoH helps criminals\"\n\nHelps criminals? So does \"the internet\" in general - it would not be\nable to have cybercrime without computers.\n\n#### \"DoH shouldn't be recommended to dissidents\"\n\nSo far as I am aware, nobody is recommending `DoH` for \"dissidents\";\n`DoH` is being recommended more broadly to *people who want more privacy*.\n\n#### \"DoH centralizes DNS traffic at a few DoH resolvers\"\n\nAha! This latter concern has some substance, and it is worth\nconsideration; generally there are three aspects to this concern:\n\n1. \"DNS is a 'distributed' protocol, and `DoH` is antithetical to 'distribution'!\".\n  * I deal with this matter extensively in a separate\n    [blogpost](https://medium.com/@alecmuffett/why-every-privacy-activist-should-embrace-dns-over-https-a361e727657f)\n2. \"There are not enough `DoH` providers and users may be deanonymised via analysis of huge data sets!\"\n  * Mozilla has sought to address this concern with their\n    [Trusted Recursive Resolver](https://wiki.mozilla.org/Trusted_Recursive_Resolver) program;\n    but simplistically it seems logical that the proper solution to \"too\n    few\" `DoH` providers is to encourage *more* of them, not *fewer*.\n3. \"A small number of *Big Data Companies* will get all the tracking information, instead of us!\"\n  * This is an actionable concern, and one where we can make an improvement well beyond `DoH` let alone `Do53`.\n\nThe fear that \"Big Data Companies\" will mine `DoH` request data for\nprofit is valid and is one which the likes of (e.g.)  Mozilla are\nalready working on\n([see point 2, here](https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozillas-dns-over-https-doh/)) -\nbut it's one where the internet is also already equipped with a well-tested solution:\n[Tor](https://www.torproject.org).\n\n### Why Tor, and why use DoH over Tor?\n\nOne of the goals of the Tor project is to provide anonymity of clients\nfrom servers; there are *other* benefits to Tor and Tor \"Onion\nNetworking\", but this is the most popular rationale for Tor's use.\n\nIt's also a rationale which meshes insanely well, with `DoH`.\n\nTor does not support UDP and therefore cannot provide anonymity for\n`Do53` traffic, but because `DoH` is normal HTTPS it can be carried\nefficiently over Tor connections.\n\nTherefore:\n\n* if the individual provides and controls a local `Do53` resolver,\n  not least for normal, \"legacy\" use - being offered by DHCP, etc.\n* and that resolver is configured to resolve upstream, using `DoH`\n* and that resolver is configured to strip linkable identifiers from `DoH` requests\n* and that resolver connects to various major `DoH` providers over Tor\n* then the provider will not know who is making the request, nor from where it came, nor will be able to \"link\" requests\n\nThis architecture follows Tor's\n[\"anonymity loves company\"](https://www.freehaven.net/doc/wupss04/usability.pdf)\nmodel for privacy, and **offers far better privacy, integrity,\nunblockability and untrackability than anything** offered by `Do53`,\n`DoT` (DNS over TLS on port 853), raw `DoH` or indeed any other DNS\nlookup-service.\n\nAnd the technology already exists, is free, and my data and experience is that it\nworks really well for home users, perhaps more.\n\n## How do I build a DoHoT server?\n\n[See here](INSTALL.md); this project is project evolving and I will be updating it.\n\n## Surely there have been some issues?\n\nThere are a few patterns or weird experiences that I have noted:\n\n### The Ubiquity WiFi dashboard will complain about \"latency\", indefinitely\n\n![clip of dashboard](img/unifi-complaints.png)\n\nMy WiFi router dashboard perpetually complains about \"High DNS\nLatency\", which only goes to show that expectations of \"low latency\"\nin modern DNS are lower than what humans are actually okay with.\n\n### Chromecast honours DHCP's DoHoT DNS server, but also tries to use 8.8.8.8\n\nApproximately every 20 seconds my Chromecast attempts to send a\nrequest to 8.8.8.8, which my firewall drops and logs. I find this\ninteresting, but it's not really a DoHoT problem so much as a matter\nof my choice to block any non-DoHoT DNS requests.\n\nThe Chromecast - including upgrades - still works fine, so I am\nignoring this matter.\n\n### \"Human Error\" is surprisingly common\n\nEvery so often I visit somewhere that causes me to temporarily\nhardcode my laptop or phone DNS server to 1.1.1.1 or 8.8.8.8; then I\ncome home and the device stops working until I remember to reset the\nDNS to be the automatic DHCP default.\n\nAgain I consider this to be due to my choice to block any non-DoHoT DNS requests, but it's probably\nalso good discipline from a privacy perspective.  I actually used to believe that my privacy self-discipline was better than this, but I was wrong.\n\nThis situation is interesting to compare to criticism from DoH\ncritics who argue that it is they - your service provider, your\nISP - rather than you, who should be limiting access to alternative\nsources of DNS resolution.\n\n### Absolutely nothing at home is using Port 853\n\n`DoT` / DNS-over-TLS on port 853 is touted by DNS experts as the \"proper\" solution\nfor DNS privacy and security, but I have not yet seen any devices or\napplications actually using it.\n\n## Footnotes and FAQs\n\n### Why are you only publishing 4 weeks' worth of graphs?\n\nI set this up in early February, and then COVID-19 happened, and I\nbasically forgot about it; however my server *does* retain slightly\nmore than 4 weeks worth of logs.  I will try to do better in future.\n\n### Why are you not annotating the DoH providers?\n\nTo do so would not seem relevant; after some advanced technical\nexperimentation with DoH and\n[EOTK](https://github.com/alecmuffett/eotk) I simply picked three\nordinary DoH providers and set them up as resolvers in\nDNSCrypt-Proxy.\n\nSince the whole point of using Tor is to divorce the server from the\nclient, I believe that - especially given the automatic load-balancing\nof DNSCrypt-Proxy - so long as the results appear consistent it\ndoesn't really matter who won the race to give the first response; so\nwhy risk being seen to pick favourites?\n\n### Did the latency drop significantly around June 6th?\n\nLooking at the graph above, I noticed that \"cliff edge\" too. I'm not\nsure, but after checking with some members of the Tor project, some\nnewer, faster Tor infrastructure may have become more prevalent around\nthat time. Another member of the Tor community reminded me that it may\nbe that my Tor instance changed \"guard\" to a faster one.\n","funding_links":[],"categories":["Shell"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falecmuffett%2Fdohot","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falecmuffett%2Fdohot","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falecmuffett%2Fdohot/lists"}