[Samba] Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom at DOM) unknown

[Rowland Penny]

On Fri, 8 Sep 2017 13:21:34 +0200
Sven Schwedas via samba <samba at lists.samba.org> wrote:

> On 2017-09-08 13:02, Rowland Penny via samba wrote:
> > On Fri, 8 Sep 2017 12:43:40 +0200
> > Sven Schwedas via samba <samba at lists.samba.org> wrote:
> > 
> >> On 2017-09-08 12:26, Rowland Penny via samba wrote:
> >>> On Fri, 8 Sep 2017 12:03:53 +0200
> >>> "L.P.H. van Belle via samba" <samba at lists.samba.org> wrote:
> >>>
> >>>> Thanks Rowland, 
> >>>>
> >>>> Very appriciated. 
> >>>> The dnsmasq servers are explained, these are no problem in his
> >>>> setup sofar i could tell/see.
> >>>>
> >>> Yes, but do the dnsmasq servers hold all the AD records ?
> >>
> >> Define "hold"; they're used as caching servers, but all queries for
> >> ad.tao.at and subdomains are forwarded to the DCs:
> >>
> >>> server=/ad.tao.at/192.168.x #repeated for all DCs
> >>> server=/x.168.192.in-addr.arpa/x # repeated for all DCs
> >>
> >> filterwin2k etc. is **not** enabled in dnsmasq, so no queries are
> >> blocked, everything is forwarded.
> >>
> > 
> > The problem I have (and it might be me worrying over nothing) is
> > that quite a few of the AD records point to Multiple DCs and
> > dnsmasq might only retain the info for the DC it finds first. if it
> > does this and next time it is asked for the record, it returns what
> > it knows, but this DC has gone off line, what happens ?
> 
> dnsmasq handles multicast responses correctly:
> 
> > [creshal at medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.1 
> > 
> > ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.1 ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4753
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1,
> > ADDITIONAL: 0
> > 
> > ;; QUESTION SECTION:
> > ;_ldap._tcp.dc._msdcs.ad.tao.at.	IN	SRV
> > 
> > ;; ANSWER SECTION:
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 graz-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 villach-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 villach-dc-bis.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 graz-dc-1b.ad.tao.at.
> > 
> > ;; AUTHORITY SECTION:
> > _msdcs.ad.tao.at.	3600	IN	SOA
> > graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
> > 
> > ;; Query time: 4 msec
> > ;; SERVER: 192.168.17.1#53(192.168.17.1)
> > ;; WHEN: Fre Sep 08 13:20:24 CEST 2017
> > ;; MSG SIZE  rcvd: 228
> > 
> > [creshal at medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.65
> > 
> > ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.65 ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20251
> > ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 1,
> > ADDITIONAL: 0
> > 
> > ;; QUESTION SECTION:
> > ;_ldap._tcp.dc._msdcs.ad.tao.at.	IN	SRV
> > 
> > ;; ANSWER SECTION:
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 graz-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 villach-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 villach-dc-bis.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at.	900 IN	SRV	0
> > 100 389 graz-dc-1b.ad.tao.at.
> > 
> > ;; AUTHORITY SECTION:
> > _msdcs.ad.tao.at.	3600	IN	SOA
> > graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
> > 
> > ;; Query time: 3 msec
> > ;; SERVER: 192.168.17.65#53(192.168.17.65)
> > ;; WHEN: Fre Sep 08 13:20:28 CEST 2017
> > ;; MSG SIZE  rcvd: 228
> 
> First response is dnsmasq, second response is querying a DC directly.
> No difference. TTLs are honoured as well.
> 
> 

OK, you have convinced me ;-)

Seeing how you seem to know the required 'magic', do you feel up to
sharing it, if you do I will add a page to the Samba wiki.

You can send it off list if you like.

Rowland