[shitloadofbooks]

It likely overrides DNS resolution to CDN/POPs in countries which don't require age checking, or routes the traffic through TCP proxies so your traffic appears to come from a different country without these laws.

This will increase the latency of all traffic to that site though.

[lelanthran]

> It likely overrides DNS resolution to CDN/POPs in countries which don't require age checking,

I don't understand what this means:

1. It resolves DNS requests - got it.

2. The resolution sends back an address to a CDN - okay, not sure that I got it

3. The resolved address is in a country which doesn't require age checking - Totally don't get it: how will this help?

[dbmnt]

They're (ab)using the EDNS Client Subnet feature:

https://en.wikipedia.org/wiki/EDNS_Client_Subnet

[selcuka]

A DNS provider can not route your traffic through TCP proxies, so it must be the former.

[cluckindan]

Sure they can. When your browser resolves a host, they replace the actual IP with the IP of a proxy that is configured to forward traffic according to the Host HTTP header.

[okasaki]

You would have to install a certificate for that to work.

[aaronmdjones]

No you wouldn't.

The current situation:

- You ask Foo DNS Provider for the IP address of pornhub.com

- Foo DNS Provider responds with the real IP address

- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"

What could happen:

- You ask Foo DNS Provider for the IP address of pornhub.com

- Foo DNS Provider responds with one of their own IP addresses

- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"

- Foo DNS Provider now knows that you intend to connect there, so it connects there for you and relays your ClientHello to it

- Foo DNS Provider then just acts as a dumb relay, passing everything back and forth with no modifications

- The certificate verifies fine because the traffic was not modified and it was presented by the party who controls the corresponding private key

- The website thinks you are connecting from Foo DNS Provider, not your real address

The only thing that would break this is ECH (Encrypted ClientHello), currently supported only by CloudFlare and Google Chrome (and its derivatives) as far as I know. This security feature is provisioned with ... DNS records! So Foo DNS Provider can simply indicate that the records required for ECH do not exist, and your web browser wouldn't encrypt the ClientHello. It's already tampering with the responses to address lookups anyway, so DNSSEC wouldn't be an issue -- you simply would not expect to be able to validate anything.

[dbmnt]

This is wrong. It shows a fundamental misunderstanding of how certificate authorities (CAs) work.

A certificate has to be signed by a trusted CA (one your browser already trusts).

A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.

Even if they tried to trick a real CA, Certificate Transparency (CT) would expose the bogus certificate:

https://en.wikipedia.org/wiki/Certificate_Transparency

Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location. Much more simple and less nefarious.

[aaronmdjones]

> A certificate has to be signed by a trusted CA (one your browser already trusts).

Yes.

> A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.

I never said anything about the DNS provider minting any certificates, and explicitly said that the certificate would be provided by PornHub's servers and merely relayed -- verbatim -- through the DNS provider. As well as the rest of the TLS negotiation.

> Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location.

That's what they are doing now, yes. What I propose is how they can continue to make it work once the website operators catch on and start looking at the ASN information of the source IP address of the HTTP connection.

I am well aware of how CAs and the Web PKI model and TLS work.

[selcuka]

Good point. I was thinking of an HTTP proxy, but surely a TCP proxy would work.

[rany_]

I tried out NextDNS and this feature doesn't seem to work anyway. Enabling "Bypass Age Verification" has no effect. I tested it out on PornHub and XVideos.

I also can't find anything different in the returned A/AAAA records compared to my standard resolver.