× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hello Rob,

Am 28.08.2023 um 19:40 schrieb Rob Berendt <robertowenberendt@xxxxxxxxx>:

Our original internal domain name is dekko-1. While that met specs it just isn't cutting it anymore.

Yeah, people have thought for a long time, it's a good idea to use .local or some other makeup stuff. From my own decades-long experience: Sooner or later you'll run into problems, especially when it comes down on machines sending email, such as cronjobs on Linux.

One, many things go nuts with a dash in the domain name.

Yes, this is one of the braindead inventions from early LAN manager days on:
- LAN Manager names may contain _ but will not accept -
- DNS Names may contain - but _ is only allowed for certain resource record types.

Two, getting a cert from a trusted authority for that is difficult.

That's why I always try to pester customers into setting on an "external" domain, and append a short name (internal, int, corp, …) to the DNS name for LAN purposes.

Our PC domain name is still dekko-1.

What is a "PC domain name"? Are you talking about the Microsoft stuff? Are you talking about the workgroup name, or the AD? => Check with your Windows people.

Our CA has a wildcard cert for us for dekko.com an we've been rolling that out pretty well for internal/external sites.

And once the key is stolen from the external server, each and every service using this certificate can be seen as potentially compromised. Ask Microsoft. They had something similar happen.

I changed one lpar
CFGTCP,
12. Change TCP/IP domain information
Domain name . . . . . . . . . . DMNNAME
from dekko-1 to dekko.com and it didn't seem to have any adverse effect
with IFS shares, etc. Even after I bounced TCP.

When/what will be adversely affected by this change?

If the DNS you're using is set up correctly, I see no show stopper. The Windows guys with AD have way more fun to endure with such a rename. Especially with MS Exchange.

You maybe should check *outgoing* services when you address those with a short name instead of an FQDN. But then, you can easily work around this by adding search domains. This is a list of domains which are appended in order until DNS finds a match.

One thing I'm noticing is that, on another lpar, it has a different domain name, corp.dekko.com. This was a short lived fad. But after I assigned a ssl cert for the same wildcard *.dekko.com I'm having no issues with secure telnet. Back when we were using corp.dekko.com for other stuff we would have to get that it's own wildcard. TPTB decreed we were no longer ordering that wildcard. We've been able to roll pretty well with that decision.

While wildcard certs are a good way to save money, their global nature appalls me.

Where I work, we're using Letsencrypt for everything which is directly reachable from the internet. Today, scripts to cope with that IMO overly complicated MS Windows certificate handling exist, and those also managed to beat Exchange into submission. Fire and forget.

For internal machines, we have an internal AD based Microsoft CA. Everything Windows does stuff automatically, everything else needs cursing and regular manual labour.

Again, where does it care what this domain is?

This is to help in discovering mismatches between DNS- and Cert name. With wildcards, you essentially let go of this additional anti-DNS-tampering measure, and shift focus to the domain name.

From experience, per host, make all of the names equal:
- forward DNS
- reverse DNS
- Cert CN (Common Name)

And you're set.

HTH.

:wq! PoC




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.