DNS Health stays Unresolvable until admin API restart

souverain

Hello,

I would like to report a possible issue with the grommunio admin web interface or grommunio-admin-api DNS Health check.

Anonymized environment:

self-hosted grommunio server;
mail domain configured and active in grommunio-admin;
admin interface accessed through the web UI;
public DNS configured for MX, SPF, DKIM, DMARC and autodiscover.

Issue:
In the grommunio admin web interface, the “DNS Health” section showed several DNS warnings/errors. The MX check was displayed in red, and other checks such as SPF, DKIM, DMARC and autodiscover were not shown as fully valid.

When clicking on “MX Records”, the dialog displayed:

Internal DNS: Unresolvable
External DNS: Unresolvable
MX Domain: Unresolvable
Resolved IP: Unresolvable
Reverse lookup: Unresolvable

However, manual DNS checks were correct.

Checks performed:

the domain MX record resolved correctly;
the MX target resolved correctly to the expected public address;
the authoritative DNS servers returned the expected records;
SPF, DKIM, DMARC and autodiscover were present and resolved correctly;
DNS resolution from the grommunio server itself was also correct.

I then tested the Python function used by grommunio-admin-api directly:

cd /usr/share/grommunio-admin-api
python3 - <<'PY'
from tools.dnsHealth import fullDNSCheck
import json
print(json.dumps(fullDNSCheck("example.org"), indent=2, ensure_ascii=False, default=str))
PY

The result correctly returned the expected mxRecords values, including internalDNS, externalDNS, reverseLookup and mxDomain.

I also ran the same test as the actual grommunio-admin-api service user, and the result was still correct.

Nginx logs also showed that the browser was calling the DNS Health endpoint successfully with HTTP 200:

GET /api/v1/domains/<domain-id>/dnsCheck

Despite this, the web interface still displayed “Unresolvable” in the MX Records details.

Observed workaround:
After restarting the admin API service:

systemctl restart grommunio-admin-api

and then hard-refreshing the browser page, the DNS Health display became correct and the previously red/orange checks turned green.

Conclusion:
This does not seem to be a real DNS configuration issue. It looks more like an inconsistent state, cache issue, uWSGI worker state issue, or synchronization problem between grommunio-admin-api and the web interface.

The fullDNSCheck() function returned correct values when executed directly, including as the service user, while the web UI kept displaying “Unresolvable” values until grommunio-admin-api was restarted.

Questions:

Is this a known behavior?
Could the admin interface provide a “Refresh DNS check” button?
Are temporary DNS resolution failures cached somewhere?
Could the UI avoid keeping an “Unresolvable” state when fullDNSCheck() later returns valid results?
Should restarting grommunio-admin-api be documented as a possible workaround when DNS Health appears inconsistent?

Thank you.

Steakie

Thank you for the detailed report!
I encountered a similar issue in the past which i supposedly fixed but it seems that there are even more issues. What i observed was that during a faulty initial startup of the API due to networking issues the DNS-Resolver isn't initialized correctly.

I just tried to reproduce your issue, but i am unable to... i assume that you are using the latest API version?

souverain

Steakie Hi,

Yes, I am using the latest available version from my repositories.

The installed package is:

grommunio-admin-api-1.18.19.me5b13cd-lp156.13.1.noarch

The issue happens after a full server reboot: the DNS Health checks in the admin web interface show some entries as unresolved/red/orange, even though DNS records are actually correct.

If I restart only the admin API with:

systemctl restart grommunio-admin-api

and then hard-refresh the browser, the DNS Health status becomes correct again.

So it seems that the problem is not the DNS configuration itself, but possibly something in the admin API state or startup timing after boot.

Steakie

souverain yea it has to be the startup and initialization (again).

Since you described that you are getting a 200 return code, the actual response would be interesting. Can you check in the inspector what the API returns in the "faulty state" (you can sensor IPs obviously)? Also, do you have any tips on how to reproduce that faulty state?

Actually i am a bit confused... you mentioned manual DNS checks. What did you mean by that? And when did you do them? After or before restarting the API?

souverain

Steakie Hi,

I reproduced the faulty state after a full server reboot and captured the API response from the browser inspector.

The request is:

dnsCheck

HTTP status:

200

Here is the response body in the faulty state, before restarting grommunio-admin-api:

{
"autoconfig": {
"externalDNS": null,
"internalDNS": "xxMyPublicIPxx"
},
"autodiscover": {
"externalDNS": null,
"internalDNS": "xxMyPublicIPxx"
},
"autodiscoverSRV": {
"externalDNS": null,
"internalDNS": "0 0 443 mail.mydomain.tld.",
"ip": null
},
"caldavSRV": {
"externalDNS": null,
"internalDNS": null
},
"caldavTXT": {
"externalDNS": null,
"internalDNS": null
},
"caldavsSRV": {
"externalDNS": null,
"internalDNS": null
},
"carddavSRV": {
"externalDNS": null,
"internalDNS": null
},
"carddavTXT": {
"externalDNS": null,
"internalDNS": null
},
"carddavsSRV": {
"externalDNS": null,
"internalDNS": null
},
"dkim": {
"externalDNS": null,
"internalDNS": "DKIM record is found here, but I redacted the public key for readability"
},
"dmarc": {
"externalDNS": null,
"internalDNS": "\"v=DMARC1; p=none\""
},
"externalIp": "xxMyIPxx",
"imapSRV": {
"externalDNS": null,
"internalDNS": null
},
"imapsSRV": {
"externalDNS": null,
"internalDNS": null
},
"localIp": "192.168.1.5",
"mxRecords": {
"externalDNS": null,
"internalDNS": null,
"mxDomain": null,
"reverseLookup": null
},
"pop3SRV": {
"externalDNS": null,
"internalDNS": null
},
"pop3sSRV": {
"externalDNS": null,
"internalDNS": null
},
"submissionSRV": {
"externalDNS": null,
"internalDNS": null
},
"txt": {
"externalDNS": null,
"internalDNS": "\"v=spf1 mx -all\""
}
}

So in the faulty state, the API returns HTTP 200, but almost all externalDNS values are null. Some internalDNS values are present.

To reproduce on my side:

Fully reboot the grommunio server.
Open the grommunio admin web interface.
Go to DNS Health.
The interface shows MX as red and several recommended checks as orange.
Capture the dnsCheck response: the API returns 200, but externalDNS is null.
Then I restart only the admin API:

systemctl restart grommunio-admin-api

After a hard refresh of the browser, DNS Health becomes correct again.

About my “manual DNS checks”: I meant DNS checks done outside of the grommunio admin interface, from the shell / DNS tools. I did those checks while the admin interface was still in the faulty state, before restarting grommunio-admin-api. They confirmed that the DNS records themselves were already correct.

Steakie

souverain thanks again for the extensive information.
So since most external resolves fail, i assume this is the same bug i ... tried to solve ... last time.

I just reimplemented the resolver initialization again to be initialized upon first use of the DNS health endpoint and not during startup.

Can you update your system (or at least the API) and try again?

souverain

Steakie I'd like to, but when I launch the update request from the administrator interface, I get this message: No updates found.