Nameserver <<ip>> failed to resolve SRV records for domain <<domain.name>>. This may indicate a DNS misconfiguration on the TrueNAS server.

[subsequent]

Hi!

After upgrading to bluefin (scale) from core my AD connection broke. It was working fine on core. I tried to reinstall from scratch but i still get the error message:

Nameserver <<ip>> failed to resolve SRV records for domain <<domain.name>>. This may indicate a DNS misconfiguration on the TrueNAS server.

Anyone else having this issue?

When i do dig to the domain it resolves as it should and we haven't done any DNS changes.

 

[subsequent]

After some digging around i found out that in network settings the domain name was written with lower case. And the AD join needs it to be in uppercase. This was the error message that made me find this.

Error: (EINVAL) Reverse lookup of x.x.x.x points to server.domain.name. rather than our hostname of server.DOMAIN.NAME..

 

[anodos]

After some digging around i found out that in network settings the domain name was written with lower case. And the AD join needs it to be in uppercase. This was the error message that made me find this.

Hmm... that check should be case-insensitive. That said, some protocols (like kerberos) are case-sensitive and so normalizing on upper-case is a good idea.

 

[subsequent]

Yes, it may be a good idea to implement upper-case if "Inherit domain from DHCP" is checked as it was in my case.

 

[Remnant1350]

I am having this exact same issue, and all the suggested fixes have failed. I have two Scale servers, and have replicated all settings exactly between them. One is able to join the AD Domain, the other is not. There were no issues prior to upgrading to 22.12.1 on the primary server that cannot be domain joined.

 

[techant]

I can confirm this issue and have not been able to resolve it either. Is there anyway to bypass the middleware dns lookup with /etc/hosts.

 

[Remnant1350]

Adding the Domain Controllers to the hosts file has allowed the server to join the domain properly. Behavior I was seeing was the server being able to join the domain, before failing. So I will post back if the configuration fails again.

 

[Remnant1350]

Bad news, my AD failed on the truenas again. I got this error

• Failed to check for alert ActiveDirectoryDomainHealth: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/plugins/alert.py", line 776, in __run_source alerts = (await alert_source.check()) or [] File "/usr/lib/python3/dist-packages/middlewared/alert/source/active_directory.py", line 44, in check await self.middleware.call("activedirectory.check_nameservers") File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1386, in call return await self._call( File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1335, in _call return await methodobj(*prepared_call.args) TypeError: check_nameservers() missing 1 required positional argument: 'domain'

 

[techant]

Now I have this error _kerberos._tcp.truenas._sites.{{hostname}}.: Nameserver 10.0.3.3 failed to resolve SRV record for domain {domain}. This may indicate a DNS misconfiguration on the TrueNAS server. Why are there periods followed by underscores inside the dns name? Changing /etc/hosts did not seem to change anything either. AD is still unable to be reached. nslookup from the host it self works and the system is able to resolve the ad server but the gui/middleware seems to be unable to work.

 

[anodos]

Now I have this error _kerberos._tcp.truenas._sites.{{hostname}}.: Nameserver 10.0.3.3 failed to resolve SRV record for domain {domain}. This may indicate a DNS misconfiguration on the TrueNAS server. Why are there periods followed by underscores inside the dns name? Changing /etc/hosts did not seem to change anything either. AD is still unable to be reached. nslookup from the host it self works and the system is able to resolve the ad server but the gui/middleware seems to be unable to work.

That's a lookup for kerberos SRV records for your AD domain that appears to be failing for 10.0.3.3. Have you tried to use dig to look up the SRV? Can you maybe send me a debug and I'll take a look at the exact backtrace?

 

[techant]

Yes we did try to create a srv record on our windows dns server but it seems like even adding a host alias to /etc/hosts did not seem to work.

/etc/hosts
```
_kerberos._tcp.truenas._sites.{{domain}}.local _kerberos._tcp._sites.{{domain}}.local
```

```
user@truenas:~$ nslookup -type=SRV _kerberos._tcp._sites.{{domain}}.local
Server: 10.0.3.3
Address: 10.0.3.3#53

_kerberos._tcp._sites.{{domain}}.local service = 0 100 88 truenas.{{domain}}.local.
```

 

[techant]

Did something change with dns lookup since the previous version 2 updates ago? Why was it working previously without having to make a srv record?

 

[techant]

Ok I have resolved the issue yes the path of domain/_sites/truenas needs to be created on the dns server. Then the srv records for _ldap,_kerberos have to be created under that new subdomain. Then it seems to be healthy and working as intended.

 

[anodos]

Please send me a PM and we can correspond via email about the exact DNS changes you had to make. I can loosen up validation. I presume this is a case where the site-specific SRV records didn't exist in AD DNS?