Naming Scheme - Rev 1

Just looking to get a rough draft of the Naming Scheme as brought up in the


Purpose DNS
Build Logs
Mail List
RSS Feed


Purpose DNS
Cont Int. **id**
File Storage **id**
Identity Provider **id**

**id** - Represents a unique identifier for clusters and systems that scale out


xxx - unique id
env - (dev, test, stage, prod)
dcc - datacenter code



Bringing over thoughts from @neil on this topic to tack on to the Internal bit:

I’m personally a fan of location-environment-subenvironment-name/… e.g. (or similar) though pieces can be removed/added/changed as required.

1 Like

to be clear that naming isn’t a hill i will die on - i just want to make sure we build in knowing where we have things situated if our gear ends up dispersed across multiple data centers or locations.

1 Like

The consideration of putting physical location of resources in the hostname and fqdn is good, the hostname might a bit overly verbose for my personal tastes given the fqdn, but too much verbosity is better than not enough for this. I think it’s a reasonable set of things to include.

1 Like

Absolutely but getting the schema correct now is a good idea, I am thinking for the id a format like this


xxx – unique ID that is registered in a system (IE track location physical admin etc)
env - (dev, test, stage, prod)
cc - Country code

1 Like

We really dont need it in both that was a carry over from something else i was working on.

For internal DNS, FreeIPA will either need to control the domain as name servers or another DNS server will need to be managed with all the special DNS records (I don’t like the latter, it is very painful to manage - having IPA manage it would be ideal here).

If we want seamless identity management/idp, freeipa needs to be at the top to manage kerberos and other functionality of the system, including DNS records, KRA, CA, among other things. Having an “idp” subdomain is perfectly fine for having ipsilon and the like for that specific functionality, but we should be aware where the core of the identities need to sit, top level. As long as FreeIPA has control over the internal domains and reverse zones, it will work very well for our needs.

1 Like

@nazunalika to be clear, freeipa wants to own NS and SOA for

@neil Internally, yes. FreeIPA doesn’t care about external domains because it doesn’t do views. For example, my domain I have external records hosted somewhere else but my IPA domain is still internally, held by my IPA servers. Changes I do there do not reflect external changes. My external changes are done elsewhere. This system is doable.

Edit, here’s what I mean.

# dig @ A

; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> @ A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44108
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8a05702cb5025ce046ce117d5fd1343321297e13edf40253 (good)
;     IN      A

;; ANSWER SECTION: 1200 IN      A

;; AUTHORITY SECTION:  60      IN      NS  60      IN      NS  60      IN      NS

;; ADDITIONAL SECTION: 1200 IN   A 1200 IN    A 1200 IN    A 1200 IN   AAAA    2001:470:1f19:138::1 1200 IN    AAAA    2001:470:1f19:138::231 1200 IN    AAAA    2001:470:1f19:138::232

;; Query time: 0 msec
;; WHEN: Wed Dec 09 13:31:47 MST 2020
;; MSG SIZE  rcvd: 291

# dig @ A

; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> @ A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;     IN      A

;; Query time: 19 msec
;; WHEN: Wed Dec 09 13:32:27 MST 2020
;; MSG SIZE  rcvd: 54

I’m in agreement in principle except for the hostname. I don’t see a need to duplicate everything twice. Why not just

Datacenter and (if applicable) availability zone would be more valuable than the country code, IMO. Easier to tell where the impact is that way.

1 Like

ahh I see. Never done freeipa before, but I get you now.


Fair, We were initially talking about distributed so i wasn’t thinking DC but in that case i updated ref specifying the. dc us1 de1 is just an example. could be alphanumeric as well. more important is the registry IE: Netbox of those sytems

The naming scheme looks very good. :beers:

hi everyone,

are we sure that we should should use FreeIPA for managing DNS on

what i have typically seen is that FreeIPA had control over a subdomain, like “

and all systems managed by FreeIPA are hosted within this subdomain (with whatever level of deeper nested subdomains)

this has also the advantage, that the subdomain could be completely internal.

which would count as a security measure.


If I’m understanding it right you set it up at the root but you make use of split-brain DNS so external requests are unaffected but internal auth is routed correctly.

Somebody please correct me if I don’t have that right.

hmm, split DNS always has its problems in my experience.

it can be tricky to get right, and hard to debug. it is always strange i things resolve differently, depending on what view you are seeing.

Split DNS is only problematic if you set it up poorly. I have done this at multiple clients and have it running personally at home with no issues. Regardless if you subdomain or not, you’re going to have to do split DNS for the infrastructure.

1 Like

We’ve never had problems with Split DNS configured under Bind9 :wink:

The general scheme from first post looks ok, but I would put ID as last thing to follow “from biggest to smallest” scheme, so for eg:

us1/de1 are under dev and host 001 from dev-us1 is… well… under dev-us1 :wink:

(and question do we even need 3digits here? maybe 2 digita is enough? do you really plan to have more than 99 servers in single DC?)

@morsik I agree, largest to smallest completely makes sense. updated to reflect the translation and decrease to two digits I have just generally used 3 for ids in the past due to large numbers of servers but 2 makes sense.