4 ms·

> I'd rather have a mode where regular DNS and centrally controlled DNS are compared, and you get a popup if they differ. That warns you of censorship attempts.

by schoen 5y ago

> I'd rather have a mode where regular DNS and centrally controlled DNS are compared, and you get a popup if they differ. That warns you of censorship attempts. But that doesn't seem to be an option. This is difficult with CDNs because it's commonly intended that you get a different RR-set response depending on where your query originated from. So, somewhat awkwardly, there's no unique correct answer to a particular DNS query in many cases today. I just looked up IN A www.google.com from two different networks, and got two different answers, yet I think both of them are correct and are the answers that Google intended for me to get! (These discrepancies are themselves one reason that CDNs have been wary of large numbers of users not using ISP-provided recursive resolvers. There is a sort of compromise workaround called ECS, https://en.wikipedia.org/wiki/EDNS_Client_Subnet https://en.wikipedia.org/wiki/EDNS_Client_Subnet, in which the recursive resolver gives the authoritative server a hint about where the query came from, to facilitate giving a response that may be most relevant to that specific client, typically a nearby CDN instance.)

Animats 5y ago
A useful check is to then compare the certificates presented by the sites the DNS wants you to talk to. If both paths present the same cert, you're good. If they present different certs, there's a problem. Cloudflare's creation of fake TLS certs for sites they front-end may mess that up, though. Do you see the same TLS cert from all Cloudflare MITM nodes?
zo1 5y ago
Would a networking expert with some historical perspective then not say that we're misusing DNS for routing or load balancing?
- schoen 5y ago
  I'm sure there was a huge debate about this when CDNs first started doing it. (I think Akamai was already doing it 20 years ago or so, so it wasn't just invented now.) You could, of course, try to handle it at a higher protocol layer. For example, you could try to dynamically generate HTML like <img src="https://dallastx.mycdn.com/mysite/someimage.png https://dallastx.mycdn.com/mysite/someimage.png"> for one visitor, whereas a different visitor would get <img src="https://seoul.mycdn.com/mysite/someimage.png https://seoul.mycdn.com/mysite/someimage.png"> This would mean that latency for an initial HTTPS page load would be higher, but then for subresources and maybe other pages on the site it would be lower. But there are other difficulties, like requiring the web server to generate page content (at least slightly) dynamically instead of statically. I'm sure that there are many people who felt that there was something seriously improper about intentionally serving different RRs within the same zone at the same point in time. From what I've heard, this practice is so common that most people working on related Internet standards just assume that this practice has to be accommodated because CDNs and their customers will definitely refuse to give it up. (I know this issue came up a ton in ESNI because in the first version there was a risk that you could cache one version of an A record and another version of an ESNI key record, so the two could be out of sync and therefore inconsistent, if they pointed to different CDNs or different CDN instances that had different public keys. A "nice" solution might be to say "well, don't create deliberately inconsistent sets of DNS records in your DNS zone, then" but apparently nobody found that solution at all acceptable for performance, so they created a more complicated workaround where both pieces of information are merged into a single rrtype.)

by schoen 5y ago

Animats 5y ago

A useful check is to then compare the certificates presented by the sites the DNS wants you to talk to. If both paths present the same cert, you're good. If they present different certs, there's a problem. Cloudflare's creation of fake TLS certs for sites they front-end may mess that up, though. Do you see the same TLS cert from all Cloudflare MITM nodes?

zo1 5y ago

Would a networking expert with some historical perspective then not say that we're misusing DNS for routing or load balancing?

schoen 5y ago
I'm sure there was a huge debate about this when CDNs first started doing it. (I think Akamai was already doing it 20 years ago or so, so it wasn't just invented now.) You could, of course, try to handle it at a higher protocol layer. For example, you could try to dynamically generate HTML like <img src="https://dallastx.mycdn.com/mysite/someimage.png https://dallastx.mycdn.com/mysite/someimage.png"> for one visitor, whereas a different visitor would get <img src="https://seoul.mycdn.com/mysite/someimage.png https://seoul.mycdn.com/mysite/someimage.png"> This would mean that latency for an initial HTTPS page load would be higher, but then for subresources and maybe other pages on the site it would be lower. But there are other difficulties, like requiring the web server to generate page content (at least slightly) dynamically instead of statically. I'm sure that there are many people who felt that there was something seriously improper about intentionally serving different RRs within the same zone at the same point in time. From what I've heard, this practice is so common that most people working on related Internet standards just assume that this practice has to be accommodated because CDNs and their customers will definitely refuse to give it up. (I know this issue came up a ton in ESNI because in the first version there was a risk that you could cache one version of an A record and another version of an ESNI key record, so the two could be out of sync and therefore inconsistent, if they pointed to different CDNs or different CDN instances that had different public keys. A "nice" solution might be to say "well, don't create deliberately inconsistent sets of DNS records in your DNS zone, then" but apparently nobody found that solution at all acceptable for performance, so they created a more complicated workaround where both pieces of information are merged into a single rrtype.)