mirror of
https://github.com/mikaela/mikaela.github.io/
synced 2024-11-22 03:59:31 +01:00
n/dns.md: remove the long comment containing the old version of ECS
This commit is contained in:
parent
e011d47ce5
commit
526bff17bd
48
n/dns.md
48
n/dns.md
@ -157,54 +157,6 @@ See also:
|
||||
- [AdGuard DNS: Privacy-friendly EDNS Client Subnet](https://adguard-dns.io/en/blog/privacy-friendly-edns-client-subnet.html)
|
||||
- [DNS0 Privacy Policy](https://www.dns0.eu/privacy)
|
||||
|
||||
<!--
|
||||
|
||||
[_Understanding the Privacy Implications of ECS_](https://yacin.nadji.us/docs/pubs/dimva16_ecs.pdf)
|
||||
brings up two bigger issues EDNS client-subnet:
|
||||
|
||||
- Authoritative nameserver is given part of the subnet, which can be
|
||||
personally identifiable and as the connection between recursor and
|
||||
authoritative is unencrypted, anyone between them can observe all the
|
||||
queries.
|
||||
- Think of VPNs where traffic within the VPN is encrypted, but it won't
|
||||
magically encrypt plain traffic leaving it.
|
||||
- The part given to the au4thoritative nameserver is `/24` on IPv4 and
|
||||
`/56` on IPv6. These equal 192.0.2.x so if a MITM wanted to know who you
|
||||
are there would be 254 options (assuming there are no NATs). On IPv6 a
|
||||
`/56` includes 256 `/64` blocks and `/64` is the most used block and there
|
||||
is a recommendation of giving customers a `/56` block, so it would point
|
||||
directly to your connection. However some mobile operators give a `/64`
|
||||
so it will again point to 256 options again. Not that many.
|
||||
- Anyone between the recursive and authoritative nameservers can perform cache
|
||||
poisoning attack and give it a narrow target. With short TTL, it may be
|
||||
impossible to audit afterwards. Only DNSSEC can protect from this, but
|
||||
DNSSEC signing isn't used that widely.
|
||||
|
||||
These issues bring additional questions:
|
||||
|
||||
- Do you care?
|
||||
- If you run open wireless network and offer everyone ECS nameserver such as
|
||||
Google DNS through DHCP while using manually configured encrypted DNS by
|
||||
yourself, is there any cause for concern? You can always say it was
|
||||
someone using your open network? Or if this is a multi-user system like
|
||||
VPS running titlefetcher bot or Matrix homeserver, who knows who triggered
|
||||
the original queries and where? SteamOS? Speed over all as it's only used
|
||||
for gayming. Virtual machine lab? Who cares. Larger organization? That may
|
||||
be a big target?
|
||||
- How much does getting local content matter to you? More or less than
|
||||
increased resource use of contacting a server further away? _Is private ECS
|
||||
an option?_ ([r/resolv.tsv](/r/resolv.tsv))
|
||||
- What is the impact of domains you visit being surveilled?
|
||||
- This page mentions cases like FFUpdater where the surveillance would
|
||||
reveal that I interact with github.com and other sites it downloads apk
|
||||
files from, which hardly matters, but how about you?
|
||||
- What is the impact of cache poisoning tailored to you?
|
||||
- Everything is encrypted and TLS certificates wouldn't match so would you
|
||||
continue to the wrong site regardless of the prompt, or decide something
|
||||
is wrong and try again later. How about your users?
|
||||
|
||||
-->
|
||||
|
||||
### Identifying support for ECS
|
||||
|
||||
Or what is being sent to the authoritative servers.
|
||||
|
Loading…
Reference in New Issue
Block a user