Wikimedia DNS(meta.wikimedia.org)
meta.wikimedia.org
Wikimedia DNS
https://meta.wikimedia.org/wiki/Wikimedia_DNS
55 comments
I have been using https://nextdns.io for quite some time now and never looked back, highly recommend it! Having a built-in pi-hole available from anywhere and without having to manage it for my whole family is why i would recommend it...
Personally I don't know why people aren't just using a local recursive DNS resolver rather than external services like this. I wonder when the root servers etc will start supporting DoH/DoT.
I wanted to, but the classic villain, systemd, fights its damndest to retain control of local DNS resolution.
If there was a bulletproof, straightforward way to run it, I am there (not Nix). I probably gave up too early, but my initial attempts with Unbound broke all internet access until I was able to reverse my configuration.
If there was a bulletproof, straightforward way to run it, I am there (not Nix). I probably gave up too early, but my initial attempts with Unbound broke all internet access until I was able to reverse my configuration.
You can make /etc/resolv.conf immutable using chattr +i and then nothing can mess with your DNS. Of course if your apps aren't using /etc/resolv.conf and going direct to systemd-resolved then you'll have to deal with that instead of unbound/kresd/etc.
See, that feels like bandaging over the problem. A solution that is probably fine, until it is not.
Why not permit systemd-resolved to act as the local resolver along with resolved.conf? You can use Unbound listening on whatever is free on (ipv4)127.0.0.0/8 and (ipv6)[:1]:9953 (or any other free port), and configure resolved.conf to use that local address as the "upstream" DNS= option.
You're probably going to still need Unbound to talk to an encrypted DNS server on the Internet (DoH or DoT), or else your ISP will be capable of intercepting and manipulating your queries.
https://www.freedesktop.org/software/systemd/man/systemd-res...
https://www.freedesktop.org/software/systemd/man/resolved.co...
You're probably going to still need Unbound to talk to an encrypted DNS server on the Internet (DoH or DoT), or else your ISP will be capable of intercepting and manipulating your queries.
https://www.freedesktop.org/software/systemd/man/systemd-res...
https://www.freedesktop.org/software/systemd/man/resolved.co...
That feels like a brilliant strategy. Theoretically only ever requiring a one line configuration change if I ever need to reverse it.
It would be a lot better if systemd would play nicely, but this is pretty minimal jank.
Edit: and immediately ran into some trouble while trying to configure this. Definitely a situation where the documentation assumes you already know how DNS works
It would be a lot better if systemd would play nicely, but this is pretty minimal jank.
Edit: and immediately ran into some trouble while trying to configure this. Definitely a situation where the documentation assumes you already know how DNS works
Auth dns is a different beast. There are efforts in the IETF to work on it:
https://datatracker.ietf.org/doc/draft-ietf-dprive-unilatera...
https://datatracker.ietf.org/doc/draft-ietf-dprive-unilatera...
The average user is not capable of running that themselves.
Your ISP can potentially see queries if you do this also, so if you don't trust your ISP, or worry about what they may be forced to do by your government, it may not suit.
Further, DNS really benefits from caching as it scales up. As someone who runs my own resolver locally myself, I can attest to the sometimes long delay to resolve a hostname (requiring multiple external requests as the tree from root server is recursively queried).
I still run my own recursive resolver, I find it the best option overall, so ultimately I agree with your statement. But like anything there are trade-offs.
Your ISP can potentially see queries if you do this also, so if you don't trust your ISP, or worry about what they may be forced to do by your government, it may not suit.
Further, DNS really benefits from caching as it scales up. As someone who runs my own resolver locally myself, I can attest to the sometimes long delay to resolve a hostname (requiring multiple external requests as the tree from root server is recursively queried).
I still run my own recursive resolver, I find it the best option overall, so ultimately I agree with your statement. But like anything there are trade-offs.
Because your ISP will hijack the queries it makes.
That really depends.
While that could very well be the case, I find it funny people tend to assume their ISP does this, and also assume that trusting large corporates (often outside the jurisdiction they are in and subject to foreign law enforcement requests) with their data is automatically preferable to their ISP.
In the absence of widely-deployed ECH the ISP can potentially still see all hostnames visited from SNI field.
Some fears you commonly hear about from US users, like ISPs selling user browsing data, is illegal in other territories like the EU. So this calculation is different in various contexts. Where ISPs are not able to monetize it you would wonder what the business case for the (very expensive) snooping of queries is.
While that could very well be the case, I find it funny people tend to assume their ISP does this, and also assume that trusting large corporates (often outside the jurisdiction they are in and subject to foreign law enforcement requests) with their data is automatically preferable to their ISP.
In the absence of widely-deployed ECH the ISP can potentially still see all hostnames visited from SNI field.
Some fears you commonly hear about from US users, like ISPs selling user browsing data, is illegal in other territories like the EU. So this calculation is different in various contexts. Where ISPs are not able to monetize it you would wonder what the business case for the (very expensive) snooping of queries is.
Don't they only hijack the queries that you send to the ISPs DNS servers? Or do they MITM all DNS requests no matter the destination DNS server and hijack them? A local recursive resolver will generally not forward requests to the ISPs DNS servers.
It’s on the honor system: if you’re worried about the problems encrypted DNS prevents, your ISP is the most likely threat.
With traditional DNS, your ISP can monitor everything you query passively. They also see every host name you connect to using TLS with SNI. Since that’s passive, you don’t know who they share that with except to the extent that you trust your government’s privacy law’s & enforcement.
They can also spoof DNS replies if they want to send you to a different server. This used to be common for Wi-Fi login systems when most of the web ran on HTTPS but TLS breaks it now. This is an active attack which is usually pretty blatant so you won’t see it commonly on residential ISPs.
DNS over TLS/HTTPS breaks all of the passive DNS monitoring & active spoofing. It does not help with TLS SNI monitoring but there’s an Encrypted Client Hello extension being tested now for that.
With traditional DNS, your ISP can monitor everything you query passively. They also see every host name you connect to using TLS with SNI. Since that’s passive, you don’t know who they share that with except to the extent that you trust your government’s privacy law’s & enforcement.
They can also spoof DNS replies if they want to send you to a different server. This used to be common for Wi-Fi login systems when most of the web ran on HTTPS but TLS breaks it now. This is an active attack which is usually pretty blatant so you won’t see it commonly on residential ISPs.
DNS over TLS/HTTPS breaks all of the passive DNS monitoring & active spoofing. It does not help with TLS SNI monitoring but there’s an Encrypted Client Hello extension being tested now for that.
At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. SNI gets them past the multiple sites on a single IP, but even encrypted Hello might only hide your activities in the vanishingly rare instances where IPs are actually shared. The obvious analogy is sending postal mail to an address without the recipient's name: it's still pretty obvious who you're communicating with.
Maybe I'm just bitter because I've found DoH (and even DoT) to be slow and occasionally unreliable. Even using Cloudflare, which is my fastest DNS, I see my local caches hitting strange resolve errors or in the minimum, durations 4-10x slower than good old UDP.
Maybe I'm just bitter because I've found DoH (and even DoT) to be slow and occasionally unreliable. Even using Cloudflare, which is my fastest DNS, I see my local caches hitting strange resolve errors or in the minimum, durations 4-10x slower than good old UDP.
> At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname.
Shared hosting breaks that. If I connect to an IP used by AWS, Akamai, Fastly, etc. there are literally millions of things I could be using but the SNI header will tell them which one.
As a practical example, if a school administrator in Texas sees a connection to 104.16.12.208 they only know that someone is connecting to one of the millions of sites behind Cloudflare. SNI tells them it’s Planned Parenthood and they can call the police to report an offense against the church.
Shared hosting breaks that. If I connect to an IP used by AWS, Akamai, Fastly, etc. there are literally millions of things I could be using but the SNI header will tell them which one.
As a practical example, if a school administrator in Texas sees a connection to 104.16.12.208 they only know that someone is connecting to one of the millions of sites behind Cloudflare. SNI tells them it’s Planned Parenthood and they can call the police to report an offense against the church.
I can't find it right now, but there was a study about this that concluded shared hosting actually mostly doesn't break IP to domain correlation.
I'm convinced that (American) ISPs do passively log unencrypted DNS requests, so replacing their DNS with things like quad9 and not using dot/doh is mostly pointless, but the question was: will the isp hijack the response? I've never heard of one doing that, you?
When in doubt, rely on Comcast for an example of bad behavior:
https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...
https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...
They MITM all DNS requests no matter the destination DNS server and hijack them. (Clarification: every ISP can. Some, but not all, actually do so.)
> Some, but not all, actually do so
Can you name one that does?
Can you name one that does?
I've expected to find technical details, it's on another page - https://wikitech.wikimedia.org/wiki/Wikidough
Excerpt:
> Wikidough is currently deployed as an anycasted service on all our PoPs [6 datacenters].
> Our current deployment of Wikidough runs dnsdist 1.6.1 and PowerDNS Recursor 4.6.0. Both of these are installed from backported Debian sid packages
Excerpt:
> Wikidough is currently deployed as an anycasted service on all our PoPs [6 datacenters].
> Our current deployment of Wikidough runs dnsdist 1.6.1 and PowerDNS Recursor 4.6.0. Both of these are installed from backported Debian sid packages
Not to be confused with DNS over Wikipedia[0]
0. https://news.ycombinator.com/item?id=22790425
0. https://news.ycombinator.com/item?id=22790425
Does it resolve queries for pirate websites like Pirate Bay, Sci-Hub, etc?
Apologies for the janky formatting as I'm on mobile and copying from a tmux session but: yes, it seems that it does.
$ dig @wikimedia-dns.org +tls libgen.is
; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @wikimedia-dns.org +tls libgen.is
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5711
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;libgen.is. IN A
;; ANSWER SECTION:
libgen.is. 3600 IN A 193.218.118.42
;; Query time: 283 msec
;; SERVER: 2001:67c:930::1#853(wikimedia-dns.org) (TLS)
;; WHEN: Wed Sep 06 20:57:49 EDT 2023
;; MSG SIZE rcvd: 54Given how much it talks about fighting censorship and how much Wikipedia engages in political activism, I 300% expect them to censor something or another given enough time to transpire.
> We cannot recommend external resolver services such as those run by Google, Cloudflare, Quad9, among others, for a variety of reasons. We have no control over how these services are run or what private data is logged. Even though most of these services have explicit privacy policies, they do log some data and we have no control or insight into that.
I find it very ironic that Wikipedia themselves talk about the privacy/logging practices of other DNS services but neglect to indicate a clear policy for their own service. I would imagine it's based off the regular Wikipedia privacy policy but they should clearly indicate that.
I find it very ironic that Wikipedia themselves talk about the privacy/logging practices of other DNS services but neglect to indicate a clear policy for their own service. I would imagine it's based off the regular Wikipedia privacy policy but they should clearly indicate that.
It's in the privacy policy section >Wikimedia DNS is still being beta-tested and evaluated both internally and with our community. As such, there are no guarantees of the reliability or future availability of the service, and there is no formal privacy policy published yet. That said, our current configuration (visible here: dnsdist.conf.erb and recursor.conf.erb) does not currently log anything.
We currently intend, in broad strokes, to adhere to the Foundation's long-standing values around privacy-related issues, as well as to Mozilla's TRR policy, when and if this service is more-formally launched in the future.
Couldn't agree more.
It's very easy to throw shade at other providers, then not provide those assurances in your own service.
It seems like a weak attempt to throw shade at other providers without substantiated claims. Take Quad9 for instance, they have plenty of information in their transparency report regarding their service, over and above what Wikimedia has provided.
It's very easy to throw shade at other providers, then not provide those assurances in your own service.
It seems like a weak attempt to throw shade at other providers without substantiated claims. Take Quad9 for instance, they have plenty of information in their transparency report regarding their service, over and above what Wikimedia has provided.
[Disclosure: I'm an engineer at Wikimedia involved with this project]
Wikimedia hasn't actually formally launched or announced this project. We've been working on it in the background for a long time, and we've just recently reached the point of wanting to do a slightly-broader round of both beta-testing the service and soliciting other meta-feedback on the plans with our Wikipedia editor and reader communities.
Unfortunately, the only way we can do this testing and feedback round is through a public interface like meta-wiki. And of course, once we've put out public information on how to use and access it, it's being picked up on various social media and news sites and publicized beyond what we desired at this stage. We knew that was a risk, but it's still a little jarring how fast it has shown up in places like this HN thread.
We absolutely plan to have a published privacy policy and other such things in place when the service is actually, officially launched. Launching some time in the future is not yet certain to even happen, as there is still internal evaluation/debate of the project's various costs and risk/benefit going on during this phase as well.
Wikimedia hasn't actually formally launched or announced this project. We've been working on it in the background for a long time, and we've just recently reached the point of wanting to do a slightly-broader round of both beta-testing the service and soliciting other meta-feedback on the plans with our Wikipedia editor and reader communities.
Unfortunately, the only way we can do this testing and feedback round is through a public interface like meta-wiki. And of course, once we've put out public information on how to use and access it, it's being picked up on various social media and news sites and publicized beyond what we desired at this stage. We knew that was a risk, but it's still a little jarring how fast it has shown up in places like this HN thread.
We absolutely plan to have a published privacy policy and other such things in place when the service is actually, officially launched. Launching some time in the future is not yet certain to even happen, as there is still internal evaluation/debate of the project's various costs and risk/benefit going on during this phase as well.
Beta service or not I still think it's a good idea to have a policy up as soon as possible, even if it's a broad one saying that this is still in development and all queries are logged for diagnostics or something. Considering how this is on HN it's going to be on Reddit and Twitter soon and it'll explode from there.
Sorry, I didn't think about the impact of posting this here, it showed up on IRC first though.
>showed up on IRC
Does wikimedia have an IRC server?
Does wikimedia have an IRC server?
They don't have an official one, but many de-facto rooms exist on other networks operated by volunteers. Mainly on Libera chat.
https://en.wikipedia.org/wiki/Wikipedia:IRC has more detail.
https://en.wikipedia.org/wiki/Wikipedia:IRC has more detail.
Not sure, but the link was on OFTC.
I think all of that is completely understandable when launching a new service.
But I would refrain from commenting on other services, if you don't have those assurance in place yourself.
But I would refrain from commenting on other services, if you don't have those assurance in place yourself.
I understand why they likely don't, but I wish they'd run this service on wikipedia.org.
As is, this is just another DoT/DoH service for censors to block. If it was run on the main Wikipedia domain/IPs, then it would force censors into choosing collateral damage (blocking all of Wikipedia) or allowing this service to be accessible.
As is, this is just another DoT/DoH service for censors to block. If it was run on the main Wikipedia domain/IPs, then it would force censors into choosing collateral damage (blocking all of Wikipedia) or allowing this service to be accessible.
> I understand why they likely don't, but I wish they'd run this service on wikipedia.org.
I understand this sentiment, but it may be technically complex, for a few reasons.
"wikipedia.org" has over 800 hostnames under it, corresponding to encyclopedias in various languages. Which language host should they run it under? Or create a new DNS record for it altogether? What benefit would that bring?
Is it more important to run on the domain "wikipedia.org" or the IP addresses underlying the hosts in that domain? Will censors block only the DNS resolution of the servers, or their IP addresses, or both?
Now the IP addresses corresponding to the language-based wikis may be special indeed. I suspect that they are "anycast" addresses and that a single A or AAAA record corresponds to multiple geographically-distributed hosts around these United States. It is very likely that the specialized front ends for these wiki servers are not tooled up to host DNS services such as this, especially experimental ones that they're constantly messing with.
And yeah, that's the main thing: this is an experimental beta service that's barely public. I don't think they want something so unreliable to be riding coattails of production services. I know I don't want that.
Censorship is an unfortunate spectre here, but think about it, if the censors really wanted to blackhole the DoT/DoH servers then they might just throw out the baby with the bathwater, and not really care about the collateral damage, just to punish Wikipedia for trying to do this.
I understand this sentiment, but it may be technically complex, for a few reasons.
"wikipedia.org" has over 800 hostnames under it, corresponding to encyclopedias in various languages. Which language host should they run it under? Or create a new DNS record for it altogether? What benefit would that bring?
Is it more important to run on the domain "wikipedia.org" or the IP addresses underlying the hosts in that domain? Will censors block only the DNS resolution of the servers, or their IP addresses, or both?
Now the IP addresses corresponding to the language-based wikis may be special indeed. I suspect that they are "anycast" addresses and that a single A or AAAA record corresponds to multiple geographically-distributed hosts around these United States. It is very likely that the specialized front ends for these wiki servers are not tooled up to host DNS services such as this, especially experimental ones that they're constantly messing with.
And yeah, that's the main thing: this is an experimental beta service that's barely public. I don't think they want something so unreliable to be riding coattails of production services. I know I don't want that.
Censorship is an unfortunate spectre here, but think about it, if the censors really wanted to blackhole the DoT/DoH servers then they might just throw out the baby with the bathwater, and not really care about the collateral damage, just to punish Wikipedia for trying to do this.
They describe this as a small scale beta so I’d imagine a key part of deciding whether to go forward would be that question. It’d be harder for a government to block all TCP 443 to Wikipedia but they’d also be maximizing the likelihood of legal repercussions.
Are there legal repercussions for hosting DNS? I guess there are entries for “naughty” sites (as defined per jurisdiction), but seems pretty innocuous.
I’m sure that’d be the defense they’d make but remember that laws and courts aren’t board games. If someone passes a law forbidding anyone from providing access to something or assisting with that access, you can’t rule out getting dragged into court because your DNS service helped someone get content their ISP’s servers blocked. Google or Cloudflare have the same risk but also orders of magnitude more lawyers than Wikipedia.
[deleted]
Isn't the wikimedia domain used for some external assets included in wikipedia articles? Or am I misremembering?
Commons is hosted on commons.wikimedia.org, but the actual encyclopedias have an internal method to access media on the Commons server, and don't use external <img> links like you would normally see.
If Wikipedia funds this
is not a bit out of scope?
They keep asking for money to help Wikipedia, and I have no issue with that.
But if they fund ventures like this out of the same pot I have a small issue with that.
They keep asking for money to help Wikipedia, and I have no issue with that.
But if they fund ventures like this out of the same pot I have a small issue with that.
[deleted]
> Wikimedia DNS helps prevent some surveillance and censorship of our wikis and other websites by securing DNS lookups.
Seems completely in line with their mission.
Seems completely in line with their mission.
Sorta related but Wikipedia become known for having links for stuff google delists and was the most reliable way to find the official url for things.
The editors noticed and have started removing links from site pages now.
The editors noticed and have started removing links from site pages now.
Your description is very vague but if you have a substantial source that goes into detail about whatever phenomenon it is you're describing then it might make a good submission on its own.
It's not worth a full post but one example of where Wikipedia still works is to find the current link for The Pirate Bay which often changes. One example where the link is being censored on Wikipedia is Kiwi Farms
thepiratebay.org has always been the domain, it never changed (expect for a brief period where they lost control of it due to internal infighting). You're probably thinking of something else.
Curious when encrypted sni and ech will be mainstream