Hai,
If the primary domain is set in windows, which is after domain join, it used
that.
Ipconfig /all and see primary DNS suffix.
The dns suffix and first dns search list should be the same.
Yes, other settings are possible, but stick to this for now.
The Primay DNS suffix is used for the register of the IP in the DNS.
The DHCP Service User MUST be a member of the DNSAdmins.
The DHCP service User SHOULD NOT have the kerberos auth requirement (disable
pre-kerberos auth), and disable password changes.
Assuming the following. DHCP on all locations.
Location 1: primary DNS : office1.example.tld ( DC1.office1.example.tld )
Location 2: primary DNS : office2.example.tld ( DC2.office2.example.tld )
Dhcp settings Loc 1:
Dns suffix : office1.example.tld
Dns search : office1.example.tld
Dhcp settings Loc 2:
Dns suffix : office2.example.tld
Dns search : office2.example.tld
If you want to be able to use the hostnames only without domainnames.
Ping dc1 on location1, resolves to dc1.office1.example.tld
Ping dc1 on location2, fails on location 2
And visaversa same problem.
Now, if you change Dns search on location 2 to :
office2.example.tld office1.example.tld
Then ping dc1 , resolves to dc1.office1.example.tld
Do note, if the name DC1 also exist in the dns of location 2, then that one
resolves.
Choose your hostnames wisely.
If you prepaird a PC on location 1 and you moved it to location 2.
Do check the DNS suffix as followed, to be sure that it matches the location or
it wil register in the other zone of the other location.
Start explorer, properties of "My computer" see computer name and full
computername.
In my lan i use pc's with DHCP and static ips, all register within the DNS
zone they should.
I reviewed my logs and compaired them to yours. That looks the same execpt i
dont have message like : >> request has invalid signature: TSIG
1592-ms-7.34-f336b9d.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634
(QUIRINIUS\$\@AD.FVG.LNF.IT): tsig verify failure (BADSIG)
The "quick fix" could be, remove these dns entries and reboot the pc.
( but wait with that )
A cause might be,
- 2 x pc with the same name.
- The rights op this object in the DNS are not correct and the "dhcp
service" user is unable to update it.
- The pc joint with a static ip and now its dhcp, then the above line applies.
For bind. ( check this first )
Check you have have within the options section in name.conf.options.
auth-nxdomain yes; # conform to RFC1035 = no
Make sure you have somewhere below options { .... } in name.conf.options.
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
Note, if you use remove dhcp things, you might need to add the ip next to
localhost..
Like this { localhost; 1.2.3.4; }
So my guess is your missing the rndc.key or its wrongly implemented.
Below is the logpart of a pc registration of one of my pc's. Static or DHCP
is exact the same in my logs.
If the above hints did not work for you, then i need the dhcp server and full
bind config.
About these first 2lines, these exist always, why i dont know exact, but that
has todo with the DLZ implementation.
Jun 8 11:54:31 named[440]: client 192.168.1.43#513: update
'primarydnsdomain.domain.tld/IN' denied
Jun 8 11:54:31 named[440]: samba_dlz: cancelling transaction on zone
primarydnsdomain.domain.tld
My log.
## Start of A / AAAA
Jun 8 11:54:31 named[440]: client 192.168.1.43#513: update
'primarydnsdomain.domain.tld/IN' denied
Jun 8 11:54:31 named[440]: samba_dlz: cancelling transaction on zone
primarydnsdomain.domain.tld
Jun 8 11:54:31 named[440]: samba_dlz: starting transaction on zone
primarydnsdomain.domain.tld
Jun 8 11:54:31 named[440]: samba_dlz: allowing update of
signer=LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD
name=loc1-pc01l12.primarydnsdomain.domain.tld tcpaddr= type=AAAA
key=1140-ms-7.1-6b6e.f0d97c7a-6b01-11e8-94bf-f04da2f88948/160/0
Jun 8 11:54:31 named[440]: samba_dlz: allowing update of
signer=LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD
name=loc1-pc01l12.primarydnsdomain.domain.tld tcpaddr= type=A
key=1140-ms-7.1-6b6e.f0d97c7a-6b01-11e8-94bf-f04da2f88948/160/0
Jun 8 11:54:31 named[440]: samba_dlz: allowing update of
signer=LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD
name=loc1-pc01l12.primarydnsdomain.domain.tld tcpaddr= type=A
key=1140-ms-7.1-6b6e.f0d97c7a-6b01-11e8-94bf-f04da2f88948/160/0
Jun 8 11:54:31 named[440]: client 192.168.1.43#50074/key
LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD: updating zone
'primarydnsdomain.domain.tld/NONE': deleting rrset at
'loc1-pc01l12.primarydnsdomain.domain.tld' AAAA
Jun 8 11:54:31 named[440]: client 192.168.1.43#50074/key
LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD: updating zone
'primarydnsdomain.domain.tld/NONE': deleting rrset at
'loc1-pc01l12.primarydnsdomain.domain.tld' A
Jun 8 11:54:31 named[440]: samba_dlz: subtracted rdataset
loc1-pc01l12.primarydnsdomain.domain.tld
'loc1-pc01l12.primarydnsdomain.domain.tld.#0111200#011IN#011A#011192.168.1.43'
Jun 8 11:54:31 named[440]: client 192.168.1.43#50074/key
LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD: updating zone
'primarydnsdomain.domain.tld/NONE': adding an RR at
'loc1-pc01l12.primarydnsdomain.domain.tld' A 192.168.1.43
Jun 8 11:54:31 named[440]: samba_dlz: added rdataset
loc1-pc01l12.primarydnsdomain.domain.tld
'loc1-pc01l12.primarydnsdomain.domain.tld.#0111200#011IN#011A#011192.168.1.43'
Jun 8 11:54:31 named[440]: samba_dlz: committed transaction on zone
primarydnsdomain.domain.tld
## Sart of PTR
Jun 8 11:54:31 named[440]: samba_dlz: starting transaction on zone
1.168.192.in-addr.arpa
Jun 8 11:54:31 named[440]: client 192.168.1.43#65400: update
'1.168.192.in-addr.arpa/IN' denied
Jun 8 11:54:31 named[440]: samba_dlz: cancelling transaction on zone
1.168.192.in-addr.arpa
Jun 8 11:54:31 named[440]: samba_dlz: starting transaction on zone
1.168.192.in-addr.arpa
Jun 8 11:54:31 named[440]: samba_dlz: allowing update of
signer=LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD name=43.1.168.192.in-addr.arpa
tcpaddr= type=PTR
key=1140-ms-7.1-6b6e.f0d97c7a-6b01-11e8-94bf-f04da2f88948/160/0
Jun 8 11:54:31 named[440]: samba_dlz: allowing update of
signer=LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD name=43.1.168.192.in-addr.arpa
tcpaddr= type=PTR
key=1140-ms-7.1-6b6e.f0d97c7a-6b01-11e8-94bf-f04da2f88948/160/0
Jun 8 11:54:31 named[440]: client 192.168.1.43#58396/key
LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD: updating zone
'1.168.192.in-addr.arpa/NONE': deleting rrset at
'43.1.168.192.in-addr.arpa' PTR
Jun 8 11:54:31 named[440]: samba_dlz: subtracted rdataset
43.1.168.192.in-addr.arpa
'43.1.168.192.in-addr.arpa.#0111200#011IN#011PTR#011loc1-pc01l12.primarydnsdomain.domain.tld.'
Jun 8 11:54:31 named[440]: client 192.168.1.43#58396/key
LOC1-PC01L12\$\@KERBEROS.DOMAIN.TLD: updating zone
'1.168.192.in-addr.arpa/NONE': adding an RR at
'43.1.168.192.in-addr.arpa' PTR
loc1-pc01l12.primarydnsdomain.domain.tld.
Jun 8 11:54:31 named[440]: samba_dlz: added rdataset 43.1.168.192.in-addr.arpa
'43.1.168.192.in-addr.arpa.#0111200#011IN#011PTR#011loc1-pc01l12.primarydnsdomain.domain.tld.'
Jun 8 11:54:31 named[440]: samba_dlz: committed transaction on zone
1.168.192.in-addr.arpa
And a bit ahead thinking, if this is setup correctly, then your
"NETBIOS" names.. Are resolvable through DNS.
(See man smb.conf : Default: dns proxy = yes).
For that i have 1 member running nmbd that is always online and provides the
browserlist.
Do note also, you dont need nmbs, if you set the "netbios resolving"
through dns.
Now this restricts you hostnames length, NETBIOS hostname's RFC is different
then dns hostname RFCs.
The golden rule is, stay below 15 char, and dont use . In netbios names.
RFC allows it but it will conflict with the dns if setup wrong, and thats easy
done.
See also :
https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and
And this link is imo a must read before you install any AD. It really helps in
preventing strang problems.
See how for you get and let us know.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens
> Rowland Penny via samba
> Verzonden: vrijdag 8 juni 2018 12:53
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Samba, AD, 'short' name resolving...
>
> On Fri, 8 Jun 2018 12:04:30 +0200
> Marco Gaiarin via samba <samba at lists.samba.org> wrote:
>
> >
> > > You are meaning here, literally: windows client try to
> > > register/update DNS using ONLY the dns provided by DHCP?
> > > Or, speaking differently the same thing, windows client suppose
> > > blindly that DNS got by DHCP ARE AD DCs?
> >
> > Ok, DNS registration seems to work, but on a (form me)
> strange way...
> >
> > Spotted in logs:
> >
> > Jun 8 10:14:25 vdcud1 named[1049]: client
> 10.5.2.127#50250: request
> > has invalid signature: TSIG
> > 1592-ms-7.34-f336b9d.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634
> > (QUIRINIUS\$\@AD.FVG.LNF.IT): tsig verify failure (BADSIG) Jun 8
> > 10:19:05 vdcud1 named[1049]: samba_dlz: starting transaction on zone
> > ad.fvg.lnf.it Jun 8 10:19:05 vdcud1 named[1049]: client
> > 10.5.2.127#56413: update 'ad.fvg.lnf.it/IN' denied Jun 8
10:19:05
> > vdcud1 named[1049]: samba_dlz: cancelling transaction on zone
> > ad.fvg.lnf.it
> >
> > note that '10.5.2.127' is in a different 'site' from
> vdcud1. Also, the
> > link under which vdcud1 is located now suffer major
> troubles, so some
> > network errors are expected.
> >
> > Effectively, after some seconds:
> >
> > Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz: starting transaction
> > on zone ad.fvg.lnf.it Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz:
> > allowing update of signer=QUIRINIUS\$\@AD.FVG.LNF.IT
> > name=QUIRINIUS.ad.fvg.lnf.it tcpaddr= type=AAAA
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz: allowing update of
> > signer=QUIRINIUS\$\@AD.FVG.LNF.IT name=QUIRINIUS.ad.fvg.lnf.it
> > tcpaddr= type=A
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz: allowing update of
> > signer=QUIRINIUS\$\@AD.FVG.LNF.IT name=QUIRINIUS.ad.fvg.lnf.it
> > tcpaddr= type=A
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: client 10.5.2.127#50735/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > deleting rrset at 'QUIRINIUS.ad.fvg.lnf.it' AAAA Jun 8
10:19:06
> > vdcud1 named[1049]: client 10.5.2.127#50735/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > deleting rrset at 'QUIRINIUS.ad.fvg.lnf.it' A Jun 8 10:19:06
vdcud1
> > named[1049]: samba_dlz: subtracted rdataset QUIRINIUS.ad.fvg.lnf.it
> > 'QUIRINIUS.ad.fvg.lnf.it.#0111200#011IN#011A#01110.5.2.127'
Jun 8
> > 10:19:06 vdcud1 named[1049]: client 10.5.2.127#50735/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > adding an RR at 'QUIRINIUS.ad.fvg.lnf.it' A Jun 8 10:19:06
vdcud1
> > named[1049]: samba_dlz: added rdataset QUIRINIUS.ad.fvg.lnf.it
> > 'QUIRINIUS.ad.fvg.lnf.it.#0111200#011IN#011A#01110.5.2.127'
Jun 8
> > 10:19:06 vdcud1 named[1049]: samba_dlz: committed
> transaction on zone
> > ad.fvg.lnf.it Jun 8 10:19:06 vdcud1 named[1049]:
> samba_dlz: starting
> > transaction on zone ad.fvg.lnf.it Jun 8 10:19:06 vdcud1
> named[1049]:
> > client 10.5.2.127#49227: update 'ad.fvg.lnf.it/IN' denied Jun
8
> > 10:19:06 vdcud1 named[1049]: samba_dlz: cancelling transaction on
> > zone ad.fvg.lnf.it Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz:
> > starting transaction on zone ad.fvg.lnf.it Jun 8 10:19:06 vdcud1
> > named[1049]: samba_dlz: allowing update of
> > signer=QUIRINIUS\$\@AD.FVG.LNF.IT name=QUIRINIUS.ad.fvg.lnf.it
> > tcpaddr= type=AAAA
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz: allowing update of
> > signer=QUIRINIUS\$\@AD.FVG.LNF.IT name=QUIRINIUS.ad.fvg.lnf.it
> > tcpaddr= type=A
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: samba_dlz: allowing update of
> > signer=QUIRINIUS\$\@AD.FVG.LNF.IT name=QUIRINIUS.ad.fvg.lnf.it
> > tcpaddr= type=A
> > key=1592-ms-7.35-f37ffc1.cc4eac93-69d4-11e8-1eb6-dc4a3e58a634/160/0
> > Jun 8 10:19:06 vdcud1 named[1049]: client 10.5.2.127#53254/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > deleting rrset at 'QUIRINIUS.ad.fvg.lnf.it' AAAA Jun 8
10:19:06
> > vdcud1 named[1049]: client 10.5.2.127#53254/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > deleting rrset at 'QUIRINIUS.ad.fvg.lnf.it' A Jun 8 10:19:06
vdcud1
> > named[1049]: samba_dlz: subtracted rdataset QUIRINIUS.ad.fvg.lnf.it
> > 'QUIRINIUS.ad.fvg.lnf.it.#0111200#011IN#011A#01110.5.2.127'
Jun 8
> > 10:19:06 vdcud1 named[1049]: client 10.5.2.127#53254/key
> > QUIRINIUS\$\@AD.FVG.LNF.IT: updating zone
'ad.fvg.lnf.it/NONE':
> > adding an RR at 'QUIRINIUS.ad.fvg.lnf.it' A Jun 8 10:19:06
vdcud1
> > named[1049]: samba_dlz: added rdataset QUIRINIUS.ad.fvg.lnf.it
> > 'QUIRINIUS.ad.fvg.lnf.it.#0111200#011IN#011A#01110.5.2.127'
> >
> > transaction happened.
> >
> > So, to me:
> >
> > a) seems that DNS offered by DHCP CAN not be the AD DNS, and client
> > find a way to register himself.
> >
> > b) client use as DNS to register some ''random'' DNS,
and seems to
> > keep them for some time...
> >
> >
> > Currently i've machine on site A that register on site C,
> and machine
> > of site B that register on site A.
> >
> >
> > AARRGGH! ;-)
> >
>
> Yes, 'AARRGGH' indeed ;-)
>
> For a computer to update its records, the records must be owned by the
> computer or the computer will be denied.
>
> You seem to be running a strange DNS setup, where the dhcp server is
> sending one dns domain, but the AD domain is in another one, not sure
> this is a good idea.
>
> What created the dns records in AD in the first place ?
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
>