Hi Rowland / Denis,
Thanks for your quick reply. Find below smb.conf and named.conf for your
reference.
Few things I wish to clarify here.
1. We have installed the samba on CentOS 7.4 not on Debian OS. As,
packages from repositories are of version 4.3 and 4.4, we have used
sources, compiled & installed the package.
2. named.log had an entry "DNSKEY (.) could not be obtained, Time
Out".
But named-checkconf did not return any errors.
3. We did run dbcheck and dbcheck --cross-ncs. It threw some erros. We
fixed it. Yet, DNS could not resolve.
We are now simulating the production environment in our testing virtual
machines. We are trying to reproduce the error to check really what went
wrong.
We request for your guidance in getting to the bottom of the issue and
resolving it. Keeping the security requirements in mind, we have to
upgrade to 4.7 and above as early as possible.
Look forward for your guidance.
_*smb.conf*_
# Global parameters
[global]
netbios name = DC1
realm = ***********.COM
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate
workgroup = *********
server role = active directory domain controller
idmap_ldb:use rfc2307 = yes
ldap server require strong auth = No
#eventlog list = Application System Security SyslogLinux
eventlog list = Application, Security
#Log Level
log level = 3
log file = /var/log/samba/pdc.%T.log
[netlogon]
path = /usr/local/samba/var/locks/sysvol/**********.com/scripts
read only = No
[sysvol]
path = /usr/local/samba/var/locks/sysvol
read only = No
[shares]
comment = For all Users
path = /home/shares
read only = No
writable = Yes
**_**_
_*named.conf*_
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
/*
- If you are building an AUTHORITATIVE DNS server, do NOT
enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you
need to enable
recursion.
- If your recursive DNS server has a public IP address, you
MUST enable access
control to limit queries to your legitimate users. Failing
to do so will
cause your server to become part of large scale DNS
amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
forwarders {
172.##.###.10; //***** internal DNS 1
172.##.###.90; //****** internal DNS 2
};
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/usr/local/samba/private/named.conf";
--
Thanks & Regards,
Anantha Raghava
eXzaTech Consulting And Services Pvt. Ltd.
Ph: +91-9538849179, E-mail: raghav at exzatechconsulting.com
<mailto:raghav at exzatechconsulting.com>
URL: http://www.exzatechconsulting.com
<http://www.exzatechconsulting.com/>
Dell Technology Partner, 3CX - Open Software IP PBX Partner, RedHat
Solutions Partner
Open Source Software Solutions - oVirt, SMARTDesktop, Apache Metron,
OpenVPN, OPNSense......
DISCLAIMER:
This e-mail communication and any attachments may be privileged and
confidential to eXza Technology Consulting & Services, and are intended
only for the use of the recipients named above If you are not the
addressee you may not copy, forward, disclose or use any part of it. If
you have received this message in error, please delete it and all copies
from your system and notify the sender immediately by return e-mail.
Internet communications cannot be guaranteed to be timely, secure, error
or virus-free. The sender does not accept liability for any errors or
omissions.
Do not print this e-mail unless required. Save Paper & trees.
On 22/01/18 3:25 PM, Denis Cardon wrote:> Hi Anantha,
>
>> The upgrade from 4.6.5 broke all the servers. Although the services
were
>> running and there is no error message, DNS resolution failed. Even from
>> inside the domain controllers, DNS queries failed.
>>
>> Samba Version 4.7.1 and Named Version 9.9.4. The same issue happened
>> with samba version 4.7.3 and 4.7.4
>>
>> We had to revert back to 4.6.5 to bring the servers back online. Now I
>> have few questions:
>>
>> 1. On the the DCs, we stopped both samba-ad-dc and named services,
just
>> compiled samba 4.7.1 & installed without making any changes to the
>> folders or the files. On three of our 4 servers it worked without any
>> issues. On the fourth server which owned all FSMO roles, although both
>> samba-ad-dc and named services were running (no errors were thrown),
DNS
>> could not respond to any queries. For some time, two of the servers
were
>> working and they also stopped resolving any names. Whether database
>> replication faulted the other working servers as well, we are not
having
>> clarity.
>>
>> 2. Is there any specific procedure to be followed to upgrade? As
>> mentioned above, we have just compiled the latest version from sources
>> and installed on 4.6.5. The process that worked on 3 servers failed
&
>> broke the DNS on 4th server that owned all FSMO roles. Should we have
>> transferred the FSMO roles to other working servers before upgrade
>> process?
>>
>> 3. Since samba 4.7.x is a multi-process server, is there any DB locking
>> issue, that is stopping named process from reading DB?
>
> Like you are pointing out, 4.7 gets a performance boost with more
> multi-processing. However until 4.8 gets out, you may get issues with
> memory consumption if you have too many LDAP or RPC connections
> simultaneously. But it can be mitigated (see previous post on the
> subject). But it didn't trigger any issues on DNS side for us.
>
> By the way, in any case you should go with 4.7.4 and not 4.7.1.
>
>> 4. In named logs, we say that it was unable to obtain the DNAKEY (.)
and
>> it was timing out. But this error was shown even before the upgrade. It
>> turned out be a warning that can be safely ignored.
>>
>> 5. We switched back from BIND9_DLZ DNS Back end to SAMBA_INTERNAL DNS
>> Back end, the same issue continued. DNS failed to respond to any
>> queries. Even internally with in DCs, ping the self could not resolve
>> name & returned error.
>
> The fact that internal DNS was not working would rule out a problem
> with your Bind-DLZ configuration...
>
> Did you run samba-tool dbcheck --cross-ncs after upgrade? There has
> been some issues on 4.6 to 4.7 upgrades with group membership, but I
> never had an issue on the DNS partitions though. Do you have some
> Windows AD join to you Samba domain?
>
> Like Rowland was saying, could you post your smb.conf file too see if
> there is anything weird in there.
>
> By the way, unless you have specific requirements, you should stick to
> pre-compiled deb packages. There are many options, from Samba Plus
> packages with direct support from SerNet, the package from LPH van
> Belle, or ours at TIS. It would help to rule out any build/compilation
> issues.
>
> Cheers,
>
> Denis
>
>
>
>>
>> 6. Finally, when we downgraded, everything started working properly. on
>> the version 4.7.4, we just compiled 4.6.5 and installed. Just reversed
>> the upgrade process. It started working. All servers came back to
>> normal. This is really surprising. Since it is a production setup that
>> is serving the entire India, we just reverted all servers back to
4.6.5.
>>
>> 7. While we observed some network latency, it is not the culprit for
>> stopping of response to DNS queries that stopped the entire 9000 users
>> from logging in.
>>
>> Now we are simulating the same error in our lab setup to figure out the
>> root cause for the issue, before upgrading the production servers.
>>
>> I seek your expert guidance and help to get to the root cause of the
>> problem.
>>
>