why even count like 01, or 001, why not just start with “1”. with this you will never have the problems like “ohh we use $NUM digits” but now we need one more digit. also makes scripting way easier.
1 Like
because as soon as you get to needing 10 of something you’re fucked and so are all your scripts.
Plan arity from the beginning. It’s not a big deal.
1 Like
i do not see why a fixed length has to be used at all.
why is hostname-01.example.com better then hostname-1.example.com.
as soon as you hit 9, you overflow and use 10.
using a variable length is IMHO more flexible, as well as more natural.
or what is the advantage of a fix number of digits?
1 Like
Yes, you should always plan parity from the very beginning. I cannot tell you how many times at my last company that this sort of thing screwed us over after everyone ignored my suggestion of using a XXX digit scheme.
2 Likes
For external, I would like to additionally propose debuginfo.rockylinux.org for debuginfo/debugsource RPM packages.
another remark regarding the suggested naming scheme: dev-us1-01.ci.rockylinux.org:
ID
xxx - unique id
env - (dev, test, stage, prod)
dcc - datacenter code
technically speaking these all should be subdomains.
so “dev-us1-01.ci.rockylinuxorg” would become.
ci-1.dev.us1.rockylinuxorg.
this scheme will allow to use DNS service discovery, and always send local client, to the closest server.
for example. FreeIPA Clients use DNS service discovery for to find FreeIPA servers.
with the suggest scheme “dev-us1-01.ci.rockylinux.org” you will never be able to force a IPA client to use the closest IPA server.
with the scheme suggested above a DNS discovery request for a IPA kerberos will do a SRV lookup on _kerberos._tcp.ci.rockylinux.org
the result might look like this:
_kerberos._tcp.ci.rockylinux.org IN SRV 0 100 88 dev-eu1-01.ipa.rockylinux.org
_kerberos._tcp.ci.rockylinux.org IN SRV 0 100 88 dev-us1-01.ipa.rockylinux.org
_kerberos._tcp.ci.rockylinux.org IN SRV 0 100 88 dev-jp1-01.ipa.rockylinux.org
so the client will talk to a random host from the result set. which is no fun with IdM.
but if you make the “env” and “dcc” a subdomain.
you will be able to always hit the closest IPA server, and get fast results.
example:
client: ci-1.dev.eu1.rockylinux.com:
request: SRV _kerberos._tcp.dev.eu1.rockylinux.com:
result:
_kerberos._tcp.dev.eu1.rockylinux.com IN SRV 0 100 88 ipa-1.prod.eu1.rockylinux.com
_kerberos._tcp.dev.eu1.rockylinux.com IN SRV 0 200 88 ipa-1.prod.us1.rockylinux.com
_kerberos._tcp.dev.eu1.rockylinux.com IN SRV 0 300 88 ipa-1.prod.jp1.rockylinux.com
watch the different priority in the result, the client will always us the ipa server with the best priority, and will only fall back to a lower priority host in case the nothing else is available.
the fun fact is that you do not have to set these TXT/SRV records for every subdomain.
ipa client will automatically start stripping subdomains if no result is found, like:
_kerberos._tcp.dev.eu1.rockylinux.com
_kerberos._tcp.eu1.rockylinux.com
_kerberos._tcp.rockylinux.com
all this is not possible if you have a “flat” DNS structure.
another advantage of having the “dcc” as a subdomain is that you technically could run a dedicated DNS master for each “dcc”, which would allow you to make DNS changes independently from other "dcc"´s
2 Likes
+1 more for planet.rockylinux.org, dev, media and user who have websites now are talking about rocky linux. They can send rss feed to planet 
1 Like
+1 for using domain separation, such as @schlitzered recommended. It also allows breaking a subdomain into its own zone to move SOA around and whatnot for better scale or locality.
Also, regardless of whether we do internal/external DNS views, I think it’s wise to keep the internal names in subdomains rather than rockylinux.org directly. Personally, though, I don’t see views bringing anything to the table. They’re annoying to work with and make some things, like DNSSEC, more complicated.
+1 for domain separation too, but fixing again, since this should work from biggest to smallest, so instead pf proposed by @schlitzered:
ci-1.dev.us1.rockylinuxorg.
If should be:
ci-1.us1.dev.rockylinux.org.
and in such case, why do we even care about dash? Then it would be just:
ci1.us1.dev.rockylinux.org
This is because one “dev” contains all different DCs inside DEV env.
@RNM - Good catch Added planet i prefer rss but that is the current standard name so lets stick with it.
@schlitzered - Split makes sense for the Free IPA Environment
I think that splitting it on dev first would be a mistake as i doubt we are going to have a complete separate development supporting environment if that makes sense. So the logical split would be at the dcc level which provides the physical location of the system. I would be interested in @nazunalika Thoughts.
Even if you don’t have complete separate dev env, it’s still more logical to put multiple DCs into env, than putting multiple envs envs into single dc 
Because first you have infrastructure (dev/prod for eg), and under that dev/prod you have different hosts (and those hosts belongs to some DCs).
Putting everything other way makes multiple prods and multiple devs environments from logical point of view, but I don’t think we want to have them to be multiple times, we want to have one prod and one dev.
And also, putting dev under DC makes more mess, becuase now you can have:
dev.pl1 (because someone could give free servers for dev in Poland) and prod.us2. So now you don’t have prod in pl1, and you don’t have dev in us2 
The IPA servers will live at the rockylinux.org domain, internally, to keep everything consistent. There will be a chance of hosts sitting at the root domain, but not many. We can add additional internal zones without an issue, also. Doing split DNS makes sense when using FreeIPA as @darkbat91 has stated.
FreeIPA has location support (and thus helps with DNS priorities for SRV and NS records). Because of this, it needs to be determined how the host’s subdomains should be laid out. While I’m a fan of location before environment in names, it really does not matter. They both have their pro’s and con’s, with those things simply being a matter of preference for the organization. Unfortunately, I’m split on which one would be the right choice. On one hand, splitting based on DCC makes my life easier in FreeIPA when configuring the location system. On the other hand, splitting based on environment logically pinpoints what that host serves.
The other thing is too if you split on environment, we can reduce the number of subdomains we’d end up having.
us-west-ci-1.dev.rockylinux.org # Subdomain is dev.rockylinux.org
vs...
ci-1.us-west.dev.rockylinux.org # Subdomain is us-west.dev.rockylinux.org
The second one at least eliminates one subdomain. When I look at this…
dev-ci-1.us-west.rockylinux.org # Subdomain is us-west.rockylinux.org
vs...
ci-1.dev.us-west.rockylinux.org # Subdomain is dev.us-west.rockylinux.org
Honestly, both of those look really ugly to me, despite the first one bringing us down one subdomain.
Like I said, I don’t really have a preference. But, what I would suggest is if at possible, let’s try to keep the subdomains down to a minimum, by using the first lines in both examples above.
2 Likes
I like the top solutions the best. I feel that the environment is more important and should be at the domain level. Having the name of the host be dcc-function-arity makes the most sense. There doesn’t seem to be a need to consistently split out subdomain into function, and it looks really nice to anyone on the command line to be able to quickly look and see, “Oh, this is us-west-ci-1 host and not de-ci-1”.
there is no need for the ipa hosts to sit at the root domain, except if you want to expose them to the public internet. which is something i would not recommend.
@morsik: regarding dcc first env. to me this makes no sense, other way around is more natural. this is also what big could companies like AWS and Azure do.
if you think of subdomains as boxes, the boxes should get bigger from left to the right part.
or how would you explain that the hostname portion is bigger then the TLD?
also having the region first in the hostname portion of the fdqn somehow defeats the purpose of DNS search lists.
@darkbat91 why do you want to save on subdomains, as explained above. they can help with service discovery.
in the example you posted above, you are simply trading a “-” for an “.”
but the dot gives you real subdomains, which allow you to have different DNS srv records, and also allow you to physically split the zone to another DNS server (if one want to).
so even if you do many subdomains. all could live within the same zone:
so you could either have:
host-1.dev.us-east-1 in zone example.com
or
host-1 in zone dev.us-east-1.example.com
but there is no way you could do a DNS zone split, or region/stge specific DNS discovery records with the scheme you suggested above.
so from my experience it is way more flexible and gives you more options if you do it like this: ci-1.dev.us1.rockylinuxorg
1 Like
@schlitzered They will be at the root domain for consistency. They will not be exposed to the internet. Nowhere does them being at the root domain, handling an internal domain, does it imply they will be exposed to the internet in any fashion. My IPA servers sit at the root of my internal domain angelsofclockwork.net, but you don’t see them nor can you talk to them on the external internet.
@nazunalika: but why having them there at all, and deal with dns views, when they can happily live on a subdomain, that is only hosted on an internal dns?
FreeIPA should always own the primary internal domain, and thus, be at the primary, root internal domain. This is clearly laid out in the Red Hat documentation and deployment recommendations of the freeipa website.
i am sorry, but this is not true or is it needed in any way
we run a IdM cluster which stretches over different continents.
none of our IdM servers is directly running on at the top of the REALM domain.
each idm server is hosted on a subdomain, that is specific to its region.
hostnames are like this, adjusted for REALM EXAMPLE.COM:
us region 1:
“idm-1.prod.us1.example.com”
“idm-2.prod.us1.example.com”
“idm-3.prod.us1.example.com”
us region 2:
“idm-1.prod.us2.example.com”
“idm-2.prod.us2.example.com”
“idm-3.prod.us2.example.com”
eu region 1:
“idm-1.prod.eu1.example.com”
“idm-2.prod.eu1.example.com”
“idm-3.prod.eu1.example.com”
eu region 2:
“idm-1.prod.eu2.example.com”
“idm-2.prod.eu2.example.com”
“idm-3.prod.eu2.example.com”
this scheme allows us to send IdM clients from each reagion to there the IdM servers in the same region, or to the IdM server in the region with the lowest latency.
the only requirement for an IdM server is, that is has to be a FQDN that is within the same realm.
means:
idm-1.prod.us1.blarg.com can never serve the realm EXAMPLE.COM.
this is the only restriction when it comes to the IdM FQDN.
on the other hand, and IdM client, that has an FQDN outside the REALM domain name, can join a different REALM.
meaning client.blarg.com can join EXAMPLE.COM
to me that’s why exactly ENV then DC makes sense in the tree 
(I mean host00.dc1.prod.domain.tld)
Beucase you have big box that contains all dev/prod stuff, and they contain multiple different DCs inside. You explained by yourself why it makes sense 
You don’t want to have multiple boxes with different envs, you want to have single one.
And regarding “companies like AWS and Azure” - they are splitting everything per DC because it’s actual physical and logical split - in case of this project I don’t think this is necessary - I think we would rather use everything as single thing all over the world
no this is actually not what i said or at least meant.
but well we are running in circles here. it seems like no one is around who could mediate or would be in charge of making decisions.
anyhow, it seems like without knowing how the hosting infrastructure would look like it also makes not much sense to talk about stuff like DNS (or anything else). feels like putting the cart before the horse. \o/