Apparently Sonoma is processing DNS differently that prior releases.
A FMS machine, with the Fully Qualified Domain Name (FQDN) is registered with both a "www." prefix and with the base domain. Prior to Sonoma, using the base domain, without the WWW, resolved. Now in Sonoma, if the WWW prefix is not there, the domain will not register. This includes from a browser, or from FMP.
Are you speaking about the local network or access via WAN?
Are you sure that the DNS server is configured correctly?
What does the AAA record look like?
WAN access (there is a local DNS server if I were on premise).
And of course, the private IP does not resolve, so FMP (or the browser) cannot connect. Adding the WWW to the FQDN resolves
How should the external DNS server know any local IP address? That's normally impossible.
IPv4 or IPv6?
You would logically think so. Maybe someplace cached (as I also use those computers on site as well as remotely)??? There is no way I can imagine that a private IP would identify (but at least not resolve) through the PFSense NAT setup. Scratching my head over this one.........I also think that the non-control computer had been connected to the on premise FMS machine prior to the DNS server being set up on-prem, so there was a config direct to an IP, not a domain name. (and a separate one for a FQDN). When I get back at that site, I'll check to see of the other favorite to the IP still exists on that box.
An M1 mini and a m1Max MBPro (both Sonoma) side by side (test and control units). The mini could not resolve the FMS machine without the WWW. Another mini, running Ventura, and 2 different WIndows 11 boxes resolved both the WWW.domain.com and domain.com without issue.
Now here it is 2:30 am. For now I‘ll go to bed. I‘ll get back to this tomorrow.
That sounds extremely unsafe. I'm wondering the same thing as @mipiano, how does dig get access to the private IP?
AFAIK, it can’t. It has to be some default cached value from a prior, pre-internal DNS connection but I don’t see how that is likely either
Take a look at the /etc/hosts file. Maybe there is an entry with the local IP address in there.
The local IP for that domain is in the etc hosts file for the computer that works with both www and without. I can't check the other until I get onto the client site.
Is there no local DNS server? Then the /etc/hosts entry/entries for this FMS would not be needed.
There is a local DNS server on premise where the FMS machine is (running on the same box, using NAMO and configured as first resolver IP in the firewall DNS settings).
I was at a remote site, where I had just upgraded 2 machines to Sonoma, and one would connect without the WWW and the other would not. DNS at that site is Cloudflare (1.1.1.1) and Google (8.8.8.8)
The etc host file is an artifact of the days before I got the client to allow a local DNS instance
[Edit:] This artifact may be the cause! /etc/hosts is resolved first before the request is sent to the DNS server.
Maybe, but why one machine and not the other? The local host file would have not resolve if not on that network. That machine worked both with and without the www prefix. I need to explore a bit more into the differences, but as just adding the WWW fixed the domain resolution issue, it won't be a high priority. Just wanted to expose the problem in case others ran into this in upgrading to Sonoma. (hence the post to the "heads up" channel).
Well, I am on Sonoma and don't have this issue …
Hey Kirk,
I have a similar setup and would add two places to check.
Every machine should have the IP of the FMS as 1. DNS Server,
Normally you configure that in the DHCP server centrally.
The FMS machine with Namo should point probably to itself 127.0.0.1.
then you should resolve myserver.domain.com to the IP of the FMS and all Custom names like www.myserver.domain.com
Then.. inside the LAN dig should resolve to FMS LAN IP
Ouside the LAN it should resolve to your fqdn's public IP
That's the way it is configured, although instead of localhost, it is set for the static IP of a FMS/NAMO machine.
I'l be back in that client office next week, and check the Mac desktop that was not resolving the WWW prefix and see what I can find.