[Samba] Invalid PTR record in reverse lookup zone

[L.P.H. van Belle]

If i may give a small remark on a comment's here..  

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens andi 
> via samba
> Verzonden: dinsdag 12 november 2019 20:25
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Invalid PTR record in reverse lookup zone
> 
> 
> Hmm. OK. Just a remark: I finally found the reason for the invalid
> PTR record update in the reverse lookup zone. It was sssd. It 
> is actually a known problem with sssd in "ad" mode. It uses gethostname() 
> and expects it to be the fqdn. Then it invokes "adcli" with the hostname 
> to set the PTR record, which is then wrong since gethostname() does not 
> return the fqdn in all configurations.
> 

>It uses gethostname() and expects it to be the fqdn.
Normaly yes, the hostname is always/should displayed in fqdn.

> which is then wrong since gethostname() does not 
> return the fqdn in all configurations.
Which is why you should use a correct setup in /etc/hosts

If i look at yours. 
This part.
=================================================
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether f4:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.183.5/24 brd 192.168.183.255 scope global dynamic eth0
       valid_lft 800299sec preferred_lft 800299sec
    inet6 2003:e3:570b:9400:f6xx:xxff:fexx:xxxx/64 scope global dynamic mngtmpaddr 
       valid_lft 6558sec preferred_lft 1158sec
    inet6 2003:e3:5705:5200:f6xx:xxff:fexx:xxxx/64 scope global deprecated dynamic mngtmpaddr 
       valid_lft 3695sec preferred_lft 0sec
    inet6 fd1f:6d10:24a0:1:f6xx:xxff:fexx:xxxx/64 scope global dynamic mngtmpaddr 
       valid_lft 6558sec preferred_lft 2958sec
    inet6 fe80::f6xx:xxff:fexx:xxxx/64 scope link 

-----------
       Checking file: /etc/hosts

127.0.0.1	localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

=================================================


If this was my config, it would probely looked like this. 

DNS Domain: ad.home.arpa
FQDN: kronos.ad.home.arpa

/etc/resolv.conf
domain ad.home.arpa
search ad.home.arpa
nameserver 192.168.183.5 

/etc/hosts
127.0.0.1	localhost
192.168.183.5 kronos.ad.home.arpa kronos


# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
2003:e3:570b:9400:f6xx:xxff:fexx:xxxx kronos.ad.home.arpa kronos
2003:e3:5705:5200:f6xx:xxff:fexx:xxxx kronos.ad.home.arpa kronos
fd1f:6d10:24a0:1:f6xx:xxff:fexx:xxxx  kronos.ad.home.arpa kronos

If you apply it like that, and you dns zones are setup correcty, you can and should use fqdns/ip's in all your configs. 
And A-PTR's must be set offcourse.

If your applying spn's to this, which you also do, for nfs and/or cifs and kerberos for auth, 
It save you from problems with the spn resolvings.

Just set only kronos.ad.home.arpa for the spns and it just works in all configs. 

Use CNAMES for all other hostnames you need and you spn with kerberos also keep working. 

This part,
> I tried to analyze the problem and finally found, that
> the obtaining a ticket for nfs service failes in this 
> case because of a wrong spn: nfs/servername at ... instead of
> nfs/fqdnservername at ... is used by the clients to get the 
> ticket.

No, this is the normal order of nfs to detect the nfs spn, even more are checked.
I tried to find the article, but could not find it, and its late.. 
its something like spn/HOSTNAME.FQDN spn/HOSTNAME spn/HOSTNAME$ root/HOSTNAME.FQDN
If your automounting in user homedir's you might need to add the root/ spn if its not working. 
That depends a bit on the rights setup. 

> 
> I tracked the problem down to an invalid PTR record for
> the DC in the reverse lookup zone. The ptr record
> had only the hostname but not the fqdn set.
This is due to, not haveing a fully correct /etc/hosts at time of creating the domain, most probely.


> 
> I manually fixed this using samba-tool dns add/delete and nfs 
> mount worked again. Unfortunately after a while the record
> gets changed back again. I was unable to figure out how this 
> happens. It seems that the change occurs while 'samba_dnsupdate'
> tool is running but I didn't found were in 'samba_dnsupdate'
> the PTR record is set. I didn't found a suitable log
> setting in smb.conf which would help me to find the origin
> of the dns change (loglevel 12 for dns produces lots of output
> but nothing related to setting PTR records)

I dont know, if its fixed already, if not, how i check it. 
I use the windows RSAT tool, ADUC. Enable advanced in view. 
And there check in attribute editor, for the AD-DC the needed values on the server object. 
Like : dNSHostName and servicePrincipalName 
The keytab file might need a check also and reboot, check again. 

Just some advice/tips. 


Greetz, 

Louis