Incorrect SRV records for internal DNS

Fri Feb 26 13:54:19 UTC 2016

Hi,

Using sites and having already a DNS infrastructure in the company I'm
supposed to deploy Samba I had to switch to Bind-DLZ backend. One of the
reason was internal DNS was never able, in my own configurations, to remove
correctly DNS entries. Create them was also a huge pain because
samba_dnsupdate was using "nsupdate -g" to push modification. Unfortunately
nsupdate -g implies Kerberos auth, which is not in place with internal DNS
(keytab and user are created when switching to Bind-dlz backend).
Later I spotted "nsupdate command" option into smb.conf (by default it
contains nsupdate -g) which could have been useful to avoid Kerberos auth
against a DNS which does not support that.

The preamble to give you some leads to better understand DNS backends.

First bunch of questions:
1° If your DC don't have same records into DNS, as these records are into
LDAP tree, you should have synchronisation/replication issue. Verify with
"samba-tool drs showrepl".

2° Do not hesitate to remove entries manually. This needs you first
understand clearly what records are needed. That's relatively easy, you
just have to compare to others DC.
For demoted DC with remaining DNS entries, same thing: remove them
manually. With 4.4.0 samba-tool would be able to remove dead DC (ie launch
a command on DC1 to remove DC3 which is not up any more). Note I'm using
4.4.0rc2 and I wasn't able to use this new option which was ending with
error, aborting the transaction.

Second bunch of questions:

Yes samba_dnsupdate is responsible of your issue as it is responsible to
solve these issues. As it can't do its own job, it is the issue.
Trying to change nsupdate related options into smb.conf could help you get
it work. As I said, I never tried that, can't guaranty anything.

Yes it plays a role with internal backend too.

1° removed DC DNS records have to be removed. If tools can't do that
automatically, do it by hand.
2° with internal DNS backend SOA is first declared FSMO owner until you
change it manually. samba_dnsupdate do not take care (or at least was not
taking care) of SOA or NS records.

SOA = all DNS servers which are allowed to modify the zones. That's why
they are START of authority: they are masters.
NS = all DNS server which are allowed to reply DNS request for that zone.
These are masters and slaves.

With AD DNS servers all DNS server is SOA as all DC (where DNS is running,
internally or not) can modify the zone.

With Internal DNS backend you could perhaps also defined several SOA, not
sure. You can define several NS that's for sure. You don't have to any of
that: NS records are used by remote DNS servers only when they received a
request for the zone of your AD. In that case, if this non-AD DNS server
don't have a zone type = forward to forward request to your AD DNS servers,
this non-AD DNS server don't know how to contact name servers for your AD
zone. So this non-DNS will ask root DNS servers to find NS for this AD zone.
As you will not declare you DC into some registrar, NS records are not
needed.

Same for SOA: that is not too much an issue to not have them as when you
modify DNS through RSAT / DNS console you are using AD internal stuff to
modify the LDAP tree.
But there is an issue when using samba_dnsupdate because that tool uses
nsupdate which is relying on DNS protocol, nsupdate first ask for SOA and
then send its modify request to the SOA. If no SOA, no request sent.

It is always better to keep SOA pointing to FSMO owner (in my own opinion,
some could have other opinions, they are welcome to expose them ;)

3° as explained: samba_dnsupdate is using nsupdate -g which means nsupdate
+ kerberos auth. Kerberos auth means user + credentials (here a keytab to
replace password). And with internal DNS backend no account for DNS auth.
Try to deal with nsupdate option into smb.conf.

A last thing: pdc container into DNS console must always point to FSMO
owner. Only one DC must be declare there, and a working one. And the FSMO.
If you splitted FSMO roles, I have no idea which role would have to be
declared there...

Hoping this is still understandable and that could be useful to you.

Best regards,

mathias

2016-02-24 17:28 GMT+01:00 David Mansfield <samba at dm.cobite.com>:

> Hi,
>
> I have a small domain running Samba 4.3.5 with 3 DC in 2 sites (there have
> been other DC in the past which were removed).
>
> We are not using Bind, but are using the "internal" dns. The domain was
> initially set up with samba 4.0.1 and has been updated several times since
> then.
>
> There are many SRV records that are "magically" maintained when DC are
> added or removed, or moved to differenc sites and we are seeing some
> inconsistencies in a few areas that I don't understand:
>
> 1) There are entries returned by the server for a query that don't show in
> the DNS management console, for example, none of the
> _kerberos._tcp.mysite1._sites.mydomain.com records show in the tool for
> one of my sites, but they do show in response a query. (Note: records DO
> show up in the tool for one of the other sites, and they also show up in
> the tool for the non-site-specific case).
>
> 2) There are entries that are "stale" in the tool and in the query
> response, belonging to removed DC, or belonging to DC that were moved from
> one site to another (these are site specific queries in this case).
>
> Also, I'm unsure about the role of samba_dnsupdate, which seems to fail
> for various reasons. Is this the cause of these issues?  Does
> samba_dnsupdate play a role when internal DNS is used?  It has been failing
> because:
>
> 1) it seems to reference deleted DC
> 2) it seems to reference non-existent SOA records (_ldap._tcp.pdc._
> msdcs.mydomain.com)
> 3) it cannot find certain GSS credentials (again, it's looking for a key
> for a non-existent DC, DNS/volcano.mydomain.com at MYDOMAIN.COM: no such
> entry found in hdb)
>
> These failures are not all at the same time.  #1 was present yesterday
> before the update to 4.3.5 (from 4.1.12).  #2 is present today until I
> fudge the resolv.conf on the system (this one could be an issue with our
> resolver cache). #3 is present after resolv.conf  has been fudged in
> response to #2.
>
> My best guess is that the failure of samba_dnsupdate due to vestigal
> remains of dead DC is my root cause, but I don't know how to proceed. Any
> suggestions?
>
> --
> Thanks,
> David Mansfield
> Cobite, INC.
>
>
>
>