BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-09-17T07:46:21Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1489ThreadSanitizer: lock-order-inversion (potential deadlock) - findnodeintree v...2020-09-17T07:46:21ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - findnodeintree vs rss_post```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M18589 (0x7b780002a018) => M33903 (0x7b50000500d0) => M18589
Mutex M33903 acquired here while holding mutex M18589 in thr...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M18589 (0x7b780002a018) => M33903 (0x7b50000500d0) => M18589
Mutex M33903 acquired here while holding mutex M18589 in thread T12:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 findnodeintree /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:2742:2 (libdns.so.1505+0xed3db)
#3 findnode /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:2804:10 (libdns.so.1505+0xdd39b)
#4 dns_db_findnode /home/ondrej/Projects/bind9/lib/dns/db.c:447:11 (libdns.so.1505+0x5fb68)
#5 resume_addnsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:3573:11 (libdns.so.1505+0x1dda18)
#6 rss_post /home/ondrej/Projects/bind9/lib/dns/zone.c:19952:3 (libdns.so.1505+0x1dd1e8)
#7 setnsec3param /home/ondrej/Projects/bind9/lib/dns/zone.c:19760:3 (libdns.so.1505+0x1ce1fc)
#8 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#9 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M18589 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 rss_post /home/ondrej/Projects/bind9/lib/dns/zone.c:19951:3 (libdns.so.1505+0x1dd1b4)
#2 setnsec3param /home/ondrej/Projects/bind9/lib/dns/zone.c:19760:3 (libdns.so.1505+0x1ce1fc)
#3 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#4 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M18589 acquired here while holding mutex M33903 in thread T12:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:7991:3 (libdns.so.1505+0x1e6bdb)
#2 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#3 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M33903 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 resume_iteration /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8946:2 (libdns.so.1505+0xf01fb)
#3 dbiterator_next /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:9223:3 (libdns.so.1505+0xef82a)
#4 dns_dbiterator_next /home/ondrej/Projects/bind9/lib/dns/dbiterator.c:88:10 (libdns.so.1505+0x62974)
#5 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:8127:13 (libdns.so.1505+0x1e6f60)
#6 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#7 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#8 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#9 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Thread T12 'isc-worker0003' (tid=17312, running) created by main thread at:
#0 pthread_create <null> (named+0x44011b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75:8 (libisc.so.1504+0x6a9ea)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410:3 (libisc.so.1504+0x4f1b2)
#3 create_managers /home/ondrej/Projects/bind9/bin/named/./main.c:902:11 (named+0x4db206)
#4 setup /home/ondrej/Projects/bind9/bin/named/./main.c:1235:11 (named+0x4d98fe)
#5 main /home/ondrej/Projects/bind9/bin/named/./main.c:1515:2 (named+0x4d85c2)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/home/ondrej/Projects/bind9/bin/named/.libs/named+0x442616) in pthread_rwlock_rdlock
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1488ThreadSanitizer: lock-order-inversion (potential deadlock) - setnsec3paramete...2020-09-17T07:46:13ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - setnsec3parameters vs zone_asyncload```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M17781 (0x7b780001c818) => M921966132255197904 (0x000000000000) => M17781
Mutex M921966132255197904 acquired here while h...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M17781 (0x7b780001c818) => M921966132255197904 (0x000000000000) => M17781
Mutex M921966132255197904 acquired here while holding mutex M17781 in thread T15:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 setnsec3parameters /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:2288:2 (libdns.so.1505+0xec52f)
#3 iszonesecure /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:2261:2 (libdns.so.1505+0xec486)
#4 endload /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:7336:3 (libdns.so.1505+0xdb937)
#5 dns_db_endload /home/ondrej/Projects/bind9/lib/dns/db.c:301:10 (libdns.so.1505+0x5f3ee)
#6 zone_startload /home/ondrej/Projects/bind9/lib/dns/zone.c:2554:13 (libdns.so.1505+0x1cfd16)
#7 zone_load /home/ondrej/Projects/bind9/lib/dns/zone.c:2138:13 (libdns.so.1505+0x1b6796)
#8 zone_asyncload /home/ondrej/Projects/bind9/lib/dns/zone.c:2193:11 (libdns.so.1505+0x1b709c)
#9 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#10 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M17781 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 zone_asyncload /home/ondrej/Projects/bind9/lib/dns/zone.c:2192:2 (libdns.so.1505+0x1b704b)
#2 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#3 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M17781 acquired here while holding mutex M921966132255197904 in thread T9:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:8216:3 (libdns.so.1505+0x1e7942)
#2 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#3 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M921966132255197904 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 resume_iteration /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8946:2 (libdns.so.1505+0xf01fb)
#3 dbiterator_current /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:9268:3 (libdns.so.1505+0xefa7a)
#4 dns_dbiterator_current /home/ondrej/Projects/bind9/lib/dns/dbiterator.c:103:10 (libdns.so.1505+0x62a1a)
#5 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:8253:3 (libdns.so.1505+0x1e7a78)
#6 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#7 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#8 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#9 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Thread T15 'isc-worker0006' (tid=17315, running) created by main thread at:
#0 pthread_create <null> (named+0x44011b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75:8 (libisc.so.1504+0x6a9ea)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410:3 (libisc.so.1504+0x4f1b2)
#3 create_managers /home/ondrej/Projects/bind9/bin/named/./main.c:902:11 (named+0x4db206)
#4 setup /home/ondrej/Projects/bind9/bin/named/./main.c:1235:11 (named+0x4d98fe)
#5 main /home/ondrej/Projects/bind9/bin/named/./main.c:1515:2 (named+0x4d85c2)
Thread T9 'isc-worker0000' (tid=17309, running) created by main thread at:
#0 pthread_create <null> (named+0x44011b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75:8 (libisc.so.1504+0x6a9ea)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410:3 (libisc.so.1504+0x4f1b2)
#3 create_managers /home/ondrej/Projects/bind9/bin/named/./main.c:902:11 (named+0x4db206)
#4 setup /home/ondrej/Projects/bind9/bin/named/./main.c:1235:11 (named+0x4d98fe)
#5 main /home/ondrej/Projects/bind9/bin/named/./main.c:1515:2 (named+0x4d85c2)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/home/ondrej/Projects/bind9/bin/named/.libs/named+0x442616) in pthread_rwlock_rdlock
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1487ThreadSanitizer: lock-order-inversion (potential deadlock) - nodecount vs zon...2020-09-17T07:46:07ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - nodecount vs zone_asyncload```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M17329 (0x7b7800015018) => M35468 (0x7b50000302d0) => M17329
Mutex M35468 acquired here while holding mutex M17329 in thr...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=17286)
Cycle in lock order graph: M17329 (0x7b7800015018) => M35468 (0x7b50000302d0) => M17329
Mutex M35468 acquired here while holding mutex M17329 in thread T15:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 nodecount /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:7637:2 (libdns.so.1505+0xe108d)
#3 dns_db_nodecount /home/ondrej/Projects/bind9/lib/dns/db.c:847:10 (libdns.so.1505+0x613ea)
#4 zone_postload /home/ondrej/Projects/bind9/lib/dns/zone.c:4570:8 (libdns.so.1505+0x1ca704)
#5 zone_load /home/ondrej/Projects/bind9/lib/dns/zone.c:2163:11 (libdns.so.1505+0x1b6ac5)
#6 zone_asyncload /home/ondrej/Projects/bind9/lib/dns/zone.c:2193:11 (libdns.so.1505+0x1b709c)
#7 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#8 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M17329 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 zone_asyncload /home/ondrej/Projects/bind9/lib/dns/zone.c:2192:2 (libdns.so.1505+0x1b704b)
#2 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#3 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M17329 acquired here while holding mutex M35468 in thread T13:
#0 pthread_mutex_lock <null> (named+0x45e376)
#1 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:7991:3 (libdns.so.1505+0x1e6bdb)
#2 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#3 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Mutex M35468 previously acquired by the same thread here:
#0 pthread_rwlock_rdlock <null> (named+0x442616)
#1 isc_rwlock_lock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:50:3 (libisc.so.1504+0x49521)
#2 resume_iteration /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8946:2 (libdns.so.1505+0xf01fb)
#3 dbiterator_next /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:9223:3 (libdns.so.1505+0xef82a)
#4 dns_dbiterator_next /home/ondrej/Projects/bind9/lib/dns/dbiterator.c:88:10 (libdns.so.1505+0x62974)
#5 zone_nsec3chain /home/ondrej/Projects/bind9/lib/dns/zone.c:8127:13 (libdns.so.1505+0x1e6f60)
#6 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10819:4 (libdns.so.1505+0x1e074b)
#7 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13650:2 (libdns.so.1505+0x1c4faa)
#8 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134:7 (libisc.so.1504+0x52007)
#9 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319:2 (libisc.so.1504+0x4f3a8)
Thread T15 'isc-worker0006' (tid=17315, running) created by main thread at:
#0 pthread_create <null> (named+0x44011b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75:8 (libisc.so.1504+0x6a9ea)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410:3 (libisc.so.1504+0x4f1b2)
#3 create_managers /home/ondrej/Projects/bind9/bin/named/./main.c:902:11 (named+0x4db206)
#4 setup /home/ondrej/Projects/bind9/bin/named/./main.c:1235:11 (named+0x4d98fe)
#5 main /home/ondrej/Projects/bind9/bin/named/./main.c:1515:2 (named+0x4d85c2)
Thread T13 'isc-worker0004' (tid=17313, running) created by main thread at:
#0 pthread_create <null> (named+0x44011b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75:8 (libisc.so.1504+0x6a9ea)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410:3 (libisc.so.1504+0x4f1b2)
#3 create_managers /home/ondrej/Projects/bind9/bin/named/./main.c:902:11 (named+0x4db206)
#4 setup /home/ondrej/Projects/bind9/bin/named/./main.c:1235:11 (named+0x4d98fe)
#5 main /home/ondrej/Projects/bind9/bin/named/./main.c:1515:2 (named+0x4d85c2)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/home/ondrej/Projects/bind9/bin/named/.libs/named+0x442616) in pthread_rwlock_rdlock
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1478ThreadSanitizer: lock-order-inversion (potential deadlock) - dns_zone_setview...2020-09-17T07:45:17ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - dns_zone_setviewcommit vs dns_view_setviewcommit```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=1260)
Cycle in lock order graph: M637958001013031032 (0x000000000000) => M423192645322475544 (0x000000000000) => M637958001013031032
Mutex M423192645322475...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=1260)
Cycle in lock order graph: M637958001013031032 (0x000000000000) => M423192645322475544 (0x000000000000) => M637958001013031032
Mutex M423192645322475544 acquired here while holding mutex M637958001013031032 in thread T9:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_zone_setviewcommit /home/ondrej/Projects/bind9/lib/dns/zone.c:1530 (libdns.so.1505+0x20b0bf)
#2 dns_view_setviewcommit /home/ondrej/Projects/bind9/lib/dns/view.c:2355 (libdns.so.1505+0x1fd42d)
#3 load_configuration server.c:8971 (named+0x57743)
#4 run_server server.c:9654 (named+0x59a47)
#5 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56fa6)
#6 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56fa6)
#7 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M637958001013031032 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_view_setviewcommit /home/ondrej/Projects/bind9/lib/dns/view.c:2349 (libdns.so.1505+0x1fd3eb)
#2 load_configuration server.c:8971 (named+0x57743)
#3 run_server server.c:9654 (named+0x59a47)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56fa6)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56fa6)
#6 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M637958001013031032 acquired here while holding mutex M423192645322475544 in thread T10:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_view_findzonecut /home/ondrej/Projects/bind9/lib/dns/view.c:1242 (libdns.so.1505+0x1f7819)
#2 fctx_create /home/ondrej/Projects/bind9/lib/dns/resolver.c:4890 (libdns.so.1505+0x190c0d)
#3 dns_resolver_createfetch /home/ondrej/Projects/bind9/lib/dns/resolver.c:10581 (libdns.so.1505+0x1976b1)
#4 zone_refreshkeys /home/ondrej/Projects/bind9/lib/dns/zone.c:10575 (libdns.so.1505+0x22c089)
#5 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10787 (libdns.so.1505+0x249326)
#6 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13652 (libdns.so.1505+0x249326)
#7 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56fa6)
#8 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56fa6)
#9 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M423192645322475544 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 zone_refreshkeys /home/ondrej/Projects/bind9/lib/dns/zone.c:10462 (libdns.so.1505+0x22b945)
#2 zone_maintenance /home/ondrej/Projects/bind9/lib/dns/zone.c:10787 (libdns.so.1505+0x249326)
#3 zone_timer /home/ondrej/Projects/bind9/lib/dns/zone.c:13652 (libdns.so.1505+0x249326)
#4 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56fa6)
#5 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56fa6)
#6 <null> <null> (libtsan.so.0+0x29b3d)
Thread T9 'isc-worker0000' (tid=1327, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bcc4)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59d63)
#3 create_managers main.c:902 (named+0x1aeec)
#4 setup main.c:1235 (named+0x1aeec)
#5 main main.c:1515 (named+0x1aeec)
Thread T10 'isc-worker0001' (tid=1329, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bcc4)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59d63)
#3 create_managers main.c:902 (named+0x1aeec)
#4 setup main.c:1235 (named+0x1aeec)
#5 main main.c:1515 (named+0x1aeec)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x3d62b) in pthread_mutex_lock
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1470ThreadSanitizer: lock-order-inversion (potential deadlock) - validator_start ...2020-09-17T07:45:09ZOndřej SurýThreadSanitizer: lock-order-inversion (potential deadlock) - validator_start vs. dns_resolver_createfetch```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=21211)
Cycle in lock order graph: M100197 (0x7b7000010008) => M1110 (0x7b7400000008) => M100197
Mutex M1110 acquired here while holding mutex M100197 in th...```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=21211)
Cycle in lock order graph: M100197 (0x7b7000010008) => M1110 (0x7b7400000008) => M100197
Mutex M1110 acquired here while holding mutex M100197 in thread T1:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_resolver_createfetch /home/ondrej/Projects/bind9/lib/dns/resolver.c:10538 (libdns.so.1505+0x196da5)
#2 create_fetch /home/ondrej/Projects/bind9/lib/dns/validator.c:1055 (libdns.so.1505+0x1f1c55)
#3 seek_dnskey /home/ondrej/Projects/bind9/lib/dns/validator.c:1305 (libdns.so.1505+0x1f1c55)
#4 validate_answer /home/ondrej/Projects/bind9/lib/dns/validator.c:1557 (libdns.so.1505+0x1f1c55)
#5 validator_start /home/ondrej/Projects/bind9/lib/dns/validator.c:3157 (libdns.so.1505+0x1f2ac9)
#6 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#7 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#8 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M100197 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 validator_start /home/ondrej/Projects/bind9/lib/dns/validator.c:3140 (libdns.so.1505+0x1f27a8)
#2 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#3 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#4 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M100197 acquired here while holding mutex M1110 in thread T1:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 dns_validator_destroy /home/ondrej/Projects/bind9/lib/dns/validator.c:3402 (libdns.so.1505+0x1f23da)
#2 validated /home/ondrej/Projects/bind9/lib/dns/resolver.c:5379 (libdns.so.1505+0x1a8153)
#3 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#4 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#5 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M1110 previously acquired by the same thread here:
#0 pthread_mutex_lock <null> (libtsan.so.0+0x3d62b)
#1 validated /home/ondrej/Projects/bind9/lib/dns/resolver.c:5365 (libdns.so.1505+0x1a7f4e)
#2 dispatch /home/ondrej/Projects/bind9/lib/isc/task.c:1134 (libisc.so.1504+0x56f36)
#3 run /home/ondrej/Projects/bind9/lib/isc/task.c:1319 (libisc.so.1504+0x56f36)
#4 <null> <null> (libtsan.so.0+0x29b3d)
Thread T1 'isc-worker0000' (tid=21226, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:75 (libisc.so.1504+0x7bc54)
#2 isc_taskmgr_create /home/ondrej/Projects/bind9/lib/isc/task.c:1410 (libisc.so.1504+0x59cf3)
#3 isc_taskmgr_createinctx /home/ondrej/Projects/bind9/lib/isc/task.c:1978 (libisc.so.1504+0x5f3a2)
#4 main /home/ondrej/Projects/bind9/bin/delv/delv.c:1730 (delv+0x3cfa)
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x3d62b) in pthread_mutex_lock
```BIND 9.17 BackburnerDiego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2149The `edns-udp-size` sets the advertised buffer size in the responses2020-09-17T06:18:00ZOndřej SurýThe `edns-udp-size` sets the advertised buffer size in the responsesThe `max-udp-size` controls the amount of the data put into the request, but the `edns-udp-size` is the value that's put in the responses coming from the resolver. A simple test with following `named.conf` will confirm the behaviour:
``...The `max-udp-size` controls the amount of the data put into the request, but the `edns-udp-size` is the value that's put in the responses coming from the resolver. A simple test with following `named.conf` will confirm the behaviour:
```
options {
max-udp-size 512;
edns-udp-size 1232;
};
```
And `dig +bufsize=4096 @localhost` to confirm:
```
; <<>> DiG 9.17.4 <<>> -p 5300 +bufsize @localhost
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26389
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e379761b8aa9b4f4010000005f611030d22f78d5a864fc70 (good)
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518399 IN NS c.root-servers.net.
. 518399 IN NS l.root-servers.net.
. 518399 IN NS m.root-servers.net.
. 518399 IN NS b.root-servers.net.
. 518399 IN NS f.root-servers.net.
. 518399 IN NS d.root-servers.net.
. 518399 IN NS k.root-servers.net.
. 518399 IN NS e.root-servers.net.
. 518399 IN NS h.root-servers.net.
. 518399 IN NS i.root-servers.net.
. 518399 IN NS j.root-servers.net.
. 518399 IN NS g.root-servers.net.
. 518399 IN NS a.root-servers.net.
;; Query time: 0 msec
;; SERVER: ::1#5300(::1)
;; WHEN: Tue Sep 15 21:04:16 CEST 2020
;; MSG SIZE rcvd: 279
```
e.g. the size was capped to 512 (whole `ADDITIONAL` section was dropped), but the advertised buffer size is still `1232` in the response.https://gitlab.isc.org/isc-projects/bind9/-/issues/2074BIND allows an empty 'cm' value for optional LOC RDATA fields2020-09-16T21:01:07ZCathy AlmondBIND allows an empty 'cm' value for optional LOC RDATA fieldsFrom Support ticket [https://support.isc.org/Ticket/Display.html?id=16882](#16882)
Customer says:
```
(Checked the behavior with some recent version on the public git repo, but I believe it's the same
for all versions that support LOC...From Support ticket [https://support.isc.org/Ticket/Display.html?id=16882](#16882)
Customer says:
```
(Checked the behavior with some recent version on the public git repo, but I believe it's the same
for all versions that support LOC).
I've just noticed somewhat awkward behavior of BIND about parsing textual LOC RDATA: it accepts an
empty 'cm' part after a 'dot' of the SIZE or HORIZ/VERT PRE field. For example, it accepts the
following textual RDATA as part of a zone file:
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.m
in this case, the VERT PRE field is specified that way (and is interpreted as "1m").
Is this intentional? The syntax format described in RFC1876 is not very formal, so it could be
left to the implementor's discretion. But it looks quite awkward to me at least, and I wonder whether
this was not really intentional. In that case, you may want to tighten the validation.
I'm reporting this just because I've noticed it. I'm fine if you decided to keep it as is.
```
Then follows up with:
```
(Essentially the same issue but) maybe this looks even more awkward. BIND accepts these
fields just containing a dot (with or without the 'm' suffix):
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .m
and interprets it as "0.00m" (<1cm).
```
And:
```
and one more...it even accepts just with an 'm' (interpreting it as 0.00m):
22 21 54.000 N 71 6 18.000 W -24.00m 30m 0100m m
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/2152Bind 9.17.4 assertion failure2020-09-16T10:25:41ZKlaus DarilionBind 9.17.4 assertion failure### Summary
After upgrade from Bind 9.11.22 to 9.17.4 Bind crashes on startup with an assertion failure.
### BIND version used
BIND 9.17.4-1+ubuntu18.04.1+isc+5-Ubuntu (Development Release) <id:>
running on Linux x86_64 4.15.0-112-gen...### Summary
After upgrade from Bind 9.11.22 to 9.17.4 Bind crashes on startup with an assertion failure.
### BIND version used
BIND 9.17.4-1+ubuntu18.04.1+isc+5-Ubuntu (Development Release) <id:>
running on Linux x86_64 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-nHvHYZ/bind9-9.17.4=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 7.5.0
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
### Steps to reproduce
I do not know. Just startin up the server in our cases generates the assertion failure.
### What is the current *bug* behavior?
Assertion failure
### What is the expected *correct* behavior?
Startup
### Relevant configuration files
I can't share the whole config. Nothing special in it. Here some options:
```
options {
directory "/etc/bind-validation/zones";
auth-nxdomain no; # conform to RFC1035
listen-on { xx.xxx.34.22; };
listen-on-v6 { xxx:xxx:9::7; };
version "IPCom ancast network 1.0";
notify-source xx.xxx.34.22;
notify-source-v6 xxx:xxx:9::7;
transfer-source xx.xxx.34.22;
transfer-source-v6 xxx:xxx:9::7;
try-tcp-refresh no;
notify explicit;
query-source xx.xxx.34.22;
query-source-v6 xxx:xxx:9::7;
/* Disable all zone checks. This should speed up zone loading */
check-names master ignore;
check-names slave ignore;
check-dup-records ignore;
check-mx ignore;
check-wildcard no;
check-integrity no;
check-mx-cname ignore;
check-srv-cname ignore;
check-sibling no;
check-spf ignore;
transfers-in 50; // number of total concurrent zone transfers from the masters to me
transfers-out 200; // number of concurrent zone transfers from me to my slaves
transfers-per-ns 25; // number of concurrent zone transfers per master from the masters to me
max-refresh-time 300;
max-retry-time 300;
// some customers do not allow IXFR. Hence we have to calculate the "diff" ourselfs. Otherwise all
// the zone transfers to the anycast nodes would be AXFR always. (.foo full zone to Singapore
// takes up 1 one hour)
ixfr-from-differences yes; // default: no
request-ixfr yes; // default: yes
max-journal-size 50m; // default: unlimited
pid-file "/var/run/named/named-validation.pid";
allow-recursion {
none;
};
allow-transfer {
...
};
allow-query {
...
};
};
controls {
...
};
logging {
channel default_syslog {
syslog local1;
};
};
```
### Relevant logs and/or screenshots
```
09:05:43 named[5112]: zone asdfasdf.asdfsdf/IN: sending notifies (serial 1600236090)
09:05:43 named[5112]: zone asdfasdfas.dasfdfasdf/IN: sending notifies (serial 1600236087)
09:05:43 named[5112]: zone asfdfasdf.asdfasdfsadf/IN: sending notifies (serial 1600236077)
09:05:43 named[5112]: netmgr/netmgr.c:1112: REQUIRE(((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references); __typeof__ (*__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back trace
09:05:43 named[5112]: zone asdfasdf.asdfasdf/IN: sending notifies (serial 1600236059)
09:05:43 named[5112]: zone sadfsdfasdf.asdfasdf/IN: sending notifies (serial 2020091603)
09:05:43 named[5112]: /usr/sbin/named(+0x2b4cb) [0x5639af3984cb]
09:05:43 named[5112]: zone sdfasdfasdf/IN: sending notifies (serial 1512401053)
09:05:43 named[5112]: zone asfasdf.asdfsdf/IN: sending notifies (serial 1600236082)
09:05:43 named[5112]: /usr/lib/x86_64-linux-gnu/libisc.so.1704(isc_assertion_failed+0xa) [0x7f39dfffe16a]
09:05:43 named[5112]: /usr/lib/x86_64-linux-gnu/libisc.so.1704(isc_nmhandle_ref+0x5a) [0x7f39dffe32ba]
09:05:43 named[5112]: /usr/sbin/named-(+0x28d5b) [0x5639af395d5b]
09:05:43 named[5112]: /usr/lib/x86_64-linux-gnu/libisc.so.1704(+0x4dfef) [0x7f39e001dfef]
09:05:43 named[5112]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f39ddfe16db]
09:05:43 named[5112]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f39dd521a3f]
09:05:43 named[5112]: exiting (due to assertion failure)
```
### Possible fixes
Nonehttps://gitlab.isc.org/isc-projects/bind9/-/issues/113Minor testsummary.sh improvements (handling colored output, failure summary)2020-09-16T10:05:12ZMichał KępieńMinor testsummary.sh improvements (handling colored output, failure summary)`bin/tests/system/testsummary.sh` could be slightly improved, so that it:
* correctly processes colored system test output,
* prints a summary of failed system tests, if any.`bin/tests/system/testsummary.sh` could be slightly improved, so that it:
* correctly processes colored system test output,
* prints a summary of failed system tests, if any.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1637unable to create dispatch for reserved port <ip>#53: permission denied2020-09-14T13:52:58ZMathieu Arnoldunable to create dispatch for reserved port <ip>#53: permission denied### Summary
A lot of those lines are logged when named starts.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e60>
running on FreeBSD amd64 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0: Tue Nov 12 08:59:04 UTC 2019 r...### Summary
A lot of those lines are logged when named starts.
### BIND version used
```
BIND 9.16.0 (Stable Release) <id:6270e60>
running on FreeBSD amd64 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0: Tue Nov 12 08:59:04 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.3' 'build_alias=amd64-portbld-freebsd11.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 -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 356365)
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Start named?
### What is the current *bug* behavior?
When named starts, those lines are printed:
```
Feb 24 16:05:03 ns1 named[58048]: unable to create dispatch for reserved port 79.143.243.129#53: permission denied
Feb 24 16:05:03 ns1 named[58048]: unable to create dispatch for reserved port 2a01:678:2:100::53#53: permission denied
```
A lot.
```
# grep 'unable to create dispatch for reserved port' /var/log/named.log|grep 'Feb 24 16:05'|wc
5330 79950 623610
```
### What is the expected *correct* behavior?
Well, maybe a bit less.
### Relevant configuration files
```
acl "friends" {
127.0.0.1/32;
::1/128;
79.143.243.129/32;
key "yop";
key "oups";
key "ouinch";
key "ns1-gw.in";
key "ns1-gw.mat";
217.70.177.40/32;
82.66.245.111/32;
62.212.120.194/32;
82.229.45.53/32;
217.128.128.42/32;
79.143.243.135/32;
79.143.243.150/32;
79.143.241.142/32;
};
acl "nsabso" {
217.174.201.32/28;
79.143.243.129/32;
83.169.77.112/28;
80.245.57.152/32;
185.167.19.240/28;
};
acl "blocs" {
79.143.240.0/20;
2a01:678::/29;
};
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
inet 79.143.243.129 port 953 allow {
"nsabso";
} keys {
"nsabso";
};
};
logging {
channel "dnssec-log" {
file "/var/log/dnssec.log" versions 4 size 10485760;
severity debug 3;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"default_syslog";
};
category "dnssec" {
"dnssec-log";
};
category "queries" {
"null";
};
};
options {
directory "/usr/local/etc/namedb";
dump-file "/var/dump/named_dump.db";
listen-on {
79.143.243.129/32;
127.0.0.1/32;
};
listen-on-v6 {
2a01:678:2:100::53/128;
2a01:678:2:100::2:53/128;
::1/128;
};
managed-keys-directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
recursing-file "/var/stats/named.recurse";
statistics-file "/var/stats/named.stats";
transfers-in 100;
transfers-out 2000;
transfers-per-ns 10;
allow-recursion {
127.0.0.1/32;
};
dnssec-enable yes;
query-source address 79.143.243.129 port 0;
rate-limit {
exempt-clients {
"blocs";
"friends";
};
responses-per-second 10;
window 30;
};
allow-query {
"any";
};
allow-transfer {
"friends";
};
masterfile-format text;
notify yes;
notify-source 79.143.243.129 port 53;
notify-source-v6 2a01:678:2:100::53 port 53;
transfer-source 79.143.243.129;
transfer-source-v6 2a01:678:2:100::53;
};
key "rndc-key" {
algorithm "hmac-md5";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
key "nsabso" {
algorithm "hmac-md5";
secret "????????????????????????";
};
key "yop" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
key "oups" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
key "ouinch" {
algorithm "hmac-sha256";
secret "????????????????????????";
};
trust-anchors {
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
zone "." {
type hint;
file "named.root";
};
```https://gitlab.isc.org/isc-projects/bind9/-/issues/21369.14.10: query.c:8499: INSIST(qctx->is_zone || (((qctx->client)->query.attrib...2020-09-11T12:23:11ZCathy Almond9.14.10: query.c:8499: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x20000) != 0)) failedAll servers that received a zone update removing some NS delegation RRs crashed 5 mins later with :
query.c:8499: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x20000) != 0)) failed
These servers have:
- root hint zone ...All servers that received a zone update removing some NS delegation RRs crashed 5 mins later with :
query.c:8499: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x20000) != 0)) failed
These servers have:
- root hint zone configured (so not a mirrored root zone - although we don't know what's actually in the root hints)
- global forwarding (defaulting to forward first)
- a secondary zone (that received the NS RRs zone update removing some delegation NS RRset)
- (default) 'qname-minimization relaxed;'
Prior to the zone update, the secondary zone contained delegation RRs that would have caused the resolver to follow the delegation path directly (global forwarding overridden in the zone definition).
We do not know if ALL the delegation RRs were removed for each subdomain, or only some of them. We also don't know if there was an exception made to the usual IXFR zone update process this time around.
The zone update should have been received via IXFR and was the removal of 50,000 RRs from a 250,000 RR zone.
Post zone-update, all the servers that crashed received a client query that should have either been answered from, or followed delegation from, the zone that had just been updated.
This crash location looks very much like #1862, but the scenario is a little different, due to the lack of mirrored root.
We have core dumps, binaries and libs available - please see [Support Ticket #17077](https://support.isc.org/Ticket/Display.html?id=17077) for further customer-confidential details.
**NOTE: This is an important issue for a high-status ISC customer. Although this was encountered on 9.14.10, assurance is needed that the underlying cause is identified and has (or will be soon) fixed.**Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1997[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an...2020-09-11T09:02:40ZOndřej Surý[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an assertion failure in resolver.c### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
``...### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
```
BIND 9.16.4-Ubuntu (Stable Release) <id:0849b42>
running on Linux x86_64 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64
-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads'
'--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=
no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-cWwckC/bind9-9.16.4=. -fstack-protector-strong -Wformat -
Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Not sure, named is running fine and suddenly I will notice resolving slows on clients as DNS reverts to the secondary resolver, upon checking the service status it is "failed" in systemd. The service restarts but then crashes intermittently, approximately every 1-3 days.
### What is the current *bug* behavior?
Service fails and resolving stops.
### What is the expected *correct* behavior?
Service should not fail/stop
### Relevant configuration files
```
root@HOST:~# named-checkconf -px
...
```
[Sanitized by @mnowak.]
### Relevant logs and/or screenshots
Console output of /var/log/bind/bind.log
```
30-Jun-2020 00:00:02.536 general: notice: all zones loaded
30-Jun-2020 00:00:02.536 general: notice: running
30-Jun-2020 10:19:36.354 general: critical: resolver.c:5104: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
30-Jun-2020 10:19:36.354 general: critical: #0 0x55b9b83ff083 in ??
30-Jun-2020 10:19:36.354 general: critical: #1 0x7f4ea095cac0 in ??
30-Jun-2020 10:19:36.354 general: critical: #2 0x7f4ea0b26675 in ??
30-Jun-2020 10:19:36.354 general: critical: #3 0x7f4ea0b29e90 in ??
30-Jun-2020 10:19:36.354 general: critical: #4 0x7f4ea0b2fdb8 in ??
30-Jun-2020 10:19:36.354 general: critical: #5 0x7f4ea0b348a1 in ??
30-Jun-2020 10:19:36.354 general: critical: #6 0x7f4ea0984d51 in ??
30-Jun-2020 10:19:36.354 general: critical: #7 0x7f4ea0425609 in ??
30-Jun-2020 10:19:36.354 general: critical: #8 0x7f4ea034c103 in ??
30-Jun-2020 10:19:36.354 general: critical: exiting (due to assertion failure)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1219[CVE-2019-6476] resolver.c:4917: INSIST(dns_name_issubdomain(&fctx->name, &fc...2020-09-11T09:02:39ZGhost User[CVE-2019-6476] resolver.c:4917: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace causes BIND to die<!--
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
BIND died after this log:
```
general: critical: resolver.c:4917: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
```
### BIND version used
```
BIND 9.14.5 (Stable Release) <id:c2c2b6d>
running on FreeBSD amd64 11.2-RELEASE-p14-HBSD FreeBSD 11.2-RELEASE-p14-HBSD 07680caafe9(stable/19.7)
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-openssl=/usr/local' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--without-gssapi' '--with-libidn2=/usr/local' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.2' 'build_alias=amd64-portbld-freebsd11.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DHARDENEDBSD -DLIBICONV_PLUG -fPIE -fPIC -fstack-protector-all -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -Wl,-rpath,/usr/local/lib -pie -Wl,-z,relro -Wl,-z,now -fstack-protector-all ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)
compiled with OpenSSL version: OpenSSL 1.0.2s 28 May 2019
linked to OpenSSL version: OpenSSL 1.0.2s 28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Unknown
### What is the current *bug* behavior?
bind dies
### What is the expected *correct* behavior?
bind stays alive
### Relevant configuration files
```
controls {
inet 127.0.0.1 port 9530 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
};
logging {
channel "default_log" {
file "/var/log/named/named.log" versions 3 size 5242880;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query_log" {
file "/var/log/named/query.log" versions 3 size 5242880;
print-time yes;
};
channel "rpz_log" {
file "/var/log/named/rpz.log" versions 3 size 5242880;
print-time yes;
};
category "default" {
"default_log";
};
category "general" {
"default_log";
};
category "queries" {
"query_log";
};
category "rpz" {
"rpz_log";
};
};
options {
directory "/usr/local/etc/namedb/working";
dump-file "/var/dump/named_dump.db";
listen-on port 53530 {
10.99.201.1/32;
};
listen-on-v6 port 53530 {
::1/128;
};
pid-file "/var/run/named/pid";
statistics-file "/var/stats/named.stats";
dnssec-validation auto;
max-cache-size 80%;
response-policy {
zone "whitelist.localdomain";
zone "blacklist.localdomain";
};
forwarders {
1.1.1.1;
1.0.0.1;
};
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "." {
type hint;
file "/usr/local/etc/namedb/named.root";
};
zone "localhost" {
type master;
file "/usr/local/etc/namedb/master/localhost-forward.db";
};
zone "127.in-addr.arpa" {
type master;
file "/usr/local/etc/namedb/master/localhost-reverse.db";
};
zone "0.ip6.arpa" {
type master;
file "/usr/local/etc/namedb/master/localhost-reverse.db";
};
zone "whitelist.localdomain" {
type master;
check-names ignore;
file "/usr/local/etc/namedb/master/whitelist.db";
notify no;
};
zone "blacklist.localdomain" {
type master;
check-names ignore;
file "/usr/local/etc/namedb/master/blacklist.db";
notify no;
};
```
### Relevant logs and/or screenshots
```
08-Sep-2019 14:01:29.753 general: critical: exiting (due to assertion failure)
08-Sep-2019 14:01:29.753 general: critical: #7 0x0 in ??
08-Sep-2019 14:01:29.753 general: critical: #6 0x3e007b0dc36 in ??
08-Sep-2019 14:01:29.753 general: critical: #5 0x3b13830d1ed in ??
08-Sep-2019 14:01:29.753 general: critical: #4 0x3b138244169 in ??
08-Sep-2019 14:01:29.753 general: critical: #3 0x3b13823b04c in ??
08-Sep-2019 14:01:29.753 general: critical: #2 0x3b138234728 in ??
08-Sep-2019 14:01:29.753 general: critical: #1 0x3b1382ed18a in ??
08-Sep-2019 14:01:29.753 general: critical: #0 0x3b138102120 in ??
08-Sep-2019 14:01:29.753 general: critical: resolver.c:4917: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
08-Sep-2019 14:01:29.745 lame-servers: info: chase DS servers resolving 'd10u1qvpabtlks.cloudfront.net/DS/IN': 1.0.0.1#53
08-Sep-2019 14:01:29.514 lame-servers: info: chase DS servers resolving 'd10u1qvpabtlks.cloudfront.net/DS/IN': 1.1.1.1#53
```
### Incident tracking page
https://wiki.isc.org/bin/view/Main/SecurityIncidentChecklist20196476QminAndForwardersOctober 2019 (9.11.12, 9.14.7, 9.15.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/2119The runtime system tests interfered with each other2020-09-10T10:41:41ZMark AndrewsThe runtime system tests interfered with each otherOctober 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2116Views system test was not waiting for example to finish loading.2020-09-10T08:50:36ZMark AndrewsViews system test was not waiting for example to finish loading.This caused intermittent failures especially when a sanitizer was running.This caused intermittent failures especially when a sanitizer was running.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/2138big performance loss in 9.16 compared to version 9.112020-09-10T08:48:31ZLaurent Gouhierbig performance loss in 9.16 compared to version 9.11<!--
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
I was doing some test before upgrading from bind 9.11 to 9.16
and I encounter a big perfomance loss between those verions.
I have a loss of 75% ! I was at 400k query per second in bind 9.11
and in bind 9.16 i was only at 100k query per second
### BIND version used
BIND 9.16.6 (Stable Release) <id:25846cf>
BIND 9.11.22 (Extended Support Version) <id:6a05a96>
### Steps to reproduce
Use the following named.conf file :
````
options {
listen-on-v6 { any; };
version "";
max-cache-size 100M;
max-journal-size 10M;
check-names master ignore;
check-integrity no;
check-sibling no;
dnssec-secure-to-insecure yes;
directory "/etc/namedb";
recursion no;
server-id "bind-auth";
};
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} ;
};
acl "admin" {
"any";
};
zone "incache" {
type master;
file "incache";
allow-update { any; };
};
````
And for the incache zone use the following zone file :
````
$ORIGIN @
$TTL 86400 ; 1 day
@ IN SOA bench. root. (
6293 ; serial
21600 ; refresh (6 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
600 ; minimum (10 minutes)
)
NS bench
bench A 10.0.22.24
$TTL 86400 ; 1 day
* A 1.1.1.1
* AAAA 8888::1111
````
Then run a dnsperf (using the file in atachement ):
````
dnsperf -c 2 -l -d file.dnsperf -s $DNS_IP
````
[file.dnsperf](/uploads/aa5b63b63af3f768a42c661976f4b033/file.dnsperf)
### What is the current *bug* behavior?
In the Curent Stable 9.16 on FreeBSD 11-Stable I have 100k query per second
And in the 9.11 on same hardware and same os I have 400k query per second
On a FreeBSD-12 it is better but i still have a performance drop.
On current : 9.16 200k query per second
: 9.11 100k query per second
### What is the expected *correct* behavior?
I was expecting at least to have the same performance on both versions.
### Relevant logs and/or screenshots
DNSPERF on 9.16 : `
````
[Status] Testing complete (time limit)
Statistics:
Queries sent: 966633
Queries completed: 966633 (100.00%)
Queries lost: 0 (0.00%)
Response codes: NOERROR 966633 (100.00%)
Average packet size: request 29, response 45
Run time (s): 10.000892
Queries per second: 96654.678403
Average Latency (s): 0.001024 (min 0.000047, max 0.001866)
Latency StdDev (s): 0.000074
````
DNSPERF on 9.11 :
````
[Status] Testing complete (time limit)
Statistics:
Queries sent: 4144501
Queries completed: 4144501 (100.00%)
Queries lost: 0 (0.00%)
Response codes: NOERROR 4144501 (100.00%)
Average packet size: request 29, response 81
Run time (s): 10.000196
Queries per second: 414441.976937
Average Latency (s): 0.000225 (min 0.000035, max 0.013790)
Latency StdDev (s): 0.000053
````https://gitlab.isc.org/isc-projects/bind9/-/issues/1862query.c:8628: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x...2020-09-09T14:48:49ZWitold Krecickiquery.c:8628: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x20000) != 0)) failed, back traceResolver crashes when queried when starting up if both qname minimization and root mirroring is configured.
When we're coming back from recursion we don't accept DNS_R_NXDOMAIN as an answer (hence the INSIST).
Here, the DNS_R_NXDOMAIN ...Resolver crashes when queried when starting up if both qname minimization and root mirroring is configured.
When we're coming back from recursion we don't accept DNS_R_NXDOMAIN as an answer (hence the INSIST).
Here, the DNS_R_NXDOMAIN is returned by:
resume_qmin:4403 -> dns_view_findzonecut:1355 -> dns_db_find()July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1570BIND9 9.14 (and 9.11) fails to build when jsoncpp is installed2020-09-08T08:56:32ZMathieu ArnoldBIND9 9.14 (and 9.11) fails to build when jsoncpp is installedI have had [a report](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243387) of a FreeBSD user that BIND9 9.14 was failing to build if jsoncpp was installed. This is because the configure code assumes that if include/json/json.h is t...I have had [a report](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243387) of a FreeBSD user that BIND9 9.14 was failing to build if jsoncpp was installed. This is because the configure code assumes that if include/json/json.h is there, libjson is there, without actually checking that the lib is actually there. It then goes on to first check that either libjson or libjson-c exist, but if libjson-c exists, it does not call AC_DEFINE(HAVE_JSON_C...) so it breaks during build.
The same problem exists in the BIND9 9.11 branch.
It was fixed in 4d2d3b49ce0e5f2bf4a796980a599b110fc2d22d on master to have two configure knobs, one for libjson, and one for libjson-c, maybe it could be backported to the v9_14 and v9_11 branches.
(Or maybe change the ordering of the configure code so that libjson-c is checked first.)https://gitlab.isc.org/isc-projects/bind9/-/issues/855JSON C library detection in configure.in2020-09-08T08:56:31ZGhost UserJSON C library detection in configure.inSmall improvement to help the proper detection of the JSON C library when the JSON C++ library / headers are installed in addition to the C library. The patch swaps the header detection in configure.in so that the generated configure cor...Small improvement to help the proper detection of the JSON C library when the JSON C++ library / headers are installed in addition to the C library. The patch swaps the header detection in configure.in so that the generated configure correctly identifies C instead of C++ headers (I first came across this issues when bind tried to incorrectly include a C++ header instead of a C header when both JSON libraries where installed on Arch).
[json_in.patch](/uploads/68bbae4f4eafa09ce54283f26b2a21b5/json_in.patch)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2132BIND 9.11 fails to build on FreeBSD with devel/jsoncpp installed2020-09-08T08:56:29ZMichal NowakBIND 9.11 fails to build on FreeBSD with devel/jsoncpp installed`9.11` (but not `9_16` and `main`) fails to build on FreeBSD when `devel/jsoncpp` is installed and JSON is enabled in BIND:
```
--- app.o ---
In file included from app.c:33:
In file included from ../include/isc/mem.h:20:
In file included...`9.11` (but not `9_16` and `main`) fails to build on FreeBSD when `devel/jsoncpp` is installed and JSON is enabled in BIND:
```
--- app.o ---
In file included from app.c:33:
In file included from ../include/isc/mem.h:20:
In file included from ../include/isc/json.h:36:
In file included from /usr/local/include/json/json.h:9:
/usr/local/include/json/config.h:8:10: fatal error: 'cstddef' file not found
#include <cstddef>
^~~~~~~~~
```
For the time being I resolved this locally by uninstalling `devel/jsoncpp` port.
Here's downstream bug report (for 9.14) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243387 with a link to their solution.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)