4

Preface: I am not a Windows admin. I am a Linux admin.

I have a Windows 2016 server with AD DNS that handles internal DNS forward and reverse lookups.

Somewhere, somehow, some process is automatically adding PTR reverse lookup records for CNAMEs. This is breaking our Kerberos authentication for SSH between servers, as the canonical lookup of a host that has CNAMEs will return too many FQDNs and Kerberos balks.

The Kerberos SSH problem was resolved when I removed the CNAME reverse lookups.

Then, the next day, presto! all the PTR -> CNAME entries were back in AD DNS

Example, from the top (I've changed the names to be generic, but the overall setup is the same):

A pair of network operations boxes that run SMTP and Squid proxy have A records

netops01.example.com -> 10.1.2.3
netops02.example.com -> 10.4.5.6

And this same box has CNAMEs

netops
proxy
mailserver

For some reason, there are reverse lookup entries in AD DNS like so:

3.2.1.10.in-addr.arpa. 3600 IN  PTR netops.example.com
3.2.1.10.in-addr.arpa. 3600 IN  PTR proxy.example.com
3.2.1.10.in-addr.arpa. 3600 IN  PTR mailserver.example.com
3.2.1.10.in-addr.arpa. 3600 IN  PTR netops01.example.com

The last entry is the A record for this host. All the others are CNAMEs to that A record + another A record for the second host.

Neither I or the other admin that handles ops created these. Nor did we set up any scheduled task to recreate reverse lookups. Nor can I imagine a good reason to have a reverse lookup point to CNAMEs or to multiple results. (Maybe there is a good reason? I've never done this before, though)

So, I deleted all the reverse lookups except the A record one. Kerberos SSH works!

Next day, the records all returned.

I'm not even sure how on Windows to troubleshoot (thus my preface at the top)

  • How can I find in the Windows logs what performed this action?
  • Is there something about Windows DNS that would automatically do this? (Create PTRs for CNAMEs)
  • Is there a way to turn that off?
  • Anything else I'm missing?
1

Answering Myself

I found what I was missing. Two things:

  1. These were not, in fact, CNAMEs. They were A records with multiple hosts listed for the purpose of load balancing.

    Since they were A-records, they did have a checkbox along the lines of "automatically create related PTR record"

    I unchecked that for these records. That didn't actually seem to fix the problem described here: the PTR records are still being rebuilt each morning.

  2. However, that's not the solution I was looking for, anyway. The underlying problem was that Kerberos wasn't working. Well, that was easy to resolve by adding this "rdns" setting to /etc/krb5.conf

    [libdefaults]

    rdns = false

0

By default, Windows always tries to register both forward and reverse lookups using dynamic DNS.

You can disable this functionality either on the clients that are registering themselves, or on the DNS server, or both. The quickest way to resolve your immediate problem would be to disable dynamic DNS support for the relevant reverse lookup zones. In the longer run, depending on your circumstances, you may want to disable it in the forward zones as well.

I found a screenshot showing the relevant setting on the DNS server here. You want to select "None".

There is more information on disabling dynamic update on the clients here and here. This isn't essential but otherwise the clients will generate periodic event log messages because the dynamic DNS requests are being rejected by the server.

NB: you should not disable dynamic updates on the Active Directory domain controllers or for the Active Directory zones such as _msdcs that are used by the domain controllers to store information about the domain infrastructure. This will break Active Directory.

  • I'm not sure this addresses the CNAME component. How would clients even know they have a CNAME that needs a PTR record? And why would I ever want a PTR to a CNAME in the first place? – JDS Sep 2 '18 at 15:50
  • Oh, also, I forgot to mention: We have exactly zero (0) Windows clients. All of these clients are Linux boxes that connect and register with AD using Centrify Express. Not sure if that matters in this context though – JDS Sep 2 '18 at 15:52
  • Depends on how closely Centrify Express mimics the behaviour of a Windows client, I suppose. It is certainly potentially relevant and should be added to the question. Also, just to be sure: you're not using DHCP addressing for these machines, are you? – Harry Johnston Sep 2 '18 at 18:49
  • ... try checking who owns the entries in question, that might give you a clue as to where they are coming from. In the DNS Manager, right-click on the entry and select Properties. Go to the Security tab and click Advanced. Go to the Owner tab and look under "Current owner". – Harry Johnston Sep 2 '18 at 22:42
  • The machines are using DHCP addressing but the DHCP server is AWS EC2, not Windows AD. – JDS Sep 4 '18 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.