How to handle hostnames with dots?

[jakubgs]

I think Innertnet looks pretty neat, but I have a naming problem that I'm not sure how to deal with.

Lets say I have hosts for service xyz with hostnames that look like this:

node-01.eu-dc1.xyz.test.example.org
node-01.us-dc1.xyz.test.example.org
node-01.af-dc1.xyz.test.example.org

And

node-01.eu-dc1.xyz.prod.example.org
node-01.us-dc1.xyz.prod.example.org
node-01.af-dc1.xyz.prod.example.org

I can create an Innernet network called example, and then a CIDR called prod, and then another one called xyz(service name). But the problems start when we reach the different datacenters part. All the hosts in the the Innernet xyz.prod.example.wg CIDR should be connected to one another, preferably under the same CIDR. BUT I cannot name the hosts node-01.eu-dc1, node-01.us-dc1, and node-01.af-dc1 because of the dots in the hostname.

Now, one solution would be to create even more CIDRs, one for each DC, and then add hosts in each one separately. That would quickly clutter up the tree of CIDRs with a lot of actually unnecessary networks. Is there a way to add these hosts without having to make a separate CIDR for each DC?

[mcginty]

Yeah, in this case the limitation is that peers can't have the same name - "node-01" would have to be unique on the network. The reason we didn't add CIDRs to the hostnames is because we wanted to make the hostnames fairly short and easily memorable, but there's nothing stopping them from being there technically-speaking.

At tonari, we name our infrastructure peers pretty descriptively with dashes in the name, so in your scheme it would be like node-01-eu-dc1-xyz-prod for the peer name (and their hostname would be node-01-eu-dc1-xyz-prod.example.wg.

[jakubgs]

I see, that wouldn't work for us. I'd have to do a LOT of renaming, and break a lot of services in the process to move the DC info into the top element of the FQDN. I guess I'm gonna stick to pure WireGuard for now. Thanks for explaining.

[mcginty]

Yeah, I'd say if you have lots of existing enterprise-type infrastructure with complicated domain/DNS stuff, innernet doesn't have a lot of built-in integrations so you'll find yourself having to write your own helpers or submitting PRs.

The only thing that would be really blocking you from making it work with innernet would be the unique peer name limitation, since I don't think that's going to be going away any time soon.

I'll go ahead and close this issue since it seems resolved, thanks.

[mcginty]

Reopening this as a tracking issue for CIDRs to be hostname-compatible.

I'm going to start enforcing that newly-created CIDRs be hostnames, and will start adding warning dialogs and renaming functionality for CIDRs that were already created that aren't hostname-friendly.

I think it makes sense to move toward supporting layouts like yours, including the possibility of allowing peer names to only need to be unique inside its own CIDR.