-1

Suppose we have a inner-facing network that spans several geographical jurisdiction - this network can only accessed from our offices with special HSM installed, and we want to enable domain-name-based HTTPS connection with a private CA to enhance the effectiveness of access control.

What root (or starting) domain is most appropriate for this purpose?

  • home.arpa Don't seem to be appropriate as it's for Residential LAN.

  • 10.in-addr.arpa. and 168.192.in-addr.arpa. seems applicable to us, except it has numerical components and requires special DNS configuration.

Improve this question
1
  • Unfortunately, questions about protocols above OSI layer-4 are off-topic here. You could try to ask this question on Server Fault for a business network.
    – Ron Maupin ♦
    Commented Jan 25, 2020 at 15:28

1 Answer 1

Reset to default
1

Simply put: if you require no connectivity from the outside and keep everything private permanently you'd want to select a TLD or SLD/TLD combination that isn't used and isn't likely to appear.

The standard procedure is to use the reserved .local TLD and something along companyname.local. (.local is actually reserved for link-local name resolution - RFC 6762 - but you don't have to use that - you might need to make sure that all nodes are OK with that TLD though [thx Marc].) [edit] It seems this procedure is obsolete... For internal use, a subdomain of a publicly registered domain is recommended (e.g. corp.companyname.tld).

A CA service doesn't require a domain of its own, so you can also use any DNS name from your internal DNS like ca.companyname.local.

Do NOT use anything that's already used elsewhere, including .arpa.

If you do consider public availability you simply register the domain in some available TLD and use it as you like.

Improve this answer
4
  • 3
    As you point out, .local is reserved for link local name resolution, and I think that's for good reasons. I've come across mDNS implementations that check for unicast DNS resolvability of .local. If .local's SOA could be resolved, the given mDNS implementation threw an errror and stopped itself. It took me a while to get my ISP understand the problem and to fix that in the recursive DNS servers they assigned via DHCP or PPP. I suggest: Consider .local in unicast DNS only for very well controlled environments, where end systems name resolution behaviour is thoroughly understood
    – Marc 'netztier' Luethi
    Commented Jan 25, 2020 at 11:32
  • 1
    @Marc'netztier'Luethi Agreed - while it's seeing widespread use I haven't come across a problem with it though. For internal use, I like companyname.int better since you can even register it normally (which you might not need if you don't care about a collision with some namesake).
    – Zac67 ♦
    Commented Jan 25, 2020 at 11:48
  • 1
    To repeat what @Marc'netztier'Luethi has said. .local has a specific defined purpose. Using it for anything other than that purpose is a mistake. Unfortunately, "just use .local" is all over the place. It's the same level of BS as all the sites using 224.0.0.1 in multicast "examples".
    – Ricky
    Commented Jan 26, 2020 at 4:39
  • If you're certain you don't want to register under some top-level domain, you could consider the reserved two-letter codes of ISO 3166-1 (AA, QM-QZ, XA-XZ, and ZZ) which are for user assignment (as "countries"); I believe IANA has them reserved as ccTLDs (but I'd check before implementing!).
    – jonathanjo
    Commented Feb 11, 2020 at 12:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.