[takeda]

Exactly, but if you own it and add `PTR` to `has-a.name` then in turn you give them power. They can request a new certificate under that name and point that host to another IP. I'm sure there are other ways to abuse it as well.

[cortesoft]

They can do that even if you don’t set a PTR record... since they own the domain, they can get a certificate for it. The danger comes not because you set a PTR record, but because you use that domain at all.

Really, this is the same risk you take with any registrar... they could give the domain to someone else, or alter the DNS to give themselves a cert. This is basically making has-a.name your domain registrar, and you have to trust them to not behave poorly or have bad security.

[treysis]

But if they point to a new IP, the other IP's PTR is useless.

[takeda]

Yes, but what's your point? You seem to understand DNS enough and at the same time you don't seem to see the obvious security implication, are you affiliated with that domain?

[treysis]

No, I am not affiliated with them (though we follow each other on Twitter). My point is, I don't see any security implication involved with a wrong PTR record in relation to this service. If I set the PTR of my IP to this domain, but the domain itself resolves to some other IP. Or are you implying they can only request a cert if the PTR matches the domain? At least for LetsEncrypt this is not true, otherwise home owners with dynamic IPs wouldn't be able to request certificates.

[takeda]

If you provide PTR that points back to that name, configure web server to handle requests to that name, you basically makes the domain an official one.

As your users start using it, the owner of the name can now point the AAAA record to another server that will act as a proxy, request a new certificate (he owns the domain) and see all the encrypted communication.

[treysis]

But you don't need PTR in any of these steps.