We shouldn't allow IP addresses as Matrix "hostnames" on the open internet

[hawkowl]

For testing and local servers, sure, but not on the open internet. This leads to a number of problems:

• Proposed methods of "ending" federation (via DNS records) isn't possible, meaning servers will talk to them until the end of time unless someone intervenes
• It's a trivial DoS vector (get an IP, set up a server, join a bazillion rooms, release the IP)
• It's a trivial spam vector
• It's also confusing from a user perspective (where mxids can be thought of as analogous to an email address)

We should only allow IP addresses (probably with a config flag for servers) that are within the local use ranges, for local-network and testing purposes, and then blacklist the rest.

[hawkowl]

Mastodon appears to require it too, as prior art: https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md#prerequisites

[Half-Shot]

I can't think of a single reason to want IP addresses out in the open. I support a configurable range of IPs to allow for internal use.

[hawkowl]

This came up in Synapse Admin because of the fallout of Server ACLs banning IP addresses, BTW. We should be consistent.

[non-Jedi]

I'm not opposed to this in principal, but I did want to note that overloading DNS and the cost of buying a domain-name as an anti-spam measure is well outside the purpose of domain names and feels a bit hacky. For point 4, I've been told several times that mxids aren't supposed to be user-visible, so it feels like a non-issue.

Other two points definitely stand as real practical reasons to disallow bare IP addresses as server addresses. Again, feels a bit hacky to overload DNS to see when a server is no longer available for federation, but I don't have better solution.

[Half-Shot]

Totally agree @non-Jedi, I just can't see a better antispam measure that doesn't impact innocent bystanders somehow.

I don't think this should be required but disallowed on the public network.

[jevolk]

This isn't a terrible idea in itself, but not necessarily for these reasons.

Proposed methods of "ending" federation (via DNS records) isn't possible, meaning servers will talk to them until the end of time unless someone intervenes.

This point is somewhat irrelevant to whether DNS or an IP is used. In this system, something will have to be queried and fail until the end of time. This stems from protocol design shortcomings and exacerbated by implementation decisions in Synapse.

• The protocol chooses to allow users to subscribe to (join) a room once and forever. It doesn't have to be that way; though being that way it leads to the next point
• The implementation (synapse) chooses to hammer dead servers very aggressively. It doesn't have to do that. Implement appropriate caching; wait for servers to contact yours first to evict themselves from that cache.

Either way this point is moot for requiring domain names only.

It's a trivial DoS vector (get an IP, set up a server, join a bazillion rooms, release the IP)

You're forgetting a few other vectors:

1. Get just one domain, join a bazillion room with a bazillion users.
2. Get just one domain, create a bazillion subdomains, join a bazillion rooms with a bazillion users.
3. Get an IP, find out what its PTR record is with a matching A record such as host-1.2.3.4.in1-f2.isp.tld, goto: 1 & 2.

While an IP rather than a domain is indeed another vector, it's a drop in the bucket. That being said it's just not worth eliminating them on this point.

It's a trivial spam vector

AFAICT thus far the most effective intrinsic spam barrier in this system is the requirement for duplex connectivity. Reverse proxies are harder to come by and not generally harvested en masse. That's not much, but it's a slight step above the dirt.

It's also confusing from a user perspective (where mxids can be thought of as analogous to an email address)

I'm going to recite @non-Jedi here and repeat what's been explained to me as a "hard rule" -- not that I entirely agree with it myself, but it is your rule: mxids are not for user consumption.

All-in-all I don't think this is an entirely a bad idea, but these are all the wrong reasons. I actually can't think of any good reasons. This is why I consider my conclusion that this isn't a bad idea to be a purely anecdotal opinion. I don't make engineering decisions that way, so I have no basis to support you @hawkowl sorry bro.

[bkil]

Globally routable IPv6 connectivity either natively or via Yggdrasil opens up the possibility for anyone to join the P2P matrix without centralized infrastructure and for free.

DNS is an unnecessary step towards centralization.

Surely a dynamic DNS provider could be hooked up for free as well, but those are again centralized, can go bankrupt after a few years and they usually have horrible latency. Adding insult to injury, they usually also have a fixed TTL that is incidentally very low, making caching useless.

[clokep]

MSC4045 proposes removing this ability.