-
14 votes
-
Pirate site not impressed by global DNS blocking order
66 votes -
Typo leaks millions of US military emails to Mali web operator
28 votes -
Local DNS resolution for server?
I have to preface this question with a disclaimer that I am an eager learner of Linux and servers in general, but I'm still a beginner and often run into roadblocks. Current setup: Raspberry Pi 3...
I have to preface this question with a disclaimer that I am an eager learner of Linux and servers in general, but I'm still a beginner and often run into roadblocks.
Current setup:
- Raspberry Pi 3 with Adguard Home acting as primary DNS
- unRAID server with Adguard Home acting as secondary DNS
- About a dozen other containers running on same server
- DHCP is handled by my router
Goal:
- provide local DNS names for the containers running in unRAID so I don't have to enter IP:Port (e.g, calibre.local) which also has the side benefit saving the various username/password combos into Bitwarden with an actual domain attached to it instead of 14 occurrences of 192.168.x.x
Additional info:
I had PiHole running on the Pi before as the primary and only DNS previously. And I seem to recall you could put IP:Port as a custom DNS and have it resolve. AGH does have a feature for DNS Rewrites but it does not allow for port numbers, IPs only. I switched to AGH because it seems to be more effective at blocking ads, which is likely more a function of the provided DNS blocklists out of the box as opposed to what I was doing in Pihole. I would prefer to stick with AGH for adblocking/DNS if possible.
I looked into just modifying host files on the main computers I touch these apps from, but again, can't include port. What is a good solution for this? Preferably something approachable for a newb like me.
11 votes -
Understanding DNS resolvers by writing a simple one in Go
7 votes -
Understanding how Facebook disappeared from the internet
11 votes -
How accurate are whois records?
I attempted to purchase a domain this week without first using whois. The registrar's search function got stuck in an infinite load animation. I then checked the whois to find the domain was...
I attempted to purchase a domain this week without first using whois. The registrar's search function got stuck in an infinite load animation. I then checked the whois to find the domain was registered about 4 hours prior by a different registrar. Bad luck I guess but I can't help feeling paranoid that this was a domain front run.
My question is how much leeway is there for a registrar reporting the registration time?
9 votes -
EFF's 2020 in review: How we saved .org
10 votes -
Protect domains that don’t send email
13 votes -
A Google Cloud support engineer solves a tough DNS case
7 votes -
Victory! ICANN rejects .ORG sale to private equity firm Ethos Capital
22 votes -
A high-level overview of the background of the ".org" top-level domain and what happened with its recent attempted sale to a private equity firm
12 votes -
ICANN board withholds consent for a change of control of the Public Interest Registry (PIR) | The ICANN board withholds consent to transfer .org to Ethos Capital
27 votes -
Building a secure DNS infrastructure like SecureDNS.eu
5 votes -
Cloudflare announces free 1.1.1.2 and 1.1.1.3 DNS resolvers that block malware and/or adult content
14 votes -
CIRA Canadian Shield, DNS Resolution Service
5 votes -
Firefox has started enabling DNS-over-HTTPS by default for all US-based users
33 votes -
Why I voted to sell .ORG
28 votes -
Save .org: Help stop the sale of the Public Interest Registry to a Private Equity Firm
34 votes -
A new tracking technique using CNAME aliases to circumvent third-party cookie restrictions is blockable using a Firefox DNS API, but not in Chrome
18 votes -
ISPs lied to Congress to spread confusion about encrypted DNS, Mozilla says
15 votes -
Help me get my head around DNSCrypt and DoH/DoT
I want to adopt these technologies b/c I'm moving to a home w/o WiFi: I'll only use mobile networks in order to save some money. But the general pipeline and setup are hard to digest, and I'm not...
I want to adopt these technologies b/c I'm moving to a home w/o WiFi: I'll only use mobile networks in order to save some money. But the general pipeline and setup are hard to digest, and I'm not sure if I really understand what are the implications for my privacy, except for the fact that DNS queries are encrypted so I don't leak domain names. This is especially important to me because Turkish internet law and the censorship mechanism is really intrusive, with DPI & DNS blocking. My current ISP does not fiddle with my HTTPS traffic, but I won't have that with my mobile network.
I'm also considering a VPN, but major VPNs are blocked here. To what extent do the purposes of VPNs and these DNS solutions overlap? Assuming most of my important traffic is over HTTPS+DoH/T, how safe am I, and most importantly how much can I penetrate the censorship mechanisms?
6 votes -
Centralised DNS-over-HTTPS is bad for privacy, in 2019 and beyond
7 votes -
The dirty business of hosting hate online
11 votes -
A deep dive on the recent widespread DNS hijacking attacks
8 votes -
Microsoft Azure data deleted because of DNS outage
6 votes -
I tried to block Amazon from my life. It was impossible
13 votes -
Bomb threat, sextortion spammers abused weakness at GoDaddy.com
7 votes -
DNS security is a decades-old issue that shows no signs of being fully resolved. Here's a quick overview of some of the problems with proposed solutions and the best way to move forward.
9 votes -
DNS Privacy
11 votes -
Best for Privacy: Local Recursive DNS vs Cloudflare's DNS over HTTPS
I'm trying to decide what option I prefer here in terms of privacy. I'm curious of other's opinions on the issue, and if anyone has a better solution to offer more privacy. Option 1: Hosting a...
I'm trying to decide what option I prefer here in terms of privacy. I'm curious of other's opinions on the issue, and if anyone has a better solution to offer more privacy.
Option 1: Hosting a local recursive DNS
I currently have a device running Pi-hole on my local network. I recently set it up as a recursive DNS server using unbound. This allows me to no longer rely on a public DNS such as GoogleDNS, OpenDNS, Cloudflare, etc. for my queries, and just point straight to the root servers.
Pro: I removed a "pair of eyes" (Public DNS) out of the equation
Con: All my queries are not encrypted so my ISP (and potentially others) can still see my DNS queries
Option 2: Using DNS over HTTPS (DoH) using Cloudflare's client
With this option I would use Cloudflare's cloudflared daemon they provide on their website. This would allow all my queries to be encrypted when sending them to Cloudflare.
Pro: Encrypted DNS queries from my local network -> Cloudflare's servers. My ISP can no longer see my DNS queries
Security Pro: Helps prevent MitM attacks
Con: I now have a Public DNS back in the equation, which I have to put some trust into. Also, my queries are most likely only encrypted from my local network -> Cloudflare's network. When Cloudflare has to do the recursion, those queries may be not encrypted (my assumption is they will most likely be not encrypted)
Possible Con: Does Server Name Indication (SNI) "leaking" apply to DNS queries at all? If so, then my query is revealed anyways right?
As a note, I am nowhere near an expert on the specifics of DNS, so some of my assumptions on how things work may be super wrong!
6 votes -
Firefox 62 Nightlies: Improving DNS Privacy in Firefox
Firefox recently introduced DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) in nightly builds for Firefox 62. DoH and TRR are intended to help mitigate these potential privacy and...
Firefox recently introduced DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) in nightly builds for Firefox 62.
DoH and TRR are intended to help mitigate these potential privacy and security concerns:
- Untrustworthy DNS resolvers tracking your requests, or tampering with responses from DNS servers.
- On-path routers tracking or tampering in the same way.
- DNS servers tracking your DNS requests.
DNS over HTTPs (DoH) encrypts DNS requests and responses, protecting against on-path eavesdropping, tracking, and response tampering.
Trusted Recursive Resolver (TRR) allows Firefox to use a DNS resolver that's different from your machines network settings. You can use any recursive resolver that is compatible with DoH, but it should be a trusted resolver (one that won't sell users’ data or trick users with spoofed DNS). Mozilla is partnering with Cloudflare (but not using the 1.1.1.1 address) as the initial default TRR, however it's possible to use another 3rd party TRR or run your own.
Cloudflare is providing a recursive resolution service with a pro-user privacy policy. They have committed to throwing away all personally identifiable data after 24 hours, and to never pass that data along to third-parties. And there will be regular audits to ensure that data is being cleared as expected.
Additionally, Cloudflare will be doing QNAME minimization where the DNS resolver no longer sends the full original QNAME (foo.bar.baz.example.com) to the upstream name server. Instead it will only include the label for the zone it's trying to resolve.
For example, let's assume the DNS resolver is trying to find foo.bar.baz.example.com, and already knows that ns1.nic.example.com is authoritative for .example.com, but does not know a more specific authoritative name server.
- It will send the query for just baz.example.com to ns1.nic.example.com which returns the authoritative name server for baz.example.com.
- The resolver then sends a query for bar.baz.example.com to the nameserver for baz.example.com, and gets a response with the authoritative nameserver for bar.baz.example.com
- Finally the resolver sends the query for foo.bar.baz.example.com to bar.baz.example.com's nameserver.
In doing this the full queried name (foo.bar.baz.example.com) is not exposed to intermediate name servers (bar.baz.example.com, baz.example.com, example.com, or even the .com root nameservers)
Collectively DNS over HTTPs (DoH), Trusted Recursive Resolver (TRR), and QNAME Minimization are a step in the right direction, this does not fix DNS related data leaks entirely:
After you do the DNS lookup to find the IP address, you still need to connect to the web server at that address. To do this, you send an initial request. This request includes a server name indication, which says which site on the server you want to connect to. And this request is unencrypted.
That means that your ISP can still figure out which sites you’re visiting, because it’s right there in the server name indication. Plus, the routers that pass that initial request from your browser to the web server can see that info too.So How do I enable it?
DoH and TRR can be enabled in Firefox 62 or newer by going to about:config:- Set network.trr.mode to 2
- Here's the possible network.trr.mode settings:
- 0 - Off (default): Use standard native resolving only (don't use TRR at all)
- 1 - Race: Native vs. TRR. Do them both in parallel and go with the one that returns a result first.
- 2 - First: Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
- 3 - Only: Only use TRR. Never use the native (after the initial setup).
- 4 - Shadow: Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.
- 5 - Off by choice: This is the same as 0 but marks it as done by choice and not done by default.
- Here's the possible network.trr.mode settings:
- Set network.trr.uri to your DoH Server:
- Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query
(but you can use any DoH compliant endpoint)
- Cloudflare’s is https://mozilla.cloudflare-dns.com/dns-query
- The DNS Tab on about:networking will show which names were resolved using TRR via DoH.
Links:
A cartoon intro to DNS over HTTPS
Improving DNS Privacy in Firefox
DNS Query Name Minimization to Improve Privacy
TRR PreferencesI'm not affiliated with Mozilla or Firefox, I just thought ~ would find this interesting.
13 votes -
This is how internet regulation can go really wrong
4 votes