BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T09:19:55Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4315CID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"2023-11-02T09:19:55ZMichal NowakCID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID ...Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465575: (TAINTED_SCALAR)
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
** CID 465574: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465574: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
** CID 465573: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465573: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465572: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465572: (TAINTED_SCALAR)
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
** CID 465571: Insecure data handling (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465571: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/any_255/tsig_250.c: 525 in tostruct_any_tsig()
519 isc_region_consume(&sr, 2);
520
521 /*
522 * Other.
523 */
524 INSIST(sr.length == tsig->otherlen);
>>> CID 465571: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "tsig->otherlen" to "mem_maybedup", which uses it as an offset.
525 tsig->other = mem_maybedup(mctx, sr.base, tsig->otherlen);
526
527 tsig->mctx = mctx;
528 return (ISC_R_SUCCESS);
529 }
530
** CID 465570: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465570: (TAINTED_SCALAR)
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465569: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465569: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
** CID 465568: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465568: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
** CID 465567: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465567: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
** CID 465566: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465566: (TAINTED_SCALAR)
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4303dnstap logging based on rcode2023-09-13T14:09:41ZPetr Špačekpspacek@isc.orgdnstap logging based on rcode### Motivation
When FORMERR or SERVFAIL happen in the middle of resolution, we don't have exact information what we have sent and what exactly came back. We have to guess and attempt to reproduce the problem with `dig` or other tools.
#...### Motivation
When FORMERR or SERVFAIL happen in the middle of resolution, we don't have exact information what we have sent and what exactly came back. We have to guess and attempt to reproduce the problem with `dig` or other tools.
### Request
Add parameter to `dnstap` statement which would allow logging just selected RCODEs. Presumably FORMERR and/or SERVFAIL. I imagine that this could be so low-touch that it could be running in production indefinitely (as a cyclic buffer).
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4301ans4 server failed to shut down in upforwd test2023-11-16T11:42:31ZMark Andrewsans4 server failed to shut down in upforwd testJob [#3640428](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3640428) failed for f60dd556ad1b4a8454afeaaf6017cf4922a31ada:
```
2023-09-06 05:26:40 INFO:upforwd I:upforwd_tmp_1y_2pk5t:ans4 didn't die when sent a SIGTERM
2023-09-06...Job [#3640428](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3640428) failed for f60dd556ad1b4a8454afeaaf6017cf4922a31ada:
```
2023-09-06 05:26:40 INFO:upforwd I:upforwd_tmp_1y_2pk5t:ans4 didn't die when sent a SIGTERM
2023-09-06 05:26:40 ERROR:upforwd Failed to stop servers
2023-09-06 05:26:40 INFO:upforwd I:upforwd_tmp_1y_2pk5t:Core dump(s) found: /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908
2023-09-06 05:26:40 INFO:upforwd D:upforwd_tmp_1y_2pk5t:backtrace from /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908:
2023-09-06 05:26:40 INFO:upforwd D:upforwd_tmp_1y_2pk5t:--------------------------------------------------------------------------------
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:Core was generated by `/usr/bin/perl ans.pl'.
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:Program terminated with signal SIGABRT, Aborted.
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#0 0x00007f85c2db40d4 in __GI___select (nfds=8, readfds=0x5560c664e9e0, writefds=0x0, exceptfds=0x0, timeout=0x0) at ../sysdeps/unix/sysv/linux/select.c:69
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#0 0x00007f85c2db40d4 in __GI___select (nfds=8, readfds=0x5560c664e9e0, writefds=0x0, exceptfds=0x0, timeout=0x0) at ../sysdeps/unix/sysv/linux/select.c:69
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#1 0x00005560c4591ec7 in Perl_pp_sselect ()
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#2 0x00005560c4536c06 in Perl_runops_standard ()
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#3 0x00005560c4497881 in perl_run ()
2023-09-06 05:26:49 INFO:upforwd D:/builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t:#4 0x00005560c4469482 in main ()
2023-09-06 05:26:49 INFO:upforwd D:upforwd_tmp_1y_2pk5t:--------------------------------------------------------------------------------
2023-09-06 05:26:49 INFO:upforwd D:upforwd_tmp_1y_2pk5t:full backtrace from /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908 saved in /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908-backtrace.txt
2023-09-06 05:26:49 INFO:upforwd D:upforwd_tmp_1y_2pk5t:core dump /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908 archived as /builds/isc-projects/bind9/bin/tests/system/upforwd_tmp_1y_2pk5t/ans4/core.75908.gz
2023-09-06 05:26:49 ERROR:upforwd Found core dumps or sanitizer reports
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4297Follow-up from "Resolve "UAF in validator logging""2023-09-06T01:05:12ZMark AndrewsFollow-up from "Resolve "UAF in validator logging""The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would...The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would be attached to the `dns_name_t` instead of just assigned to prevent this reordering issues? What would be the performance impact of such change?Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4272stress:rpz:fedora:38:arm64 crashed (async_restart at query.c:5843)2023-10-03T15:24:25ZMichal Nowakstress:rpz:fedora:38:arm64 crashed (async_restart at query.c:5843)After one minute runtime, the `stress:rpz:fedora:38:arm64` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3599502) on `main`.
```
Core was generated by `/builds/isc-projects/bind9/.local/usr/local/sbin/named -f -c ./named.co...After one minute runtime, the `stress:rpz:fedora:38:arm64` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3599502) on `main`.
```
Core was generated by `/builds/isc-projects/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffff9949e5e0 in async_restart (arg=0xffff15302000) at query.c:5843
5843 isc_mem_put(client->manager->mctx, qctx, sizeof(*qctx));
[Current thread is 1 (Thread 0xffff96cfe300 (LWP 24042))]
#0 0x0000ffff9949e5e0 in async_restart (arg=0xffff15302000) at query.c:5843
#1 0x0000ffff99755b10 in isc__async_cb (handle=<optimized out>) at async.c:111
#2 0x0000ffff98cda0c0 in uv__async_io (loop=0xffff974830a0, w=0xffff97483270, events=1) at /usr/src/libuv-v1.46.0/src/unix/async.c:176
#3 0x0000ffff98cf6d0c in uv__io_poll (loop=0xffff974830a0, timeout=5) at /usr/src/libuv-v1.46.0/src/unix/linux.c:1476
#4 0x0000ffff98cdb084 in uv_run (loop=0xffff974830a0, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.46.0/src/unix/core.c:447
#5 0x0000ffff99768800 in loop_thread (arg=arg@entry=0xffff97483080) at loop.c:282
#6 0x0000ffff997787c8 in thread_body (wrap=wrap@entry=0x3e733a90) at thread.c:85
#7 0x0000ffff997787f8 in thread_run (wrap=0x3e733a90) at thread.c:100
#8 0x0000ffff9861bc74 in start_thread () from /lib64/libc.so.6
#9 0x0000ffff9868925c in thread_start () from /lib64/libc.so.6
```
[core.24039-backtrace.txt](/uploads/61b63bae17f042b4dc2d1153cc9948dc/core.24039-backtrace.txt)
[named.log](/uploads/10dd091e5632bfcc7457c0f367874b4b/named.log)
On [retry](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3600371) it didn't immediately crash.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4268There is a performance waste in the rpz check2023-08-22T07:06:22ZMr BenThere is a performance waste in the rpz check
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9....
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:5218cdf>
running on Linux x86_64 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021
built by make with '--enable-dnstap' '--enable-epoll' '--with-dlz-filesystem' '--with-libjson' '--with-libtool' '--enable-dnsdrps' '--prefix=/data/named/' 'CFLAGS= -O0 -g -DDEBUG' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1p 21 Jun 2022
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
default paths:
named configuration: /data/named/etc/named.conf
rndc configuration: /data/named/etc/rndc.conf
DNSSEC root key: /data/named/etc/bind.keys
nsupdate session key: /data/named/var/run/named/session.key
named PID file: /data/named/var/run/named/named.pid
named lock file: /data/named/var/run/named/named.lock
```
### Steps to reproduce
```
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
```
### What is the current *bug* behavior?
It is not reflected in the function, but it is reflected in the code logic.
```
eg:
dig @127.0.0.1 www.microsoft.com
;; ANSWER SECTION:
www.microsoft.com. 1496 IN CNAME www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net. 247 IN CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. 203 IN CNAME e13678.ca2.s.tl88.net.
e13678.ca2.s.tl88.net. 158 IN A 218.58.101.49
```
The rpz module checks the following domain names twice, which is a huge waste of performance:
www.microsoft.com, www.microsoft.com-c-3.edgekey.net, www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
### What is the expected *correct* behavior?
Each domain name is checked only once。
### Relevant configuration files
```
Configure the rpz module normally:
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
and the file of badlist.zone is:
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
```
### Relevant logs and/or screenshots
none.
### Possible fixes
The call of the rpz module should be migrated from query_gotanswer to before query_gotanswer:
```
if (!RECURSING(qctx->client) &&
!dns_name_equal(qctx->client->query.qname, dns_rootname))
{
result = query_checkrpz(qctx, result);
if (result == ISC_R_COMPLETE) {
return (ns_query_done(qctx));
}
}
```
After the query resume function is triggered, it will execute to ns_query_start. It is not necessary to call rpz in query_gotanswer after query_resume, but call rpz in ns_query_start, which reduces the number of rpz calls.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4261Detect unexpected files created during system test run with pytest runner2023-12-06T15:51:28ZTom KrizekDetect unexpected files created during system test run with pytest runner> we should have a check whether the named haven't produced any unexpected files. But that's only tangential to cleaning up the cruft. Perhaps this can take a form of .gitignore(?) with expected files for each test.
https://gitlab.isc.o...> we should have a check whether the named haven't produced any unexpected files. But that's only tangential to cleaning up the cruft. Perhaps this can take a form of .gitignore(?) with expected files for each test.
https://gitlab.isc.org/isc-projects/bind9/-/issues/4246#note_395492
Related #3810Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4256implement 0x202023-08-22T16:07:55ZEvan Huntimplement 0x20A recent conversation on dnsop reminded me that several of the open source servers have implemented the 0x20 draft, and now google public DNS has done so as well, and we still haven't.
The idea is to add entropy to outgoing queries by r...A recent conversation on dnsop reminded me that several of the open source servers have implemented the 0x20 draft, and now google public DNS has done so as well, and we still haven't.
The idea is to add entropy to outgoing queries by randomizing the case of letters in the query name. There are two parts to this:
1. The resolver requires responses to have an exact bit-for-bit copy of the name that was sent, and ignores responses that don't. We'd probably need a `server` option to relax this requirement in the event that a remote server was known to be responding persistently with the QNAME downsized. (This is arguably something we might want to do just for the sake of better protocol compliance; our current practice of case-insensitive QNAME matching seems a little iffy to me.)
2. When sending queries, the resolver randomly capitalizes letters in query names. We'd need a `view` option to decide whether to do this. For a first iteration I'd default to off.
Pros:
- cheap way to increase entropy, so why not
- ticks off a feature-parity box with unbound, knot resolver, google public DNS, probably others
Cons:
- doesn't add much entropy for short QNAMEs, which are more frequent now with QNAME minimization, and kinda important
- some increase in complexity
- may break resolution with some servers that work now
- we already have DNS COOKIE and should prioritize thatNot plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4254zonechecks died mid test2023-08-10T13:14:02ZMark Andrewszonechecks died mid testJob [#3577320](https://gitlab.isc.org/isc-private/bind9/-/jobs/3577320) failed for isc-private/bind9@51f47c4d045f50dd0e72573cd573a5031261fed4:
zonechecks died mid test possibly fallout from setting `-e`.
```
2023-08-10 07:15:03 INFO:zo...Job [#3577320](https://gitlab.isc.org/isc-private/bind9/-/jobs/3577320) failed for isc-private/bind9@51f47c4d045f50dd0e72573cd573a5031261fed4:
zonechecks died mid test possibly fallout from setting `-e`.
```
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (fail)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (warn=default)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking that we detect a NS which looks like a AAAA record (ignore)
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:checking 'rdnc zonestatus' output
2023-08-10 07:15:03 INFO:zonechecks I:zonechecks_tmp_w6aef5m0:ns1 zone reload queued
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4239Add dnstap-output support for tcp2023-08-02T08:00:29ZMr BenAdd dnstap-output support for tcp### Description
goals:Add dnstap-output support for tcp
### Request
###
Now the output of dnstap only supports file and unix domain socket to generate logs. I expect to output logs in the form of tcp, so that the log server can be on ...### Description
goals:Add dnstap-output support for tcp
### Request
###
Now the output of dnstap only supports file and unix domain socket to generate logs. I expect to output logs in the form of tcp, so that the log server can be on other hosts. Reduce the overhead of the dns server itself.
The reason for such a requirement is that in the production environment, even if the dns server itself generates logs, they will still be output to other places for analysis and detection through tcp/udp. It is better to output directly to other hosts.
###
### Links / references
###
Like coredns, it supports tcp output log.
dnstap /tmp/dnstap.sock
dnstap unix:///tmp/dnstap.sock full
dnstap tcp://127.0.0.1:6000 full
dnstap tcp://example.com:6000 full
###Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4237Remove "dialup" and "heartbeat-interval"2024-03-01T04:30:01ZEvan HuntRemove "dialup" and "heartbeat-interval"The "dialup" and "heartbeat-interval" options have been deprecated in 9.20 (see #3700, !8080) and will need to be removed later.
The due date for this issue has been set to an arbitrary date that is presumed to fall within the BIND 9.21...The "dialup" and "heartbeat-interval" options have been deprecated in 9.20 (see #3700, !8080) and will need to be removed later.
The due date for this issue has been set to an arbitrary date that is presumed to fall within the BIND 9.21 development cycle.Not plannedEvan HuntEvan Hunt2024-08-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4233dig: add +human option2023-08-08T13:04:27ZJulia Evansdig: add +human option### Description
I've spent a lot of time explaining `dig` to newcomers to DNS over the years, and I've found that they generally find `dig`'s output format to be very inscrutable. Of course, there's always `+short` or `+noall +answer` f...### Description
I've spent a lot of time explaining `dig` to newcomers to DNS over the years, and I've found that they generally find `dig`'s output format to be very inscrutable. Of course, there's always `+short` or `+noall +answer` for a terser output, but I generally want to explain more advanced DNS concepts to people (like glue records or SOA records for example), and for that you do need the full output.
Some specific things that I find confusing in dig's default output: ([example output here](https://gist.github.com/jvns/2d252e3f54a86ee6b2ea001e733a8e78))
* There's some ASCII art decoration (`<<>> DiG 9.10.6 <<>>`, `->>HEADER<<-`) that feels very ad hoc and it's hard to tell initially if those symbols are supposed to have some technical meaning. (why is `->>HEADER<--` styled like that, but not `OPT PSEUDOSECTION`?)
* the header is split across 2 lines, and it's not completely clear that the second line is also part of the header
* overall, it's not obvious which pieces of information are part of the DNS response itself and which aren't. For example, is `global options: +cmd` part of the DNS response? (of course it isn't, I don't think that's immediately obvious)
* There's no newline between `OPT PSEUDOSECTION` and `QUESTION SECTION`, but there is a newline between `QUESTION SECTION` and `ANSWER SECTION`. There seems to be no reason for that inconsistency.
* In `MSG SIZE rcvd: 56`, why are there two spaces between `SIZE` and `rcvd`? Are there more fields in `MSG SIZE`? (I checked the source code and the answer is no, the code says `printf(";; MSG SIZE rcvd: %u\n", bytes);`, so it seems like this is just an ad hoc choice)
* The `;;` prefix is confusing to many people. I realize it's because `;` it's the comment character in a zone file, but I personally do not use `bind` or zone files and most DNS users I talk to don't either: they either use web-based admin consoles to administrate their DNS records or do it through an API like Route 53. So the `;` character isn't familiar.
These might sound a little nitpicky -- each of these things on its own is pretty minor, and of course most users of dig learn to ignore them. But taken together I've found that newcomers are often misled into thinking that DNS responses are much more complicated than they actually are, which is really unfortunate.
I find the way Wireshark displays DNS packets to be much more clear ([screenshot](https://jvns.ca/images/dns-wireshark.png)), even though they're both working at around the same level of detail.
### Request
I realize that `dig`'s default output format needs to remain relatively stable because people parse it in scripts. But would ISC be open to adding a `+human` (or something) option to dig that's designed to be more intuitive for newcomers to dig? Similarly to how `du` has an `-h` option.
I'm imagining something like this:
```
$ dig +human example.com
Received response from 192.168.1.1:53 (UDP), 68 bytes in 16ms
HEADER:
status: NOERROR
opcode: QUERY
id: 15451
flags: qr rd ra
records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
OPT PSEUDOSECTION:
EDNS: version: 0, flags: None, udp: 4096
QUESTION SECTION:
example.com. IN A
ANSWER SECTION:
example.com. 78709 IN A 93.184.216.34
```
I think the important thing is to make it easy for a newcomer to see at a glance that there are 4 parts to this DNS response (the header, the EDNS record, the question, and the answer)
I created a very rough proof of concept at https://github.com/jvns/dig-pretty that parses dig's `+yaml` format and outputs a format like what I suggested above, with a tiny bit of syntax highlighting for the DNS status code.
### Alternatives I've considered
* `+short` or `+noall +answer` are great for a lot of use cases, but as I mentioned above, they don't work for more advanced usage like looking at the `SOA` record on a `NXDOMAIN` response.
* We already have `+yaml`, but I find `+yaml` to be extremely verbose (the output for `dig +yaml example.com` doesn't fit in my terminal window), and it's really a machine format and not a human format.
* There are also alternative DNS tools (like `dog`) that aim to be more user friendly, but in general I've found those tools to be missing important features that `dig` has.
Thanks for considering this! I love dig and would love to see it become a little more approachable.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4230checkds test may fail due to a timing issue2024-01-02T13:40:29ZMark Andrewscheckds test may fail due to a timing issueJob [#3552282](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3552282) failed for 423c9d6716c4b96f0cf939653da47abca267bd23:
```
___________________________ test_checkds_dspublished ___________________________
[gw0] linux -- Python 3.1...Job [#3552282](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3552282) failed for 423c9d6716c4b96f0cf939653da47abca267bd23:
```
___________________________ test_checkds_dspublished ___________________________
[gw0] linux -- Python 3.11.4 /usr/bin/python3.11
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:640: in test_checkds_dspublished
checkds_dspublished(named_port, "explicit", "10.53.0.8")
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:308: in checkds_dspublished
keystate_check(parent, zone, "DSPublish")
/builds/isc-projects/bind9/bin/tests/system/checkds/tests_checkds.py:228: in keystate_check
assert val != 0
E assert 0 != 0
```Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4219Exempt from fetch-limits, fetches generated as a result of prefetch of someth...2023-12-19T09:19:57ZCathy AlmondExempt from fetch-limits, fetches generated as a result of prefetch of something already in cache (opened as feature request, but could also be considered to be a design defect)### Description
Exempt fetches generated as a result of prefetch of something already in cache, from fetch limits
### Request
fetches-per-zone and fetches-server were originally designed to limit the number of pending fetches from a r...### Description
Exempt fetches generated as a result of prefetch of something already in cache, from fetch limits
### Request
fetches-per-zone and fetches-server were originally designed to limit the number of pending fetches from a resolver to auth servers when the auth servers were failing to respond (thus causing a backlog of fetches). There is another use-case for fetch-limits that we have observed (see [Support ticket #18991](https://support.isc.org/Ticket/Display.html?id=18991)) in which fetch-limits are used instead to limit concurrent queries to servers that are responding normally, even under DDoS query loads. In this situation the intention of applying the fetch-limits is to limit the impact on the auth servers of the DDoS. But this has the unfortunate effect of also rate-limiting 'good' queries.
For the 'good' queries for popular names - those are only going to be sent to the authoritative servers on a cache miss, or when previously cached content is close to expiry. Therefore one additional potential mitigation would be to try to ensure a much 'good' content remains in cache, so that it's only the 'new' or 'bad' content queries that causes fetches. IF prefetches (of previous known 'good' content, not negative NXDOMAIN or NXRRSET) were allowed a free pass through the fetch limits fence, then this would help in maintaining a good cache from which good query responses could be given, whilst at the same time rate-limiting the 'bad' queries being sent to the auth servers.
### Links / referencesBIND 9.21.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4218Extract the no DS proof, if any, from the referral and save/validate it.2023-07-25T06:56:43ZMark AndrewsExtract the no DS proof, if any, from the referral and save/validate it.Insecure referrals contain a no DS proof. We are currently not using it and instead are make DS queries and validating those. Extracting the no DS proof should resolution for data in insecure zones.Insecure referrals contain a no DS proof. We are currently not using it and instead are make DS queries and validating those. Extracting the no DS proof should resolution for data in insecure zones.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4216Report missing DNSSEC algorithms in returned RRSIGs2023-11-02T16:30:30ZMark AndrewsReport missing DNSSEC algorithms in returned RRSIGsWhile we only require one DNSSEC algorithm to validate a response reporting missing algorithms listed in the DS RRset will be useful for the overall health of the system.While we only require one DNSSEC algorithm to validate a response reporting missing algorithms listed in the DS RRset will be useful for the overall health of the system.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4206dig(1) returns success on AXFR failure2023-07-13T22:57:25ZJan Schaumanndig(1) returns success on AXFR failure<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential!
-->
### Summary
When a zone transfer using dig(1) fails, the resulting exit status is '0', indicating success.
This makes it difficult to script around dig(1) and goes counter to common unix practice.
### BIND version used
BIND 9.14.7 (Extended Support Version) <id:d410de0>
running on NetBSD amd64 9.3 NetBSD 9.3 (PANIX-VC) #1: Wed Aug 17 12:34:21 EDT 2022 root@juggler.panix.com:/misc/obj64/misc/devel/netbsd/9.3/src/sys/arch/amd64/compile/PANIX-VC
built by make with defaults
compiled by GCC 7.5.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
threads support is enabled
### Steps to reproduce
```
$ dig @a.nic.de. AXFR de.
; <<>> DiG 9.14.7 <<>> @a.nic.de. AXFR de.
; (2 servers found)
;; global options: +cmd
; Transfer failed.
$ echo $?
0
$
```
### What is the current *bug* behavior?
dig(1) exits successfully, (`echo $?` yields `0`).
### What is the expected *correct* behavior?
dig(1) should exit with an exit value > 0.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dig/dighost.c#L3542
Possibly add `exitcode = 252;` (or whatever) there? I'm not sure if that bubbles up, but either way that line seems like a good place to start.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4205OpenAPI Description Document for the JSON statistics channel2023-07-12T15:31:13ZMarkus KötterOpenAPI Description Document for the JSON statistics channel### Description
Using the JSON statistics channel is easier when parsing of the data is accomplished using a description document.
### Request
I prepared the following description document - it validates and works.
Possible improveme...### Description
Using the JSON statistics channel is easier when parsing of the data is accomplished using a description document.
### Request
I prepared the following description document - it validates and works.
Possible improvements include:
- not using additionalProperties: { type: integer } for the statistics,
- document the statistic values (https://gitlab.isc.org/isc-projects/bind9/-/issues/3878)
- require properties
Would be great if you could include this next to https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/named/bind9.xsl and have the webserver serve it as bind9.yaml similar to https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/named/statschannel.c#L3138 for ease of use.
### Links / references
As I'm unable to fork the repo and create a MR (project limit reached), it is embedded inline.
```yaml
openapi: "3.0.0"
info:
version: "0.1"
title: OpenAPI Description Document for Bind9 JSON statistics channel
servers:
- url: /
paths:
/json:
get:
operationId: summary
responses:
'200':
description: The Summary
content:
application/json:
schema:
$ref: "#/components/schemas/Summary"
/json/v1/status:
# /json/v1:
get:
operationId: status
responses:
'200':
description: The Status
content:
application/json:
schema:
$ref: "#/components/schemas/Status"
/json/v1/server:
get:
operationId: server
responses:
'200':
description: The Status
content:
application/json:
schema:
$ref: "#/components/schemas/Server"
/json/v1/zones:
get:
operationId: zones
responses:
'200':
description: The Zones
content:
application/json:
schema:
$ref: "#/components/schemas/Views"
/json/v1/net:
get:
operationId: net
responses:
'200':
description: The Sockstats
content:
application/json:
schema:
$ref: "#/components/schemas/Sockstats"
/json/v1/mem:
get:
operationId: mem
responses:
'200':
description: The Memory Statistics
content:
application/json:
schema:
$ref: "#/components/schemas/Memory"
/json/v1/traffic:
get:
operationId: traffic
responses:
'200':
description: The Traffic Statistics
content:
application/json:
schema:
$ref: "#/components/schemas/Traffic"
components:
schemas:
Status:
type: object
additionalProperties: False
properties:
json-stats-version:
type: string
boot-time:
type: string
format: date-time
config-time:
type: string
format: date-time
current-time:
type: string
format: date-time
version:
type: string
Server:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
- $ref: "#/components/schemas/Views"
properties:
opcodes:
type: object
additionalProperties:
type: integer
rcodes:
type: object
additionalProperties:
type: integer
qtypes:
type: object
additionalProperties:
type: integer
nsstats:
type: object
additionalProperties:
type: integer
zonestats:
type: object
additionalProperties:
type: integer
Views:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
views:
type: object
additionalProperties:
$ref: "#/components/schemas/View"
View:
type: object
additionalProperties: False
properties:
zones:
type: array
items:
$ref: "#/components/schemas/Zone"
resolver:
type: object
additionalProperties: False
properties:
stats:
type: object
additionalProperties:
type: integer
qtypes:
type: object
additionalProperties:
type: integer
cache:
type: object
additionalProperties:
type: integer
cachestats:
type: object
additionalProperties:
type: integer
adb:
type: object
additionalProperties:
type: integer
Zone:
type: object
additionalProperties: False
properties:
name:
type: string
class:
type: string
serial:
type: integer
type:
type: string
loaded:
type: string
Sockstats:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
sockstats:
type: object
additionalProperties:
type: integer
Memory:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
memory:
type: object
additionalProperties: False
properties:
TotalUse:
type: integer
InUse:
type: integer
Malloced:
type: integer
ContextSize:
type: integer
Lost:
type: integer
contexts:
type: array
items:
$ref: "#/components/schemas/MemoryContext"
MemoryContext:
type: object
additionalProperties: False
properties:
id:
type: string
name:
type: string
references:
type: integer
total:
type: integer
inuse:
type: integer
maxinuse:
type: integer
malloced:
type: integer
maxmalloced:
type: integer
pools:
type: integer
hiwater:
type: integer
lowater:
type: integer
Traffic:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
traffic:
type: object
additionalProperties:
$ref: "#/components/schemas/TrafficData"
TrafficData:
type: object
additionalProperties:
type: integer
TaskMgr:
type: object
additionalProperties: False
properties:
taskmgr:
type: object
additionalProperties: False
properties:
thread-model:
type: string
default-quantum:
type: integer
tasks:
type: array
items:
$ref: "#/components/schemas/Task"
Task:
type: object
additionalProperties: False
properties:
id:
type: string
name:
type: string
references:
type: integer
state:
type: string
quantum:
type: integer
events:
type: integer
Summary:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
- $ref: "#/components/schemas/Server"
- $ref: "#/components/schemas/Views"
- $ref: "#/components/schemas/Memory"
- $ref: "#/components/schemas/Sockstats"
- $ref: "#/components/schemas/Traffic"
- $ref: "#/components/schemas/TaskMgr"
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4204Deprecate and remove the "tkey-gssapi-credential" option2023-07-11T10:49:40ZMichał KępieńDeprecate and remove the "tkey-gssapi-credential" optionThe `CHANGES` entry accompanying the introduction of the
`tkey-gssapi-keytab` option ([back from 2010][1]) suggests that this
option is intended to supersede `tkey-gssapi-credential`:
2987. [func] Improve ease of configuring TKEY/G...The `CHANGES` entry accompanying the introduction of the
`tkey-gssapi-keytab` option ([back from 2010][1]) suggests that this
option is intended to supersede `tkey-gssapi-credential`:
2987. [func] Improve ease of configuring TKEY/GSS updates by
adding a "tkey-gssapi-keytab" option. If set,
updates will be allowed with any key matching
a principal in the specified keytab file.
"tkey-gssapi-credential" is no longer required
and is expected to be deprecated. (Contributed
by Andrew Tridgell of the Samba project.)
[RT #22629]
Given that the documentation for TKEY-related configuration knobs is
already tricky to plow through for someone not well-versed in GSSAPI
(like yours truly), I guess having multiple ways of configuring that
machinery is a cherry on top.
If I am reading the documentation correctly, I think `tkey-domain` could
perhaps also be ripped out, but the relationship between all the moving
parts is not quite clear to me.
[1]: 71bd858d8ed62672e7c23999dc7c02fd16a55089Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4199dig (and other tools) may send queries with QID=0, which confuses Net::DNS2023-11-02T16:30:30ZMichał Kępieńdig (and other tools) may send queries with QID=0, which confuses Net::DNSUnless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In partic...Unless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In particular, the value chosen can be 0. While QID=0 is perfectly
legal protocol-wise, it seems that some code bases, e.g. Net::DNS, are
unable to properly handle queries with QID=0. Here is an example:
https://gitlab.isc.org/isc-private/bind9/-/jobs/3509123
```
2023-07-06 14:14:45 INFO:serve-stale I:serve-stale_tmp_iwl06k82:disable responses from authoritative server (89)
2023-07-06 14:14:57 INFO:serve-stale I:serve-stale_tmp_iwl06k82:failed
```
`bin/tests/system/serve-stale_tmp_iwl06k82/dig.out.test89`:
```
;; Warning: ID mismatch: expected ID 0, got 46879
;; communications error to 10.53.0.2#19223: timed out
; <<>> DiG 9.19.15 <<>> +time +tries -p 19223 @10.53.0.2 txt disable
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
This looked weird to me, so I started `ans2/ans2.pl` manually and sent a
query to it using `dig @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1`.
Guess what:
```
;; Warning: ID mismatch: expected ID 0, got 27885
;; communications error to 10.53.0.2#5300: timed out
; <<>> DiG 9.19.15 <<>> @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
Looking at [Net::DNS sources][1], the documentation says:
```
=head2 id
print "query id = ", $packet->header->id, "\n";
$packet->header->id(1234);
Gets or sets the query identification number.
A random value is assigned if the argument value is undefined.
```
However, the above seems to be imprecise: apparently if the ID is
*defined*, but *set to 0*, Net::DNS treats it as an undefined value.
This causes the `$packet->header->id` call to return a random value
instead of 0 for queries with QID=0, breaking responses to such queries.
I don't see any reasonable way to work around this problem in our Perl
code (apart from converting it to Python). Adding `+qid` to every `dig`
invocation in the system test suite also seems over the top for working
around something this silly. However, until we do something about this,
we might be seeing a whole class of surprising failures in the system
test suite caused by this behavior.
[1]: https://www.net-dns.org/svn/net-dns/trunk/lib/Net/DNS/Header.pmNot planned