Malaysia backtracks on DNS redirection decision
thesun.my
thesun.my
stubby is a localhost DNS proxy that can work for any app | browser | etc. on a network and use DoT or DoH to any of the common providers.
Given the ease with which national ISPs can MiTM these | intercept calls to Cloudflare | Quad9 | AdGuard etc. it might be good to extend either stubby or it's docs to let people know how to use it access | establish a much broader DNS proxy network to allow for indirect non obvious lookups.
People having their unique implementation of punctuation marks irks me...
It's one of many conventional symbols for OR, more common in the pure ASCII days due to a lack of ∧ , ∨ , ¬ et al.
Which rock have you lived under that you've never seen it used an OR before?
People imposing their limited experience of the wide world upon others would certainly irk some, but rest easy, I've not taken offence at your odd assumption of non existent universal convention.
EDIT: Backus uses the asymmetric overbarred "or" in 1959, but by 1963 the | we know and love has already taken its place (that ASCII standardisation didn't start until 1961 may have something to do with this?)
https://www.softwarepreservation.org/projects/ALGOL/paper/Ba...
Some non-alphanumeric characters add brevity and have been more or less adopted by the mainstream, such as ~ being more ergonomic than approximately or approx. Comma, slash, semicolon; these are the ORs of written English and are already the minimal characters count.
I mildly like pipe as you use it but feel it is more confusing and distracting than anything else. A comma or slash would have not interrupted the reading of the sentence. Optimizing for the reader rather than the writer seems a good default position.
Edit: you replied elsewhere using pipe with parentheses or curly braces; very, very clear in those cases. Had you used that in your original, I would have had no confusion
> that can work for any app | browser | etc. on a network
That is an English clause, not a mathematical expression. You even have the abbreviated form of et cetera there.
> non existent universal convention
In English there is a convention for listing alternatives: commonly forward-slashes with no space between them, like 'this/that', or with commas and conjunctions, like 'this, or that'. Or make your life easy, and use some other collective noun such as 'platforms'.
> a lack of ∧ , ∨ , ¬ et al.
English convention dictates 'et al' (or et alia) be used to list authors or people, rather than inanimate objects. Or you could use a collective noun here, too: 'mathematical symbols'.
DNS has a decentralised architecture designed to be resilient to failures.
DoT, DoH and similar address the privacy aspect of the unencrypted by default DNS traffic.
None of the existing DNS, DNS extensions, DoT, DoH can circumvent serious censorship attempts at scale due to name resolution requests being encapsulated in an IP packet that exposes enough metadata that (destination address and port number) to allow the packet to be altered, redirected, dropped or blackholed even if the packet is encrypted or obfuscated. Traffic bound to a specific IP address or to a specific TCP or UDP port is the easiest to curb, it does not even require the manual intervention and is widely used by intrusion detection systems to automatically block the detected in real time malicious traffic.
The censorship resistance requires a complete replacement of DNS that would be akin to the GNU Naming System[0], which fulfils all three objectives: it is a decentralised, privacy-preserving, censorship-resistant domain name resolution protocol.
Having gone through https://dnsprivacy.org/ (which is very disorganised, to be fair), I fail to see how stubby could be of any help due to still requiring a upstream DNS server of sorts somewhere, which will be blocked if not automatically then very quickly albeit manually anyway.
> I fail to see how stubby could be of any help
I agree fully with the first, partially agree with the second; the DNSPrivacy site needs an overhaul and seems a few years out of date but it does cover most of the privacy related lurks.
As you said the "stubby" | "getdns" module is good enough for privacy, it's no more than a local service shim layer between anything local requiring DNS via a variety of means, all of which can be censored.
I did suggest it could use extension .. and a network of distributed peers to extend to.
It's a project for anyone minded to take it up .. create a secure obfuscated distributed stubby net that can try DoT DoH etc in situ and should they work provide that service to others else fallover to reaching out to others to find peers that can access authorised DNS.
The Windows Portmaster project is an interesting one; it provides a level of network inspection and control to advanced regular users, stubby-like getdns functionality that's a bit easier to use, and offers a VPN layer to subscribers for data.
If the Portmaster maintainers are true to their vision I can see them adding obfuscated distributed DNS to subscribers in the near to mid future depending how they allocate resources and who they onboard now they have funds for a new hire (last I checked, I could be out of date here).
They are not exactly backtracking but it seems that some of the involved parties didn't like the solution proposed (DNS redirection) and want to discuss other alternatives.
It's chaotic. They will usually have mid level officials announce some new policy as if it's a done deal.
Then, if there's no public outcry, a higher level official will confirm it and maybe, eventually, details will roll out.
If the public responds very negatively, the idea will just disappear or the higher level guy can distance himself from the low level guy "who was misinformed".
I think it's how they test the water and decide if it's worth the effort.
With that single misstep, suddenly the people realized if they could (and did) mitm Google and Cloudflare dns endpoint, they could mitm Gmail, Outlook, Riotgames, Facebook, Tiktok or whatever too. Public outcry comes pouring in and the Minister of Comm backtracked.
First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust.
(Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.)
(Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)
subjectAltName=IP:192.168.1.1
And that's actually exactly what Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use in their certificates.
Also both issuers use certificate transparency [0], so BGP hijack shouldn't affect this — sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate (assuming certificate trust chain wasn't compromised and there are no malicious CAs installed on your system).
I think the parent is asking if malicious actor can issue a certificate in case of BGP hijack. I think they could, but then it would be visible in the CT log.
I think it'd be pretty hard to get a certificate for 1.1.1.1 after a BGP hijack, unless you had some control over a CA. I don't think LetsEncrypt issues certificates for IPs.
Not sure if it's a problem with my setup or if it's not very robust in general.
-Digi redirected ALL traffics on destination port 53 to their own DNS server. Thus DoH unaffected.
-Maxis redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on destination port 53 to their own DNS server. Thus DoH unaffected.
-TM is the most evil, they redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on all ports to its own DNS server. DoH and DoT failed due to certificate error.
When one tries to visit some sites like LibGen, DNS is redirected to a "no-no you shouldn't go there" page, which in turn redirects to this official finger-wagging page: https://opi.gr/edppi_block/edppi_block.html
DNS hijacking was also used during the beginning of the Ukraine affair as part of an EU-wide censorship push, blocking sites like the Kremlin and Pravda, though without further redirection.
1. Blocking or redirecting some pages when using the ISP's DNS server. This is what you're talking about. The workaround is to use a third party DNS resolver.
2. Intercepting all unencrypted DNS traffic to any DNS server and redirecting it to the ISPs' DNS servers. This is what Malaysia was planning to do.
It's even been ordered to close by a US court (according to Wikipedia). Obviously they ignored that as they are not in the US...