Bug 11520 - Dns secure updates not working
Dns secure updates not working
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DNS server
4.3.0
x86 Linux
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
: 10718 11675 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-14 10:35 UTC by Kirill
Modified: 2016-06-24 07:07 UTC (History)
9 users (show)

See Also:


Attachments
Fix DNS-TKEY/TSIG (20.19 KB, patch)
2016-05-15 14:47 UTC, Ralph Böhme
no flags Details
Patch for 4.4 cherry-picked from master (43.62 KB, patch)
2016-06-18 14:40 UTC, Ralph Böhme
garming: review+
Details
Patch for 4.4 cherry-picked from master (48.17 KB, patch)
2016-06-22 08:41 UTC, Ralph Böhme
garming: review+
metze: review+
Details
Patch for 4.3 (1.47 KB, patch)
2016-06-22 08:55 UTC, Ralph Böhme
metze: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill 2015-09-14 10:35:43 UTC
Hi. Dns secure updates not working on samba 4.3.0.
if you go back to 4.2.4, DNS update works fine.
if set allow dns updates to nonsecure, DNS update works fine.

tcpdump:
13:25:42.404632 IP 192.168.1.230.56320 > core.ircclub.net.domain: 20669+ SOA? TESTPC.dc.core.lan. (36)
13:25:42.404788 IP core.ircclub.net.domain > 192.168.1.230.56320: 20669 NXDomain- 0/0/0 (36)
13:25:42.533247 IP 192.168.1.230.51597 > core.ircclub.net.domain: 36039+ SOA? dc.core.lan. (29)
13:25:42.533456 IP core.ircclub.net.domain > 192.168.1.230.51597: 36039* 1/0/0 SOA (81)
13:25:42.539825 IP 192.168.1.230.57056 > core.ircclub.net.domain: 46529+ A? core.dc.core.lan. (34)
13:25:42.539994 IP core.ircclub.net.domain > 192.168.1.230.57056: 46529* 1/0/0 A 192.168.1.1 (50)
13:25:42.544886 IP 192.168.1.230.58746 > core.ircclub.net.domain: 45414 update [1a] [3n] SOA? dc.core.lan. (99)
13:25:42.545001 IP core.ircclub.net.domain > 192.168.1.230.58746: 45414 update Refused- 1/3/0 (Class 254) CNAME TESTPC.dc.core.lan. (99)
13:25:42.579959 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [S], seq 3220419354, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
13:25:42.579976 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [S.], seq 3773246463, ack 3220419355, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:25:42.580864 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], ack 1, win 256, length 0
13:25:42.616443 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], seq 1:1461, ack 1, win 256, length 1460638 [1au] TKEY? 1044-ms-7.32-46ea7e.39f3f51b-5ac0-11e5-5fa5-000c2991ce12. (1458)
13:25:42.616464 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 1461, win 251, length 0
13:25:42.616561 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], seq 1461:2921, ack 1, win 256, length 146016794 zoneRef+% [b2&3=0x7b10] [19818a] [15921q] [26415n] [51682au][|domain]
13:25:42.616579 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 2921, win 274, length 0
13:25:42.617183 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [P.], seq 2921:2942, ack 1, win 256, length 2128751 updateD [b2&3=0x5228] [21559a] [1979q] [33571n] [55924au] Type55015 (Class 22528)? [|domain]
13:25:42.617200 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 2942, win 274, length 0
13:25:42.620154 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [P.], seq 1:344, ack 2942, win 274, length 343638 1/0/1 ANY TKEY (341)
13:25:42.659054 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [F.], seq 2942, ack 344, win 255, length 0
13:25:42.659096 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [F.], seq 344, ack 2943, win 274, length 0
13:25:42.695723 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], ack 345, win 255, length 0
13:25:45.696811 IP 192.168.1.230.56322 > core.ircclub.net.domain: 27420+ SOA? TESTPC.dc.core.lan. (36)
13:25:45.696983 IP core.ircclub.net.domain > 192.168.1.230.56322: 27420 NXDomain- 0/0/0 (36)
13:25:45.815491 IP 192.168.1.230.64699 > core.ircclub.net.domain: 28979+ SOA? dc.core.lan. (29)
13:25:45.815735 IP core.ircclub.net.domain > 192.168.1.230.64699: 28979* 1/0/0 SOA (81)
13:25:45.905602 IP 192.168.1.230.59570 > core.ircclub.net.domain: 43031+ A? core.dc.core.lan. (34)
13:25:45.905826 IP core.ircclub.net.domain > 192.168.1.230.59570: 43031* 1/0/0 A 192.168.1.1 (50)
13:25:45.921770 IP 192.168.1.230.49491 > core.ircclub.net.domain: 51542 update [1a] [3n] SOA? dc.core.lan. (99)
13:25:45.921906 IP core.ircclub.net.domain > 192.168.1.230.49491: 51542 update Refused- 1/3/0 (Class 254) CNAME TESTPC.dc.core.lan. (99)
13:25:45.986995 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [S], seq 3303964566, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
13:25:45.987008 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [S.], seq 608504169, ack 3303964567, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:25:45.987807 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], ack 1, win 256, length 0
13:25:46.059021 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], seq 1:1461, ack 1, win 256, length 146057057 [1au] TKEY? 1044-ms-7.33-46f7c7.39f3f51b-5ac0-11e5-5fa5-000c2991ce12. (1458)
13:25:46.059041 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 1461, win 251, length 0
13:25:46.059103 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], seq 1461:2921, ack 1, win 256, length 14602921 updateDA NotImp* [15879q],,,,[|domain]
13:25:46.059112 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 2921, win 274, length 0
13:25:46.059797 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [P.], seq 2921:2942, ack 1, win 256, length 2118341 op3 Refused-| [4981q][|domain]
13:25:46.059803 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 2942, win 274, length 0
13:25:46.062682 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [P.], seq 1:344, ack 2942, win 274, length 34357057 1/0/1 ANY TKEY (341)
13:25:46.099691 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [F.], seq 2942, ack 344, win 255, length 0
13:25:46.099745 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [F.], seq 344, ack 2943, win 274, length 0
13:25:46.106054 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], ack 345, win 255, length 0

log:
[2015/09/14 13:29:43.873322,  2] ../source4/dns_server/dns_update.c:792(dns_server_process_update)
  Got a dns update request.
[2015/09/14 13:29:43.873412,  2] ../source4/dns_server/dns_update.c:749(dns_update_allowed)
  Update not allowed for unsigned packet.
[2015/09/14 13:29:43.954648,  1] ../source4/dns_server/dns_query.c:526(handle_tkey)
  Tkey handshake completed
Comment 1 James Andrew 2015-11-10 14:06:42 UTC
I't appears all versions of Samba 4.2.X allow secure updates. It's 
transitioning to any version of Samba 4.3.X that prevents secure 
updates. Looking at the Wireshark captures of a successful update

https://www.cloudshark.org/captures/79e72c42de44

I see two transactions concerning the TKEY. I also see the update 
request from the client signed with the TSIG.

Looking at a failed update

https://www.cloudshark.org/captures/44f706b2cc61

I see three transactions concerning the TKEY. I also am missing the 
TSIG  with the update request from the client. I do see a TSIG with the 
TKEY exchange from the DC.

The TSIG as far as I know, should not be sent in the additional records 
section of the TKEY exchange. Secure update process fails during the 
TKEY exchange. This causes the client to repeat the whole DNS query 
exchange.

The client should send the dynamic update request immediately after the 
TKEY exchange has taken place. The lack of the TSIG with the client 
update explains why Samba reports 'Update not allowed for unsigned 
packet' on the second update request.
Comment 2 Björn Jacke 2016-03-29 17:16:23 UTC
confirmed. With Samba 4.3 you currently have to set allow dns updates = unsecure to allow dns updates - until the root cause is found and fixed.
Comment 3 Jefzo 2016-03-31 08:27:23 UTC
Hello,

I'm using Samba 4.3.x or 4.4.1 with Bind.
DNS Update Secure works very well :

Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone sodexi.lan
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55738: update 'sodexi.lan/IN' denied
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: cancelling transaction on zone sodexi.lan
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone sodexi.lan
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=clt-winxp-sp3.sodexi.lan tcpaddr= type=A key=1016-ms-7.1-1588b..../160/0
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=clt-winxp-sp3.sodexi.lan tcpaddr= type=A key=1016-ms-7.1-1588b..../160/0
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55094/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone 'sodexi.lan/NONE': deleting rrset at 'clt-winxp-sp3.sodexi.lan' A
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: subtracted rdataset clt-winxp-sp3.sodexi.lan 'clt-winxp-sp3.sodexi.lan.#0111200#011IN#011A#011172.16.199.3'
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55094/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone 'sodexi.lan/NONE': adding an RR at 'clt-winxp-sp3.sodexi.lan' A
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: added rdataset clt-winxp-sp3.sodexi.lan 'clt-winxp-sp3.sodexi.lan.#0111200#011IN#011A#011172.16.199.3'
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: committed transaction on zone sodexi.lan
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone 199.16.172.in-addr.arpa
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#51813: update '199.16.172.in-addr.arpa/IN' denied
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: cancelling transaction on zone 199.16.172.in-addr.arpa
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone 199.16.172.in-addr.arpa
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=3.199.16.172.in-addr.arpa tcpaddr= type=PTR key=1016-ms-7.1-1588b..../160/0
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=3.199.16.172.in-addr.arpa tcpaddr= type=PTR key=1016-ms-7.1-1588b..../160/0
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#56906/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone '199.16.172.in-addr.arpa/NONE': deleting rrset at '3.199.16.172.in-addr.arpa' PTR
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: subtracted rdataset 3.199.16.172.in-addr.arpa '3.199.16.172.in-addr.arpa.#0111200#011IN#011PTR#011clt-winxp-sp3.sodexi.lan.'
Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#56906/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone '199.16.172.in-addr.arpa/NONE': adding an RR at '3.199.16.172.in-addr.arpa' PTR
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: added rdataset 3.199.16.172.in-addr.arpa '3.199.16.172.in-addr.arpa.#0111200#011IN#011PTR#011clt-winxp-sp3.sodexi.lan.'
Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: committed transaction on zone 199.16.172.in-addr.arpa
Comment 4 Ralph Böhme 2016-05-14 10:37:33 UTC
Looking into this as well. There are several issues:

1. before 0062a2f5fb464b7c0991ccefd2f9d146fca54a0e we never attempted to add a TSIG to the TKEY reply (fwiw, nsupdate ignores TSIG on TKEY response, they have a comment and #ifdef 0 code that explains their reasoning).
2. now we add TSIK to TKEY response, but do the MAC calculation wrong (we add the request id which is wrong and TSIG field must not use DNS name compression)
3. fixing 1 and 2, we create correct TKEY response with TSIG record, but then fail to verify the MAC of the TSIG MAC in the client modify request

Currently looking what we're doing wrong in 3.
Comment 5 Ralph Böhme 2016-05-15 14:47:33 UTC
Created attachment 12103 [details]
Fix DNS-TKEY/TSIG

WIP patch for master, testing appreciated, especially with different Windows versions. Works with Windows 7 for me.
Comment 6 Stefan Metzmacher 2016-05-15 22:18:13 UTC
(In reply to Ralph Böhme from comment #5)

Thanks Ralph!

I also found the dns name compression difference, it seems that
that all names in a signed packet are not compressed (it you look
at captures from Windows servers)

I started with something like this:

https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=faaf92c84a0dfb8798c0a

So we would not use ndr_push_struct_blob(), but so same
on our own (or add a new helper function) and set ndr->flags |= LIBNDR_FLAG_STR_NO_COMPRESSION. If state->state.sign is true
(within dns_sign_tsig() and also in its caller while marshalling
the final response)
Comment 7 Ralph Böhme 2016-05-16 13:31:25 UTC
(In reply to Stefan Metzmacher from comment #6)
I started with a similar hack which was goood enough to verify that name compression is indeed one of the problems.
But this simple approach won't work for the name field of dns record responses, where we only want to prevent compression for tsig records, but probably keep it for other record types:
https://git.samba.org/?p=slow/samba.git;a=commitdiff;h=94a6aa692a46263ced28a53d5f4794ae971c5675#patch1
Comment 8 Garming Sam 2016-05-16 21:40:35 UTC
I can at least confirm that Ralph's earlier patch works for me on some of the 2012 boxes I have. And it's probable that it also fixes a number of scattered bug reports to do with DNS.
Comment 9 Ralph Böhme 2016-05-17 11:00:06 UTC
(In reply to Garming Sam from comment #8)
Thanks for confirming! I have a slightly simplified version
https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/dns-tkey
that doesn't add a new type dns_unique_string but instead uses a new ndr flag (as also suggested by metze). I didn't know that you could push flags for specific union members, very handy.
Comment 10 Ralph Böhme 2016-05-25 15:24:52 UTC
*** Bug 10718 has been marked as a duplicate of this bug. ***
Comment 11 Ralph Böhme 2016-06-18 14:40:05 UTC
Created attachment 12187 [details]
Patch for 4.4 cherry-picked from master
Comment 12 Ralph Böhme 2016-06-18 14:42:47 UTC
Patch doesn't apply to 4.3 as 4.3 is missing several commits. After carefully studying the merge conflicts I concluded I don't want to take the risk of breaking something else. So no backport for 4.3.
Comment 13 Stefan Metzmacher 2016-06-20 05:05:58 UTC
(In reply to Ralph Böhme from comment #12)

I think we should at least restore the 4.2 behavior in 4.3,
using a hack like this:

https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=fdf292b3f005a30c642fb37aa8a1f395201f018a
Comment 14 Garming Sam 2016-06-20 07:18:48 UTC
*** Bug 11675 has been marked as a duplicate of this bug. ***
Comment 15 Garming Sam 2016-06-20 07:31:37 UTC
Comment on attachment 12187 [details]
Patch for 4.4 cherry-picked from master

Looks as expected.

Should we include the patch that Jeremy put on top? 
c3dfeb3aa6c7df5127022abc090e446adc1b7d71

There's one other TSIG test that we wrote which matched one of our Windows bugs (I think we can take it or leave it).
c752e93fc5960d2d31d80fcf608eff0fbfa784a0

I agree with Ralph that 4.3 seems non-trivial.
Comment 16 Ralph Böhme 2016-06-22 08:41:03 UTC
Created attachment 12197 [details]
Patch for 4.4 cherry-picked from master

Updated patchset for 4.4 including Jerermy's talloc check and the Garming's additional test.
Comment 17 Ralph Böhme 2016-06-22 08:55:17 UTC
Created attachment 12198 [details]
Patch for 4.3
Comment 18 Karolin Seeger 2016-06-23 10:10:42 UTC
Pushed to autobuild-v4-[4|3]-test.
Comment 19 Karolin Seeger 2016-06-24 07:07:10 UTC
(In reply to Karolin Seeger from comment #18)
Pushed to both branches.
Closing out bug report.

Thanks!