DNS names that resolve to an IP address in the name

Issuance Policy
1

@cpu Wouldn't issuing a cert for such a "generic" name basically equal issuing a cert to an IP?
It might have well just been 88.168.18.109.in-addr.arpa (so long as it met FCrDNS)

Completely off topic - but that is one reason why SPAM is easy - when ISPs assign functional FCrDNS entries to all their IPs.

1 Like
2

Not really. This generic name is still a name in DNS. It just happens to resolve to an IP address that matches a prefix of the DNS name.

At a technical level, this is still represented by a "dNSName" field in X.509, not an "iPAddress" field.

2 Likes
3

And what when that name is dynamic and changes frequently?

1 Like
4

I think this is a somewhat separate question, right? Domain names that resolve to an IP address in the hostname are pretty static - they always resolve to the same IP.

There are other domain names where the resolved IP address does change frequently - for instance, if example.com uses DNS-based load balancing, you might see a different IP address every time you look it up. That doesn't pose a problem for certificates that vouch for a dNSName, because they don't say anything about the underlying IP address.

1 Like
5

I think I may have misspoke,
What I meant was…
Even though the IP and the rDNS will always match, what happens when the IP is dynamically assigned (like with any standard DHCP)?
The user may get a completely new IP (and name) every time they reboot their router.
Should such (temporary) IPs be given certs based on names directly correlating to that IP?
Dynamic DNS lives to solve that problem.

1 Like
6

Now I understand what you are asking. Yes, there’s always a risk that either a domain name, or the underlying IP address, will change hands during the lifetime of a certificate. There are some circumstances that make that more likely, like dynamically assigned IP ranges, and generated DNS namespaces that map to them. That’s one of the many reasons we offer 90-day certificates instead of 1-year or 2-year: it somewhat reduces the risk.

The other mitigation for the risk of reused IP addresses is that it only affects the people who specifically take it on. For instance, if you decided to run a production website on 198.51.100.100.rev.sfr.net, but you know 198.51.100.100 isn’t yours forever, you’re taking on a risk. If someone else later gets assigned 198.51.100.100 and gets a certificate for 198.51.100.100.rev.sfr.net, they would be able to intercept traffic intended for your production website, stealing cookies and so on. However, that just means it’s a bad idea to run a production website using domain names and IP addresses that you don’t fully own.

2 Likes
7

This problem is created by the ISPs; When they issue fully functional rDNS entries to every IP they control.
The entire Internet should frown on this practice (for many reasons).
I’m not even sure if they are required to follow any standard that could mitigate this situation.
I mean, I do understand the need to create functional rDNS entries.
But they should be done in such a way that they can’t be misused/abused.
One simple solution is to prepend all entries with an undercore:

_198.51.100.100.rev.sfr.net

could still resolve to an IP and pass FCrDNS checks.
But such a name should never be issued a cert.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.