Bug 1394320

I would recommend to follow wiki
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_DNS_Updates

With the HOWTO (by the way the commands given there are invalid) I managed to reproduce the problem with plain nsupdate. No matter what I do, the DNS server doesn't accept the kerberos ticket, I always get the "; TSIG error with server: tsig verify failure" error.
I did set up a new AD domain for testing pruporses and unfortunately I can't reproduce the problem there (nsupdate works as expected).

I also did some tracing with wireshark to figure out how Windows 7 behaves.
It updates the A record with unauthenticated DNS update commands and the PTR record is set by the DHCP server, by request of the windows DHCP client. If I use the fqdn.fqdn option in dhclient, I can get the same behavior and everything seems to work.

I'm not exactly sure what the best solution would look like, maybe to configure dhclient to match the Windows behavior.
I can provide additional information but I'm not all that sure what would be helpful. A debug log from nsupdate doesn't seem to contain anything useful.

I think it would still be helpful to provide the (sanitized if needed) nsupdate message dump, at least as a reference for other users..

I managed to reproduce the problem in my test setup. It's actually very simple, but I got confused by a missing reverse lookup zone in our AD :/

Basically, it's enough to enable unsafe dynamic DNS update in the DNS server configuration.
In this case the GSS-TSIG authentication always fails. The DNS server still runs the query and the update succeeds, but nsupdate returns an error (return code 2).
I'm not sure, if nsupdate should return success in this case, or if sssd should ignore this return code. Windows clients always seem to try an unauthenticated update first and switch to an authenticated update if this fails.

I will attach an nsupdate log, if you need any further informations, please don't hesitate to ask.

Created attachment 1221136 [details]
nsupdate log with authentication

nsupdate command used:
server dc.testdomain.example.com
zone testdomain.example.com
update del fedora25.testdomain.example.com A
send

Interesting, I'm not sure what leads nsupdate to return 2 if the update in fact succeeds. Maybe Tomas (CC) knows?

I'm adding Petr Mensik (soon to be official BIND maintainer) to CC as I will not have time to look into this in near future and I would have to inspect the code to tell where may be the problem.

Do you know answer for  Comment 6?

Hi. Yes, this issue is obviously known to the authors of nsupdate. But I doubt they are willing to fix it. They report it as violation of RFC 2845 by MS DNS in a comment. It returns 2 on any error. Unfortunately also TSIG failure is reported as an error, even if server reported success and nsupdate understands it.

Simple fix is commented out in the source code since 2006. See https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/nsupdate/nsupdate.c;h=a631dd8db467c436e1fc3ebf83333442ad999ff9;hb=289ae548d52bc8f982d9823af64cafda7bd92232#l1750

It would be easy to return different error codes for different error. You might ignore specific error if you wanted. But it should be still reported as failure.

Can you make an update log also with nsupdate parameter -L 3?

Created attachment 1268714 [details]
the requested log

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.