BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-10-05T12:07:18Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3524Inline system sub test failure for queued 'rndc signing -nsec3param'2022-10-05T12:07:18ZMark AndrewsInline system sub test failure for queued 'rndc signing -nsec3param'Job [#2733417](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2733417) failed for e014ac3c5bd288f8ca3350c4dc9a8a1059532076:
```
8073I:inline:check 'rndc signing -nsec3param' requests are queued for zones which are not loaded (50)
8074...Job [#2733417](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2733417) failed for e014ac3c5bd288f8ca3350c4dc9a8a1059532076:
```
8073I:inline:check 'rndc signing -nsec3param' requests are queued for zones which are not loaded (50)
8074I:inline:failed
```
The wait loop terminated before all the NSEC/NSEC3 chain generation completed.
```
for i in 0 1 2 3 4 5 6 7 8 9
do
$RNDCCMD 10.53.0.3 signing -list retransfer3 > signing.out.test$n.$i 2>&1
keys_done=$(grep "Done signing" signing.out.test$n.$i | wc -l)
nsec3_pending=$(grep "NSEC3 chain" signing.out.test$n.$i | wc -l)
test $keys_done -eq 2 -a $nsec3_pending -eq 0 && break
sleep 1
done
```
```
% more signing.out.test50.0
Done signing with key 36392/ECDSAP256SHA256
Done signing with key 53929/ECDSAP256SHA256
%
```
Which doesn't show the pending NSEC/NSEC3 chain generation status.
```
02-Sep-2022 03:04:25.444 received control channel command 'retransfer retransfer'
02-Sep-2022 03:04:26.508 received control channel command 'signing -nsec3param 1 0 0 - retransfer3'
02-Sep-2022 03:04:26.520 received control channel command 'signing -nsec3param none retransfer3'
02-Sep-2022 03:04:26.536 received control channel command 'signing -nsec3param 1 0 0 - retransfer3'
02-Sep-2022 03:04:26.572 received control channel command 'retransfer retransfer3'
02-Sep-2022 03:04:26.588 received control channel command 'signing -list retransfer3'
```
```
02-Sep-2022 03:04:26.572 journal file retransfer3.bk.signed.jnl does not exist, creating it
02-Sep-2022 03:04:26.572 writing to journal
02-Sep-2022 03:04:26.572 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042407 20 20 1814400 3600
02-Sep-2022 03:04:26.572 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042408 20 20 1814400 3600
02-Sep-2022 03:04:26.572 add re-sign retransfer3. 300 IN RRSIG DNSKEY 13 1 300 20221002030425 20220902020426 36392 retransfer3. d9aOw4rzEIRNWeH9ueAlZUK0waIbarUE9cZG19g+KUCL8SPrJUyjKHs0 6KQxaVji6sRTJ796/mb1+SNQq1dWPQ==
02-Sep-2022 03:04:26.572 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20221002030426 20220902020426 53929 retransfer3. 5vagxcwPP2/qm7B2Wt71oGSUagPjURdpInBS90DEgENqkvzG5IBhGID7 ZskC3oGp/4ApXEjhAVynlxMBMqNXgQ==
02-Sep-2022 03:04:26.572 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. 6bS5Wygfm8bTKvBX5I8qcQ/RlK11ujOA5EDg5wbtNPAnxfwMgiJQSYRP mQwGJrzla+wljZ9TYLXFVd8DUCZmug==
02-Sep-2022 03:04:26.572 add retransfer3. 300 IN DNSKEY 256 3 13 o8vbIZePdT1a97BLJSJ8HZnLyWve8jTGQTC37QehPRYXoNuF/SFsjEeG zIBkolXnUCb6LbY0AFz62LhT/EwF1g==
02-Sep-2022 03:04:26.572 add retransfer3. 300 IN DNSKEY 257 3 13 yBj6wQS+NW6kp59q07jJBPfo9eK2FywCfeNtj9lhRitmZUiN4YBeO9ry 6HSpcduKYnABlOZNye3quoREwSZV5A==
02-Sep-2022 03:04:26.572 add retransfer3. 0 IN TYPE65534 \# 5 0DD2A90000
02-Sep-2022 03:04:26.572 add retransfer3. 0 IN TYPE65534 \# 5 0D8E280000
```
```
02-Sep-2022 03:04:26.576 writing to journal
02-Sep-2022 03:04:26.576 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042408 20 20 1814400 3600
02-Sep-2022 03:04:26.576 del re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20221002030426 20220902020426 53929 retransfer3. 5vagxcwPP2/qm7B2Wt71oGSUagPjURdpInBS90DEgENqkvzG5IBhGID7 ZskC3oGp/4ApXEjhAVynlxMBMqNXgQ==
02-Sep-2022 03:04:26.576 del re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. 6bS5Wygfm8bTKvBX5I8qcQ/RlK11ujOA5EDg5wbtNPAnxfwMgiJQSYRP mQwGJrzla+wljZ9TYLXFVd8DUCZmug==
02-Sep-2022 03:04:26.576 del retransfer3. 0 IN TYPE65534 \# 5 0DD2A90000
02-Sep-2022 03:04:26.576 del retransfer3. 0 IN TYPE65534 \# 5 0D8E280000
02-Sep-2022 03:04:26.576 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042409 20 20 1814400 3600
02-Sep-2022 03:04:26.576 add re-sign retransfer3. 300 IN RRSIG NS 13 1 300 20220914001838 20220902020426 53929 retransfer3. P0EuD2CmebyVdGY0M2k15dZwaAc9Yv+xKSwvNzJufkYP4yeMSO+LaQYR 4scr79duDeaOWfMG25BZAcAqwEE1yQ==
02-Sep-2022 03:04:26.576 add re-sign ns2.retransfer3. 300 IN RRSIG NSEC 13 2 300 20220914001838 20220902020426 53929 retransfer3. Niq93wK4ubpfZa27/VZScC25MRrK2ucz1wppwpBzX+Yz9Z2pyeH0GwwW f7/vWDZoqortT9BVBMe9VDA/DDiC4w==
02-Sep-2022 03:04:26.576 add re-sign ns2.retransfer3. 300 IN RRSIG A 13 2 300 20220914001838 20220902020426 53929 retransfer3. 4wQwWPlYjo46x0z75G1IwA4yv0nBp46SwFXOBRpe7YtCoWTzXXvrPdg/ 4WZSNuTcxMZ7F6JCZEQryeY5xx3j1A==
02-Sep-2022 03:04:26.576 add re-sign ns3.retransfer3. 300 IN RRSIG NSEC 13 2 300 20220914001838 20220902020426 53929 retransfer3. 6Ih6hY1u0Z5OAIakw/dx5lU7bpvQIsnwsji5AyPMXKqlzo9oZG6FHlIG xIsAdGznQXz+zUiN/eG8r4XlbpdPfA==
02-Sep-2022 03:04:26.576 add re-sign ns3.retransfer3. 300 IN RRSIG A 13 2 300 20220914001838 20220902020426 53929 retransfer3. NFADmB//07zB3AvWYngsG9tjE2dQutLXaqqkyEDejKl3lN3rwP59HKQC BaDU2vv+744IR7TFjYDlFhO3pcnXqw==
02-Sep-2022 03:04:26.576 add re-sign retransfer3. 300 IN RRSIG NSEC 13 1 300 20220914001838 20220902020426 53929 retransfer3. fwCzCCfdls0UjEoeaD1X3PndlwSQGrrBP+zk7ycq4e6TNj1vJUIXeJSF 3+iSKkgRUDX1UeNRFqmMEnECmY54Vw==
02-Sep-2022 03:04:26.576 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220914001838 20220902020426 53929 retransfer3. A/kGf/heioT7b2Xu9P448ea6w+CbivopIZqvd6fYb1EMq3936Zu1S76S nbtOECi2/NxJaaUpHKORLHdZRIlqpg==
02-Sep-2022 03:04:26.576 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. msvpXWtwx/B0nxQfohpcgeC79bcvibKHrfa9/2526VWuG5PTV71B6gLN CBQXNIJnLNEb8D3mSAtZGpYZWgj6NQ==
02-Sep-2022 03:04:26.576 add ns2.retransfer3. 300 IN NSEC ns3.retransfer3. A RRSIG NSEC
02-Sep-2022 03:04:26.576 add ns3.retransfer3. 300 IN NSEC retransfer3. A RRSIG NSEC
02-Sep-2022 03:04:26.576 add retransfer3. 300 IN NSEC ns2.retransfer3. NS SOA RRSIG NSEC DNSKEY TYPE65534
02-Sep-2022 03:04:26.576 add retransfer3. 0 IN TYPE65534 \# 5 0DD2A90001
02-Sep-2022 03:04:26.576 add retransfer3. 0 IN TYPE65534 \# 5 0D8E280001
```
NSEC chain generation completed
```
02-Sep-2022 03:04:26.584 writing to journal
02-Sep-2022 03:04:26.584 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042409 20 20 1814400 3600
02-Sep-2022 03:04:26.584 del retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. msvpXWtwx/B0nxQfohpcgeC79bcvibKHrfa9/2526VWuG5PTV71B6gLN CBQXNIJnLNEb8D3mSAtZGpYZWgj6NQ==
02-Sep-2022 03:04:26.584 del retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220914001838 20220902020426 53929 retransfer3. A/kGf/heioT7b2Xu9P448ea6w+CbivopIZqvd6fYb1EMq3936Zu1S76S nbtOECi2/NxJaaUpHKORLHdZRIlqpg==
02-Sep-2022 03:04:26.584 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042410 20 20 1814400 3600
02-Sep-2022 03:04:26.584 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. zfRl4hzPkDFvGwQ5jm9w5WQH5Jt/qiBhGuUbj+Fv+ms+06oN/AKmSc2I X/5qIJwjbPme0la5Jb3QDw9pdN723Q==
02-Sep-2022 03:04:26.584 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220911094241 20220902020426 53929 retransfer3. ON2VhDPOxiXifaSN70l6cTyvsBTndWBhft41S8x4uLAIvXQrd8HMpSoL kaRpu56Pdietri9lXG/owalW6MIbzA==
02-Sep-2022 03:04:26.584 add re-sign KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN RRSIG NSEC3 13 2 300 20220911094241 20220902020426 53929 retransfer3. IyEakMBsFvhuMMnfLoW6BKc2i0IHqOdIyahkc/vIK6GniMFBkEbQRaMV ABrSD2xF/mPdFxH111+S77997Z7YvA==
02-Sep-2022 03:04:26.584 add KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN NSEC3 1 0 0 - KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP NS SOA RRSIG DNSKEY TYPE65534
02-Sep-2022 03:04:26.584 add retransfer3. 0 IN TYPE65534 \# 6 000180000000
```
rndc 'signing -list retransfer3' happens here
```
02-Sep-2022 03:04:26.596 writing to journal
02-Sep-2022 03:04:26.596 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042410 20 20 1814400 3600
02-Sep-2022 03:04:26.596 del retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220911094241 20220902020426 53929 retransfer3. ON2VhDPOxiXifaSN70l6cTyvsBTndWBhft41S8x4uLAIvXQrd8HMpSoL kaRpu56Pdietri9lXG/owalW6MIbzA==
02-Sep-2022 03:04:26.596 del retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. zfRl4hzPkDFvGwQ5jm9w5WQH5Jt/qiBhGuUbj+Fv+ms+06oN/AKmSc2I X/5qIJwjbPme0la5Jb3QDw9pdN723Q==
02-Sep-2022 03:04:26.596 del retransfer3. 0 IN TYPE65534 \# 6 000180000000
02-Sep-2022 03:04:26.596 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042411 20 20 1814400 3600
02-Sep-2022 03:04:26.596 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220927075759 20220902020426 53929 retransfer3. upvjWoHZpi3ZMT2T9NNhOsg9MHY2++w+pdrejGbhR+X6USxD7Q3pQwrh mBFO4j8iqcPtRWmX7HLFU4ru+Ffsmw==
02-Sep-2022 03:04:26.596 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. bugb5zYF+GAvOutXHYzxZqa53LUYl8zYWlBeF7SkSZYqwteQRTQ/3yKw iB3yjh31sw5R4YPZ2oBjjDdCrsULPg==
02-Sep-2022 03:04:26.596 add retransfer3. 0 IN TYPE65534 \# 6 000140000000
```
```
02-Sep-2022 03:04:26.596 writing to journal
02-Sep-2022 03:04:26.596 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042411 20 20 1814400 3600
02-Sep-2022 03:04:26.596 del retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. bugb5zYF+GAvOutXHYzxZqa53LUYl8zYWlBeF7SkSZYqwteQRTQ/3yKw iB3yjh31sw5R4YPZ2oBjjDdCrsULPg==
02-Sep-2022 03:04:26.596 del retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220927075759 20220902020426 53929 retransfer3. upvjWoHZpi3ZMT2T9NNhOsg9MHY2++w+pdrejGbhR+X6USxD7Q3pQwrh mBFO4j8iqcPtRWmX7HLFU4ru+Ffsmw==
02-Sep-2022 03:04:26.596 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042412 20 20 1814400 3600
02-Sep-2022 03:04:26.596 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. IaAdgd7/4/jB7mh0p3xfNzPQyOWJWJpQv6f930v7gz2R1m7uUFrx0/0i hAZrtovd4RYanmy0bRhHKGi7yhOWzQ==
02-Sep-2022 03:04:26.596 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220910114144 20220902020426 53929 retransfer3. niDuwh9gQWMfUzrHWyBNmXftgBiVaHH/6mRhsVtjEemNJpRXlJXO8Wf8 7g6ZYX8H8XTeKCvq8bHevPaSO4vuIQ==
02-Sep-2022 03:04:26.596 add retransfer3. 0 IN TYPE65534 \# 6 000180000000
```
```
02-Sep-2022 03:04:26.600 writing to journal
02-Sep-2022 03:04:26.600 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042412 20 20 1814400 3600
02-Sep-2022 03:04:26.600 del re-sign KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN RRSIG NSEC3 13 2 300 20220911094241 20220902020426 53929 retransfer3. IyEakMBsFvhuMMnfLoW6BKc2i0IHqOdIyahkc/vIK6GniMFBkEbQRaMV ABrSD2xF/mPdFxH111+S77997Z7YvA==
02-Sep-2022 03:04:26.600 del re-sign retransfer3. 300 IN RRSIG NSEC 13 1 300 20220914001838 20220902020426 53929 retransfer3. fwCzCCfdls0UjEoeaD1X3PndlwSQGrrBP+zk7ycq4e6TNj1vJUIXeJSF 3+iSKkgRUDX1UeNRFqmMEnECmY54Vw==
02-Sep-2022 03:04:26.600 del re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. IaAdgd7/4/jB7mh0p3xfNzPQyOWJWJpQv6f930v7gz2R1m7uUFrx0/0i hAZrtovd4RYanmy0bRhHKGi7yhOWzQ==
02-Sep-2022 03:04:26.600 del retransfer3. 300 IN NSEC ns2.retransfer3. NS SOA RRSIG NSEC DNSKEY TYPE65534
02-Sep-2022 03:04:26.600 del KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN NSEC3 1 0 0 - KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP NS SOA RRSIG DNSKEY TYPE65534
02-Sep-2022 03:04:26.600 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042413 20 20 1814400 3600
02-Sep-2022 03:04:26.600 add re-sign KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN RRSIG NSEC3 13 2 300 20220926033815 20220902020426 53929 retransfer3. 6jsenN0lebMVnLgLMi0cGfqNteJbiFqPvfQEE1yTelfPuVB+esGdaLcq lDOyvkRgekX0B0cKX5CoufR2uwrBZA==
02-Sep-2022 03:04:26.600 add re-sign HP3LMHCOV1Q1QDV75VPE3QDQJAO95H3S.retransfer3. 300 IN RRSIG NSEC3 13 2 300 20220926033815 20220902020426 53929 retransfer3. s5g0s7w7Nbo5A4/CZ+sP1T+EQ/ti1th6hIYhXcVSafuJO3aM8q9MLCAz SrSHcdxfXkhL/0gHU2DDHwDn4tKNNQ==
02-Sep-2022 03:04:26.600 add re-sign VC4A16SBM4TU2URNQM9VJNH2A2QFIS2U.retransfer3. 300 IN RRSIG NSEC3 13 2 300 20220926033815 20220902020426 53929 retransfer3. f5ce33nRLixq5OhXfOX0mhSxPv5tFaM+mOTTMyW2cZm5oAV+td+lXLXg B1nH/ttYQ3RKlCQx99hLZj6jodnCKg==
02-Sep-2022 03:04:26.600 add re-sign retransfer3. 0 IN RRSIG NSEC3PARAM 13 1 0 20220926033815 20220902020426 53929 retransfer3. DdkeAWAfC4RZOnOJLNZG8s96ffiiT8D9VKDxUDXI7XBVo48lL5Qh3U+X gr14Uhd2yTAShy7dKpfglTk5X7oEJw==
02-Sep-2022 03:04:26.600 add re-sign retransfer3. 300 IN RRSIG NSEC 13 1 300 20220926033815 20220902020426 53929 retransfer3. xvsxZbroUm2UkSLy2MVk8FIkLVyfyhD58YF7xH+YbWApgijDgpzpLqJV v5nqcmbExOuAR+v/WxBKKkbpXFGEiQ==
02-Sep-2022 03:04:26.600 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. wdrKQKvL152cXNYyfwCD4fqWsdY9VzGUFlj5RCh4C/jGBszc7/6ZW2tb QbNG++UK9jaCMYA99ZRSog2Pfl3vuQ==
02-Sep-2022 03:04:26.600 add retransfer3. 300 IN NSEC ns2.retransfer3. NS SOA RRSIG NSEC DNSKEY NSEC3PARAM TYPE65534
02-Sep-2022 03:04:26.600 add KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP.retransfer3. 300 IN NSEC3 1 0 0 - VC4A16SBM4TU2URNQM9VJNH2A2QFIS2U NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534
02-Sep-2022 03:04:26.600 add HP3LMHCOV1Q1QDV75VPE3QDQJAO95H3S.retransfer3. 300 IN NSEC3 1 0 0 - KQBIM20MS0GAJ77QDN9NUQ83LQKKNTOP A RRSIG
02-Sep-2022 03:04:26.600 add VC4A16SBM4TU2URNQM9VJNH2A2QFIS2U.retransfer3. 300 IN NSEC3 1 0 0 - HP3LMHCOV1Q1QDV75VPE3QDQJAO95H3S A RRSIG
02-Sep-2022 03:04:26.600 add retransfer3. 0 IN NSEC3PARAM 1 0 0 -
```
NSEC3 chain generation complete
```
02-Sep-2022 03:04:26.620 writing to journal
02-Sep-2022 03:04:26.620 del retransfer3. 300 IN SOA ns2.retransfer3. . 2000042413 20 20 1814400 3600
02-Sep-2022 03:04:26.620 del re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220910114144 20220902020426 53929 retransfer3. niDuwh9gQWMfUzrHWyBNmXftgBiVaHH/6mRhsVtjEemNJpRXlJXO8Wf8 7g6ZYX8H8XTeKCvq8bHevPaSO4vuIQ==
02-Sep-2022 03:04:26.620 del re-sign retransfer3. 300 IN RRSIG NSEC 13 1 300 20220926033815 20220902020426 53929 retransfer3. xvsxZbroUm2UkSLy2MVk8FIkLVyfyhD58YF7xH+YbWApgijDgpzpLqJV v5nqcmbExOuAR+v/WxBKKkbpXFGEiQ==
02-Sep-2022 03:04:26.620 del re-sign ns2.retransfer3. 300 IN RRSIG NSEC 13 2 300 20220914001838 20220902020426 53929 retransfer3. Niq93wK4ubpfZa27/VZScC25MRrK2ucz1wppwpBzX+Yz9Z2pyeH0GwwW f7/vWDZoqortT9BVBMe9VDA/DDiC4w==
02-Sep-2022 03:04:26.620 del re-sign ns3.retransfer3. 300 IN RRSIG NSEC 13 2 300 20220914001838 20220902020426 53929 retransfer3. 6Ih6hY1u0Z5OAIakw/dx5lU7bpvQIsnwsji5AyPMXKqlzo9oZG6FHlIG xIsAdGznQXz+zUiN/eG8r4XlbpdPfA==
02-Sep-2022 03:04:26.620 del re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. wdrKQKvL152cXNYyfwCD4fqWsdY9VzGUFlj5RCh4C/jGBszc7/6ZW2tb QbNG++UK9jaCMYA99ZRSog2Pfl3vuQ==
02-Sep-2022 03:04:26.620 del retransfer3. 300 IN NSEC ns2.retransfer3. NS SOA RRSIG NSEC DNSKEY NSEC3PARAM TYPE65534
02-Sep-2022 03:04:26.620 del ns2.retransfer3. 300 IN NSEC ns3.retransfer3. A RRSIG NSEC
02-Sep-2022 03:04:26.620 del ns3.retransfer3. 300 IN NSEC retransfer3. A RRSIG NSEC
02-Sep-2022 03:04:26.620 del retransfer3. 0 IN TYPE65534 \# 6 000140000000
02-Sep-2022 03:04:26.620 del retransfer3. 0 IN TYPE65534 \# 6 000180000000
02-Sep-2022 03:04:26.620 add retransfer3. 300 IN SOA ns2.retransfer3. . 2000042414 20 20 1814400 3600
02-Sep-2022 03:04:26.620 add re-sign retransfer3. 0 IN RRSIG TYPE65534 13 1 0 20220924180437 20220902020426 53929 retransfer3. mhdVdBg/rEWOI/oUW4PdoWBcGZy1d+uz0sv8Vw1IqHpAqEkFR+zjrqVQ OSQ5MoylQIoBrlZDo+WYZADn/U/VcA==
02-Sep-2022 03:04:26.620 add re-sign retransfer3. 300 IN RRSIG SOA 13 1 300 20221002030426 20220902020426 53929 retransfer3. XkraRQU3YLbONGn2c0/NAjsW9/s/T28kADw9giY1Pq1A4eoy/VIPpUts GPYfzhZhYqro3pOn/ddMdr+2HhHAqQ==
```
and then the retransfer request for the next sub test.
```
02-Sep-2022 03:04:26.620 received control channel command 'signing -nsec3param 1 0 0 - retransfer3'
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3522Double detach of client->reqhandle lib/ns/update.c2022-09-20T13:59:02ZCathy AlmondDouble detach of client->reqhandle lib/ns/update.cReported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
In respond(), there's a double detach of client->reqhandle which was
already detached at the end of ns_updat...Reported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
In respond(), there's a double detach of client->reqhandle which was
already detached at the end of ns_update_start(). Though this is
unlikely to execute to crash in ISC BIND, the modified appliance
uses use refactored code that crashes.
The following is the ISC BIND part of patch hunks to fix it:
```patch
diff --git a/bind9.16/lib/ns/update.c b/bind9.16/lib/ns/update.c
index 640f001e734..6ed23073349 100644
--- a/bind9.16/lib/ns/update.c
+++ b/bind9.16/lib/ns/update.c
@@ -2062,7 +2062,14 @@ msg_failure:
"could not create update response message: %s",
isc_result_totext(msg_result));
ns_client_drop(client, msg_result);
+#ifdef ORIGINAL_ISC_CODE
isc_nmhandle_detach(&client->reqhandle);
+#else
+ /*
+ * The statement in the original ISC code is a double detach
+ * that can cause an assertion failure.
+ */
+#endif
}
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3520Use after detach of task object in rndc2022-09-22T08:41:08ZCathy AlmondUse after detach of task object in rndcReported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
> rndc could use a task object after detach when it is being
> shutdown. Though the crash doesn't cause any ...Reported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
> rndc could use a task object after detach when it is being
> shutdown. Though the crash doesn't cause any issues, it leaves cores on
> our appliances due to the abort (which support and QA teams don't like)
>
> The following patch is used to fix it:
```patch
diff --git a/bind9.16/bin/rndc/rndc.c b/bind9.16/bin/rndc/rndc.c
index 13bb3f4c72a..a56cfede60e 100644
--- a/bind9.16/bin/rndc/rndc.c
+++ b/bind9.16/bin/rndc/rndc.c
@@ -301,6 +301,14 @@ rndc_senddone(isc_task_t *task, isc_event_t *event) {
{
isc_socket_detach(&sock);
isc_task_shutdown(task);
+#ifdef ORIGINAL_ISC_CODE
+#else
+ /*
+ * Detach from the task here. See the corresponding
+ * comment in main().
+ */
+ isc_task_detach(&task);
+#endif
isc_app_shutdown();
}
}
@@ -377,6 +385,14 @@ rndc_recvdone(isc_task_t *task, isc_event_t *event) {
atomic_load_acquire(&recvs) == 0) {
isc_socket_detach(&sock);
isc_task_shutdown(task);
+#ifdef ORIGINAL_ISC_CODE
+#else
+ /*
+ * Detach from the task here. See the corresponding
+ * comment in main().
+ */
+ isc_task_detach(&task);
+#endif
isc_app_shutdown();
}
}
@@ -1069,7 +1085,18 @@ main(int argc, char **argv) {
isc_socket_cancel(sock, task, ISC_SOCKCANCEL_ALL);
}
+#ifdef ORIGINAL_ISC_CODE
isc_task_detach(&task);
+#else
+ /*
+ * Don't detach from the task here as it creates a race with
+ * rndc_start() if the app context exits due to a signal before
+ * rndc_start() is run. This causes a crash when the task object
+ * is used within rndc_start() thread. Instead, rndc_senddone()
+ * or rndc_recvdone() will detach from the task right before it
+ * shuts down the app.
+ */
+#endif
isc_managers_destroy(&netmgr, &taskmgr);
isc_socketmgr_destroy(&socketmgr);
isc_log_destroy(&log);
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3519System test fixes for macOS2022-09-14T10:50:55ZTony FinchSystem test fixes for macOSA few recent changes to the system tests revealed some troubles on macOS:
* The extra loopback interfaces were not verified by `testsock.pl` nor added to `org.isc.bind.system`.
* macOS has an old version of Net::DNS that causes the ...A few recent changes to the system tests revealed some troubles on macOS:
* The extra loopback interfaces were not verified by `testsock.pl` nor added to `org.isc.bind.system`.
* macOS has an old version of Net::DNS that causes the xfer test to fail.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3427tests/system/tcp/tests-tcp.py timeout consistently2022-09-20T13:56:02ZStacey Marshalltests/system/tcp/tests-tcp.py timeout consistently<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
**tests-tcp.py** consistently failing on Solaris 11.4 as call to `socket.create_connection(..., timeout=1)` times out.
### BIND version used
9.18.4
### Steps to reproduce
`cd tests/system; ./run.sh tcp`
### What is the current *bug* behavior?
Test consistently fails, occasional one passes.
### What is the expected *correct* behavior?
Test passes consistently, it just needs a little more time.
### Relevant configuration files
Not applicable.
### Relevant logs and/or screenshots
```
I:tcp:starting servers
D:tcp:============================= test session starts ==============================
D:tcp:platform sunos5 -- Python 3.7.12, pytest-7.0.0, pluggy-1.0.0 -- /usr/bin/python3.7
D:tcp:cachedir: .pytest_cache
D:tcp:hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/builds/bind-9.18/components/bind/build/sparcv9/bin/tests/system/tcp/.hypothesis/examples')
D:tcp:rootdir: /builds/bind-9.18/components/bind/build/sparcv9/bin/tests/system/tcp
D:tcp:plugins: hypothesis-4.57.1
D:tcp:collecting ... collected 3 items
D:tcp:
D:tcp:tests-tcp.py::test_tcp_garbage FAILED [ 33%]
D:tcp:tests-tcp.py::test_tcp_garbage_response FAILED [ 66%]
D:tcp:tests-tcp.py::test_close_wait FAILED [100%]
D:tcp:
D:tcp:=================================== FAILURES ===================================
D:tcp:_______________________________ test_tcp_garbage _______________________________
D:tcp:
D:tcp:named_port = 5300
D:tcp:
D:tcp: def test_tcp_garbage(named_port):
D:tcp: with create_socket("10.53.0.7", named_port) as sock:
D:tcp:
D:tcp: msg = create_msg("a.example.", "A")
D:tcp: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:tcp:> (response, rtime) = dns.query.receive_tcp(sock, timeout())
D:tcp:
D:tcp:tests-tcp.py:50:
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:717: in receive_tcp
D:tcp: ldata = _net_read(sock, 2, expiration)
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:
D:tcp:sock = <socket.socket [closed] fd=-1, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6>
D:tcp:count = 2, expiration = 1655993050.969228
D:tcp:
D:tcp: def _net_read(sock, count, expiration):
D:tcp: """Read the specified number of bytes from sock. Keep trying until we
D:tcp: either get the desired amount, or we hit EOF.
D:tcp: A Timeout exception will be raised if the operation is not completed
D:tcp: by the expiration time.
D:tcp: """
D:tcp: s = b''
D:tcp: while count > 0:
D:tcp: try:
D:tcp:> n = sock.recv(count)
D:tcp:E socket.timeout: timed out
D:tcp:
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:637: timeout
D:tcp:__________________________ test_tcp_garbage_response ___________________________
D:tcp:
D:tcp:named_port = 5300
D:tcp:
D:tcp: def test_tcp_garbage_response(named_port):
D:tcp: with create_socket("10.53.0.7", named_port) as sock:
D:tcp:
D:tcp: msg = create_msg("a.example.", "A")
D:tcp: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:tcp:> (response, rtime) = dns.query.receive_tcp(sock, timeout())
D:tcp:
D:tcp:tests-tcp.py:73:
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:717: in receive_tcp
D:tcp: ldata = _net_read(sock, 2, expiration)
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:
D:tcp:sock = <socket.socket [closed] fd=-1, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6>
D:tcp:count = 2, expiration = 1655993052.2569585
D:tcp:
D:tcp: def _net_read(sock, count, expiration):
D:tcp: """Read the specified number of bytes from sock. Keep trying until we
D:tcp: either get the desired amount, or we hit EOF.
D:tcp: A Timeout exception will be raised if the operation is not completed
D:tcp: by the expiration time.
D:tcp: """
D:tcp: s = b''
D:tcp: while count > 0:
D:tcp: try:
D:tcp:> n = sock.recv(count)
D:tcp:E socket.timeout: timed out
D:tcp:
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:637: timeout
D:tcp:_______________________________ test_close_wait ________________________________
D:tcp:
D:tcp:named_port = 5300
D:tcp:
D:tcp: def test_close_wait(named_port):
D:tcp: with create_socket("10.53.0.7", named_port) as sock:
D:tcp:
D:tcp: msg = create_msg("a.example.", "A")
D:tcp: (sbytes, stime) = dns.query.send_tcp(sock, msg, timeout())
D:tcp:> (response, rtime) = dns.query.receive_tcp(sock, timeout())
D:tcp:
D:tcp:tests-tcp.py:97:
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:717: in receive_tcp
D:tcp: ldata = _net_read(sock, 2, expiration)
D:tcp:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:tcp:
D:tcp:sock = <socket.socket [closed] fd=-1, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6>
D:tcp:count = 2, expiration = 1655993053.3719778
D:tcp:
D:tcp: def _net_read(sock, count, expiration):
D:tcp: """Read the specified number of bytes from sock. Keep trying until we
D:tcp: either get the desired amount, or we hit EOF.
D:tcp: A Timeout exception will be raised if the operation is not completed
D:tcp: by the expiration time.
D:tcp: """
D:tcp: s = b''
D:tcp: while count > 0:
D:tcp: try:
D:tcp:> n = sock.recv(count)
D:tcp:E socket.timeout: timed out
D:tcp:
D:tcp:/home/smarshal/.local/lib/python3.7/site-packages/dns/query.py:637: timeout
D:tcp:=========================== short test summary info ============================
D:tcp:FAILED tests-tcp.py::test_tcp_garbage - socket.timeout: timed out
D:tcp:FAILED tests-tcp.py::test_tcp_garbage_response - socket.timeout: timed out
D:tcp:FAILED tests-tcp.py::test_close_wait - socket.timeout: timed out
D:tcp:============================== 3 failed in 3.98s ===============================
I:tcp:FAILED
I:tcp:stopping servers
R:tcp:FAIL
E:tcp:2022-06-23T07:04:06-0700
FAIL: tcp
```
### Possible fixes
Increase timeout in call to [socket.create_connection](https://docs.python.org/3/library/socket.html#socket.create_connection) in [tests-tcp.py](
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/tests/system/tcp/tests-tcp.py#L40)
In my testing I modified it from `timeout=1` to `timeout=10`.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3399Remove unused random-device statement from named.conf2022-09-20T13:48:07ZPetr Špačekpspacek@isc.orgRemove unused random-device statement from named.confAs far as I can tell, `random-device` statement in named.conf grammar does not do anything since !269 (9.13.0). At the same time it is not marked as deprecated or obsolete in the config.
Proposal:
- Mark it as obsolete but still accepte...As far as I can tell, `random-device` statement in named.conf grammar does not do anything since !269 (9.13.0). At the same time it is not marked as deprecated or obsolete in the config.
Proposal:
- Mark it as obsolete but still accepted by the parser in ~"v9.16" and ~"v9.18"
- Remove in ~"v9.19"October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3566UAF in req_senddone on shutdown2022-09-27T12:48:58ZOndřej SurýUAF in req_senddone on shutdownFrom https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793682
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted...From https://gitlab.isc.org/isc-projects/bind9/-/jobs/2793682
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:Sent by thr_kill() from pid 27679 and user 1001.
D:inline:#0 0x000000080151369a in thr_kill () from /lib/libc.so.7
D:inline:[Current thread is 1 (LWP 100288)]
D:inline:#0 0x000000080151369a in thr_kill () from /lib/libc.so.7
D:inline:#1 0x0000000801511af4 in raise () from /lib/libc.so.7
D:inline:#2 0x0000000801487719 in abort () from /lib/libc.so.7
D:inline:#3 0x000000000024013d in library_fatal_error (file=0x8008aeb37 "request.c", line=979, format=0x8008a1b5c "%s(): %s() failed with error %d (%s)", args=0x7fffdfffdb30) at main.c:278
D:inline:#4 0x00000008003194a5 in isc_error_fatal (file=0x187c0 <error: Cannot access memory at address 0x187c0>, line=6, format=0x0) at error.c:68
D:inline:#5 0x00000008009c7cf0 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:993
D:inline:#6 0x0000000800913a75 in send_done (handle=0x801949780, result=ISC_R_SHUTTINGDOWN, cbarg=0x0) at dispatch.c:1920
D:inline:#7 0x0000000800314d88 in isc__nm_udp_send (handle=0x187c0, region=0x7fffdfffdce8, cb=0x800913a40 <send_done>, cbarg=0x0) at netmgr/udp.c:715
D:inline:#8 0x0000000800307a5c in isc_nm_send (handle=0x187c0, region=0x6, cb=0x0, cbarg=0x8015136ba <thr_self+10>) at netmgr/netmgr.c:1984
D:inline:#9 0x0000000800913a10 in dns_dispatch_send (resp=0x805230a00, r=0x7fffdfffdce8, dscp=<optimized out>) at dispatch.c:1971
D:inline:#10 0x00000008009c806c in req_send (request=0x80530db40) at request.c:295
D:inline:#11 0x00000008009c7a96 in req_connected (eresult=ISC_R_SUCCESS, region=<optimized out>, arg=0x80530db40) at request.c:957
D:inline:#12 0x000000080091391e in udp_connected (handle=0x801949780, eresult=ISC_R_SUCCESS, arg=0x805230a00) at dispatch.c:1804
D:inline:#13 0x0000000800307d75 in isc__nm_async_connectcb (worker=<optimized out>, ev0=<optimized out>) at netmgr/netmgr.c:2143
D:inline:#14 0x0000000800305300 in process_netievent (arg=0x80533ad80) at netmgr/netmgr.c:488
D:inline:#15 0x00000008003207a7 in isc__job_cb (idle=0x802f6d548) at job.c:75
D:inline:#16 0x000000080111d5cd in ?? () from /usr/local/lib/libuv.so.1
D:inline:#17 0x0000000801117026 in uv_run () from /usr/local/lib/libuv.so.1
D:inline:#18 0x000000080032792e in loop_run (loop=0x801940530) at loop.c:266
D:inline:#19 0x0000000800326b1c in loop_thread (arg=0x801940530) at loop.c:293
D:inline:#20 0x000000080033d446 in isc__trampoline_run (arg=0x8019f5330) at trampoline.c:198
D:inline:#21 0x000000080133d08c in ?? () from /lib/libthr.so.3
D:inline:#22 0x0000000000000000 in ?? ()
D:inline:Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
```
@each, can you take a look at this?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3559Provide custom isc_mem based allocators for external libraries2022-09-29T09:47:35ZOndřej SurýProvide custom isc_mem based allocators for external librariesSome of the external libraries that we use in BIND 9 provide a way how to override their internal allocators. Create separate memory context for each of the libraries.Some of the external libraries that we use in BIND 9 provide a way how to override their internal allocators. Create separate memory context for each of the libraries.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3549resource.c:120:27: runtime error: left shift of 1 by 63 places cannot be repr...2022-10-05T10:51:43ZMichal Nowakresource.c:120:27: runtime error: left shift of 1 by 63 places cannot be represented in type 'rlim_t' (aka 'long')UBSAN error on FreeBSD 13.1 in "tcp" system test:
```
resource.c:120:27: runtime error: left shift of 1 by 63 places cannot be represented in type 'rlim_t' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior resource.c:1...UBSAN error on FreeBSD 13.1 in "tcp" system test:
```
resource.c:120:27: runtime error: left shift of 1 by 63 places cannot be represented in type 'rlim_t' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior resource.c:120:27 in
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3539work around libuv's broken behaviour when stdin is closed2023-10-02T16:01:35ZMark Andrewswork around libuv's broken behaviour when stdin is closedAs reported on bind-users
```
sh-3.2$ /usr/local/bin/nslookup example.net 0<&-
Server: ::1
Address: ::1#53
Non-authoritative answer:
Name: example.net
Address: 93.184.216.34
Name: example.net
Address: 2606:2800:220:1:248:1893:25c8:194...As reported on bind-users
```
sh-3.2$ /usr/local/bin/nslookup example.net 0<&-
Server: ::1
Address: ::1#53
Non-authoritative answer:
Name: example.net
Address: 93.184.216.34
Name: example.net
Address: 2606:2800:220:1:248:1893:25c8:1946
Assertion failed: (fd > STDERR_FILENO), function uv__close, file src/unix/core.c, line 615.
Abort trap: 6
sh-3.2$
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3529Implement TLS transport support for dns_request2022-12-14T15:34:11ZArаm SаrgsyаnImplement TLS transport support for dns_requestImplementing TLS transport support for dns_request will become a building block for several new features in the future, including DDNS update forwarding using DoT, DoT support for `nsupdate`, query forwarding through DoT, etc.Implementing TLS transport support for dns_request will become a building block for several new features in the future, including DDNS update forwarding using DoT, DoT support for `nsupdate`, query forwarding through DoT, etc.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3528Reduce delays in `catz` system test2022-09-29T11:30:27ZTony FinchReduce delays in `catz` system testThe `catz` system test does a lot of zone transfers. By default `named` has limits on the rate of NOTIFY messages and catalog zone updates. The test can run a lot faster if these limits are adjusted.The `catz` system test does a lot of zone transfers. By default `named` has limits on the rate of NOTIFY messages and catalog zone updates. The test can run a lot faster if these limits are adjusted.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3527More lenient IDNA processing in dig2022-09-20T13:24:38ZTony FinchMore lenient IDNA processing in digIt's annoying when dig gives up with an error if there is a problem with IDNA conversion. Rather than having to re-run it with +noidnout etc. it would be nice if dig would automatically fall back to printing the unconverted name. (And si...It's annoying when dig gives up with an error if there is a problem with IDNA conversion. Rather than having to re-run it with +noidnout etc. it would be nice if dig would automatically fall back to printing the unconverted name. (And similarly for IDNA input names.)
Users who need to script IDNA error / syntax checks can use the `idn2` tool, which provides much more specific options than dig can. (This is a minor incompatibility with the old behaviour.)October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3512XoT breaks DDNS update forwarding2022-09-28T10:28:06ZBen WeeksXoT breaks DDNS update forwarding
### Summary
When XoT is used in BIND 9.18, allow-update-forwarding { any; } does not forward TSIG signed updates to primary
### BIND version used
```
BIND 9.18.5 (Stable Release) <id:>
running on FreeBSD amd64 12.3-RELEASE-p6 FreeBSD ...
### Summary
When XoT is used in BIND 9.18, allow-update-forwarding { any; } does not forward TSIG signed updates to primary
### BIND version used
```
BIND 9.18.5 (Stable Release) <id:>
running on FreeBSD amd64 12.3-RELEASE-p6 FreeBSD 12.3-RELEASE-p6 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--enable-dnsrps' '--with-readline=libedit' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen' '--prefix=/usr/local' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.3' 'build_alias=amd64-portbld-freebsd12.3' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'PKG_CONFIG_LIBDIR=/wrkdirs/usr/ports/dns/bind918/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig' 'PYTHON=/usr/local/bin/python3.9' 'READLINE_CFLAGS=-L/usr/local/lib'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1l-freebsd 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l-freebsd 24 Aug 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.48.0
linked to libnghttp2 version: 1.48.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
```
### Steps to reproduce
configure dynamic zone where a client (eg. nsupdate) sends a TSIG signed update to a secondary. The secondary is expected to forward to the primary to validate the TSIG signature
TSIG nsupdate client ---> secondary ---> primary
Install a TSIG key for DDNS updates on the client and primary.
Note the configuration works when Xot is disabled. Enable XoT and note the bug.
### What is the current *bug* behavior?
BIND on the secondary does not forward the DDNS update and logs:
client @0xXXXXXXXXX xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx#56633: request has invalid signature: TSIG ddns-key.dynzone.example.com: tsig verify failure (BADKEY)
### What is the expected *correct* behavior?
I expect the same behavior when Xot is disabled. That is to forward the TSIG signed update to the primary.
### Relevant configuration files
```
primaries example.com {
2001:db8::1 key ns1-ns2.example.com. tls ephemeral;
};
zone "dynzone.example.com" {
type secondary;
primaries { example.com; };
allow-update-forwarding { any; };
file "/var/dns/secondary/dynzone.example.com";
};
```
### Relevant logs and/or screenshots
Secondary logs:
```
client @0xXXXXXXXXX xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx#56633: request has invalid signature: TSIG ddns-key.dynzone.example.com: tsig verify failure (BADKEY)
```October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3202Convert the isc_timer API to use isc_nm loops2022-09-29T10:55:30ZOndřej SurýConvert the isc_timer API to use isc_nm loopsOctober 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2295Add the ability to specify that a server supports COOKIES.2022-09-20T13:44:03ZMark AndrewsAdd the ability to specify that a server supports COOKIES.We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a va...We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a valid TSIG or client cookie when `require-cookie` is true.
`server <prefix> { require-cookie <bool>; };`October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1967named may generate broken glueless referrals when reaching UDP packet size limit2022-09-22T12:24:31ZMichał Kępieńnamed may generate broken glueless referrals when reaching UDP packet size limit`named` unconditionally [ignores][1] the `ISC_R_NOSPACE` result code
when rendering the ADDITIONAL section of a response message. This is
usually fine, but there is an edge case which breaks with this
behavior: for delegations which onl...`named` unconditionally [ignores][1] the `ISC_R_NOSPACE` result code
when rendering the ADDITIONAL section of a response message. This is
usually fine, but there is an edge case which breaks with this
behavior: for delegations which only have in-bailiwick name servers
defined for the child zone, a referral must include glue records;
meanwhile, `named` may not include any glue records in a referral if its
size is close to the UDP packet size limit.
While I have not proved this in practice, I believe BIND has been
behaving this way since version 9.0.0. The issue affects all referrals,
both signed and unsigned, including those served by root servers: I came
across this problem by analyzing traffic patterns on my home resolver.
I believe that in extreme cases, this issue may cause resolution
failures for the delegated domain.
Given enough retries (due to load balancing), it should be possible to
reproduce this problem with:
```
$ dig @k.root-servers.net. _.dk. A +norec +dnssec +bufsize=512 +ignore +nsid
; <<>> DiG 9.17.2 <<>> @k.root-servers.net. _.dk. A +norec +dnssec +bufsize=512 +ignore +nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10102
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID: 6e 73 31 2e 64 65 2d 66 72 61 2e 6b 2e 72 69 70 65 2e 6e 65 74 ("ns1.de-fra.k.ripe.net")
;; QUESTION SECTION:
;_.dk. IN A
;; AUTHORITY SECTION:
dk. 172800 IN NS b.nic.dk.
dk. 172800 IN NS l.nic.dk.
dk. 172800 IN NS p.nic.dk.
dk. 172800 IN NS s.nic.dk.
dk. 172800 IN NS a.nic.dk.
dk. 172800 IN NS d.nic.dk.
dk. 172800 IN NS c.nic.dk.
dk. 86400 IN DS 9280 13 2 3A93091A1A8A850E72A86DDAD3C79B2E3D426CC275BC11980E85C0AC 2854612B
dk. 86400 IN RRSIG DS 8 1 86400 20200706050000 20200623040000 48903 . AKrl/m0EtfPo4IbY0oJLNkCh/H0ZzFeEEl7SrgQOoKQ7uxj1rYsb5vy7 w7J+kRjq0Ll4LTt92DtkJS6OqcXZguv0sQFnEOw5tkmTvjNXJZSsjk6u c/jPrfDlVaT9glKeGGjcFpSnDfSkUv7gsR5S91Ovk6RX1ZfKKzlydebC /ci+qAcaxnJtFDiSa7RR7jReoGkeR8FFo0onjsO/RRcUKxvBjO7aRWNh k/1dD8VSGBro/8LEaPuTYMxRnbTSvBxqO+IY1JhcbCoZYRMRCvFqPm1j 3zh025e+vDjQsA86YeahM/lr2mSgNXkNO87BEYPPVo73eA+9ANoPEcle vnhEtA==
;; Query time: 23 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Tue Jun 23 11:19:28 CEST 2020
;; MSG SIZE rcvd: 511
```
This issue is similar in spirit to the [F-Root incident][2] which
happened earlier this year.
If my findings are correct, I think the fix for this bug needs a release
note.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e8fa9986bd3bc6fdb7d40b60ecebfdcafbabea4c/lib/ns/client.c#L541-543
[2]: https://www.isc.org/docs/f-root/incident-2020-01.pdfOctober 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1176Add support for sd_notify interface to better integrate on Linux2022-09-29T10:55:38ZOndřej SurýAdd support for sd_notify interface to better integrate on LinuxThe [sd_notify()](https://www.freedesktop.org/software/systemd/man/sd_notify.html) interface allows the daemon to report its internal state back to the supervisor (systemd) in this case. It's similar to SMF interface we use on Solaris.
...The [sd_notify()](https://www.freedesktop.org/software/systemd/man/sd_notify.html) interface allows the daemon to report its internal state back to the supervisor (systemd) in this case. It's similar to SMF interface we use on Solaris.
The work here should probably abstract the two interfaces (systemd and SMF) into a common API.October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3582CID 358309: Integer handling issues in tests/bench/siphash.c2022-10-05T14:07:47ZMichal NowakCID 358309: Integer handling issues in tests/bench/siphash.cisc-projects/bind9!6789 added the `siphash` benchmark. Coverity Scan reports a possible undefined behavior issue in it:
```
/tests/bench/siphash.c: 54 in main()
48 count++;
49 }
50
51 isc_time_now_hires(&finish);
...isc-projects/bind9!6789 added the `siphash` benchmark. Coverity Scan reports a possible undefined behavior issue in it:
```
/tests/bench/siphash.c: 54 in main()
48 count++;
49 }
50
51 isc_time_now_hires(&finish);
52
53 us = isc_time_microdiff(&finish, &start);
>>> CID 358309: Integer handling issues (DIVIDE_BY_ZERO)
>>> In expression "count * 1000UL / us", division by expression "us" which may be zero has undefined behavior.
54 printf("%f us wide-lower len %3zu, %7llu kh/s (%llx)\n",
55 (double)us / 1000000.0, len,
56 (unsigned long long)(count * 1000 / us),
57 (unsigned long long)sum);
58 }
59
```
@ondrej @fanf Can you please have a look?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3580CID 358310: Possible Control flow issues in lib/isc/resource.c2022-10-05T15:51:21ZMichal NowakCID 358310: Possible Control flow issues in lib/isc/resource.cAfter isc-projects/bind9!6788 (a fix for isc-projects/bind9#3549) Coverity Scan reports the following on `main`:
```
*** CID 358310: Possible Control flow issues (DEADCODE)
/lib/isc/resource.c: 118 in isc_resource_setlimit()
112 ...After isc-projects/bind9!6788 (a fix for isc-projects/bind9#3549) Coverity Scan reports the following on `main`:
```
*** CID 358310: Possible Control flow issues (DEADCODE)
/lib/isc/resource.c: 118 in isc_resource_setlimit()
112 * rlim_t, and whether rlim_t has a sign bit.
113 */
114 isc_resourcevalue_t rlim_max = UINT64_MAX;
115 size_t wider = sizeof(rlim_max) - sizeof(rlim_t);
116 bool sign_bit = (double)(rlim_t)-1 < 0;
117
>>> CID 358310: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "1" inside this statement: "rlim_max >>= 8UL * wider + ...".
118 rlim_max >>= CHAR_BIT * wider + (sign_bit ? 1 : 0);
119 rlim_value = ISC_MIN(value, rlim_max);
120 }
121
122 rl.rlim_cur = rl.rlim_max = rlim_value;
123 unixresult = setrlimit(unixresource, &rl);
```
@fanf Can you have a look, please?October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Tony FinchTony Finch