ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-06-29T13:04:00Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4186Name Buffer Truncation2023-06-29T13:04:00ZMarkus VervierName Buffer Truncation
### Summary
A truncation of the name of memory pools was found which might lead to unintended behavior
or incorrect debugging output.
A memory pool structure `isc_mempool` has a member field name with a capacity of 16 bytes as
shown i...
### Summary
A truncation of the name of memory pools was found which might lead to unintended behavior
or incorrect debugging output.
A memory pool structure `isc_mempool` has a member field name with a capacity of 16 bytes as
shown in the following listing from file `lib/isc/mem.c`:
~~~c
struct isc_mempool {
/* always unlocked */
unsigned int magic;
isc_mem_t *mctx;
/*%< our memory context */
ISC_LINK(isc_mempool_t) link; /*%< next pool in this mem context */
element *items;
/*%< low water item list */
size_t size;
/*%< size of each item on this pool */
size_t allocated;
/*%< # of items currently given out */
size_t freecount;
/*%< # of items on reserved list */
size_t freemax;
/*%< # of items allowed on free list */
size_t fillcount;
/*%< # of items to fetch on each fill */
/*%< Stats only. */
size_t gets; /*%< # of requests to this pool */
/*%< Debugging only. */
char name[16]; /*%< printed name in stats reports */
};
~~~
In the function `dns_zonemgr_create()` a string of size 16 without the terminating NUL byte is passed
on to function `isc_mem_setname()`, leading to silent truncation of the last character in that string
as shown in the following listing:
~~~c
for (size_t i = 0; i < zmgr->workers; i++) {
isc_mem_create(&zmgr->mctxpool[i]);
isc_mem_setname(zmgr->mctxpool[i], "zonemgr-mctxpool");
,→
// MARK truncation / off by one (namebuffer is 16 bytes only)
}
~~~
This issue is informational since the truncation has no security implications, but could lead to
incorrect assumptions or functionality defects.
### BIND version used
BIND 9.19.13 (Development Release) <id:66a3c6b>
### Possible fixes
X41 recommends either increase the buffer size or shorten the name value, but to also add an
assertion to the `isc_mem_create()` function that ensures the name size is larger than zero and less
than 16 bytes without the terminating NUL byte.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4164Investigate performance impact of UDP_GRO2023-06-27T07:06:24ZPetr Špačekpspacek@isc.orgInvestigate performance impact of UDP_GRO### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple dat...### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.
More reading:
https://developers.redhat.com/articles/2021/11/05/improve-udp-performance-rhel-85
### Request
- Investigate if UDP receipt is even a bottleneck.
- Investigate if UDP_GRO makes a difference and is worth messing with (I supposed in libuv).
### Links / referencesLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4162SHA-1 removal2023-06-27T07:27:14ZPetr Špačekpspacek@isc.orgSHA-1 removal### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all app...### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all applications** by December 31, 2030
### Request
Don't get caught asleep at the wheel.
### Links / references
Send questions about the transition in an email to sha-1-transition@nist.gov. Visit the [Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions) page to learn more.Long-term2030-12-31https://gitlab.isc.org/isc-projects/bind9/-/issues/4161Support quantum safe DNSSEC algorithms2023-06-27T07:27:28ZPetr Špačekpspacek@isc.orgSupport quantum safe DNSSEC algorithms### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early exp...### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early experimentation.
Many algorithms are already available as OpenSSL provider here: https://github.com/open-quantum-safe/oqs-provider
### Additional details
* [FALCON implementation in PowerDNS](https://indico.dns-oarc.net/event/42/contributions/902/attachments/871/1601/Post-Quantum%20DNSSEC%20with%20FALCON-512%20and%20PowerDNS(2).pdf)
* [Verisign's presentation](https://indico.dns-oarc.net/event/46/contributions/985/attachments/938/1728/OARC40-ResearchAgendaForAPQCDNSSEC-Final.pdf)
Word of mouth from Red Hat crypto people I talked to:
Right now it seems that NIST might standardize 5 algorithms, with several variants for each algorithm with intent to provide 128/256 bit-equivalent of security.
Rambling about candidate algorithms for DNSSEC:
- HSS/LMS & XMSS^MT algorithms are extremely susceptible to key reuse. One key reuse ruins the whole thing. Don't use it.
- Falcon-512 has smallest signatures by large margin (around 666 bytes). CRYSTALS-Dillithium are built on the same principle but have larger signatures (about 2420 bytes). The problem is, both are reportedly built on shaky grounds because we as humankind don't fully understand the math behind them, so chances for breaking these algorithms in couple years are non-negligible.
- The remaining candidate algorithm is SPHINCS+-128. That one is most solid because it's based on ordinary hashes, which are well understood. The catch is that one signature is about 7856 bytes :exploding_head:
Consequently, this sounds like we need very good very solid TCP/TLS/QUIC support in client and server, so we are not limited to UDP packet sizes. That's IMHO the only way to go without significantly changing the protocol.
(Or we can go and engineer DNS 2.0 :grinning:)
### Links / referencesLong-term2026-01-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4160doth system test is failing on MacOS - both system's CA store tests based are...2023-09-05T21:16:42ZMark Andrewsdoth system test is failing on MacOS - both system's CA store tests based are failingLooks like we are getting a different error state and the expected message is not emitted.
```
S:doth:2023-06-22T16:29:52+1000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:5300,5301,5302,5303,5304,5305,5306,5307,5308,5309,5310,5311,5...Looks like we are getting a different error state and the expected message is not emitted.
```
S:doth:2023-06-22T16:29:52+1000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:5300,5301,5302,5303,5304,5305,5306,5307,5308,5309,5310,5311,5312
I:doth:starting servers
I:doth:checking DoT query (with TLS verification using the system's CA store, failure expected) (1)
setup_libs()
setup_system()
create_search_list()
ndots is 1.
timeout is 0.
retries is 3.
get_server_list()
make_server(::1)
dig_query_setup
parse_args()
making new lookup
make_empty_lookup()
make_empty_lookup() = 0x1061e4000->references = 1
main parsing +tls
main parsing +noadd
main parsing +nosea
main parsing +nostat
main parsing +noquest
main parsing +nocmd
main parsing -p
main parsing +tls-ca
main parsing +tls-hostname=srv01.crt01.example.com
main parsing @10.53.0.1
make_server(10.53.0.1)
main parsing .
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x1061e5800->references = 1
clone_server_list()
make_server(10.53.0.1)
looking up .
main parsing SOA
main parsing -d
dig_startup()
start_lookup()
setup_lookup(0x1061e5800)
resetting lookup counter.
idn_textname: .
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x10613c8c0 linked to lookup 0x1061e5800
dighost.c:2141:lookup_attach(0x1061e5800) = 2
dighost.c:2651:new_query(0x10613c8c0) = 1
do_lookup()
start_tcp(0x10613c8c0)
dighost.c:2928:query_attach(0x10613c8c0) = 2
query->servname = 10.53.0.1
dighost.c:3016:query_attach(0x10613c8c0) = 3
isc_tls_create -> 0x106086000
initialize_tls -> success
tls_do_bio: sock->tlsstream.state=0
SSL_do_handshake -> -1
tls_do_bio: tls_try_handshake -> -1
tls_do_bio: tls_status=2 saved_errno=0
tls_do_bio: tls_process_outgoing -> 303
tls_do_bio: sock->tlsstream.state=1
tls_do_bio: tls_status=2 saved_errno=0
tls_do_bio: tls_process_outgoing -> 0
tls_do_bio: SSL_ERROR_WANT_READ
tls_readcb: success
tls_do_bio: sock->tlsstream.state=1
SSL_do_handshake -> -1
tls_do_bio: tls_status=5 saved_errno=0
tls_do_bio: tls_process_outgoing -> 7
tls_do_bio: sock->tlsstream.state=1
tls_do_bio: tls_status=5 saved_errno=0
tls_do_bio: tls_process_outgoing -> 0
tls_do_bio: SSL_ERROR_WANT_READ
tls_readcb: end of file
tls_failed_read_cb: end of file
tls_failed_read_cb: is is TLS counterpart of isc__nm_failed_connect_cb()
tls_call_connect_cb: calling sock->connect_cb(0x10613ed80, end of file, 0x10610a800)
streamdns_transport_connected: end of file -> operation canceled
streamdns_transport_connected: sock->streamdns.tls_verify_error=unable to get local issuer certificate
tcp_connected()
tcp_connected(0x10613ef40, operation canceled, 0x10613c8c0)
dighost.c:3526:lookup_attach(0x1061e5800) = 3
in cancel handler
dighost.c:3546:_cancel_lookup()
canceling pending query 0x10613c8c0, belonging to 0x1061e5800
dighost.c:1729:query_detach(0x10613c8c0) = 2
dighost.c:2774:query_detach(0x10613c8c0) = 1
check_if_done()
list empty
dighost.c:3549:query_detach(0x10613c8c0) = 0
dighost.c:3549:destroy_query(0x10613c8c0) = 0
dighost.c:1687:lookup_detach(0x1061e5800) = 2
dighost.c:3550:lookup_detach(0x1061e5800) = 1
clear_current_lookup()
lookup cleared
dighost.c:1820:lookup_detach(0x1061e5800) = 0
destroy_lookup
freeing server 0x106109e00 belonging to 0x1061e5800
start_lookup()
check_if_done()
list empty
shutting down
shutdown
destroy_lookup
freeing server 0x106108a00 belonging to 0x1061e4000
cancel_all()
destroy_libs()
flush_server_list()
destroy DST lib
Removing log context
Destroy memory
I:doth:failed
I:doth:exit status: 1
I:doth:stopping servers
R:doth:FAIL
E:doth:2023-06-22T16:29:57+1000
FAIL: doth
============================================================================
Testsuite summary for BIND 9.19.15-dev
============================================================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See bin/tests/system/run.log
Please report to https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Bug
============================================================================
make[3]: *** [run.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1
```
[debugging diff](/uploads/a1a79a1bb5239c456385dd40fc4a08f8/diff)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4158investigate performance impact of huge pages2023-06-27T07:27:35ZPetr Špačekpspacek@isc.orginvestigate performance impact of huge pages- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-u...- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/configuring-huge-pages_monitoring-and-managing-system-status-and-performanceLong-termhttps://gitlab.isc.org/isc-projects/keama/-/issues/22keama silently suppresses shared-networks with one subnet2023-09-21T07:41:57ZThomas Markwalderkeama silently suppresses shared-networks with one subnetThe following discussion from !6 should be addressed:
- [ ] @tmark started a [discussion](https://gitlab.isc.org/isc-projects/keama/-/merge_requests/6#note_380506): (+1 comment)
> If a shared-network only has one subnet, keama emi...The following discussion from !6 should be addressed:
- [ ] @tmark started a [discussion](https://gitlab.isc.org/isc-projects/keama/-/merge_requests/6#note_380506): (+1 comment)
> If a shared-network only has one subnet, keama emits only the subnet, omitting the network. I'm not sure I agree with suppressing the network in that case, but keama also does not log that the network is being omitted, leaving one to scratch one's head.
>
> See this comment in confparse.c:
> ```
> /* There is one subnet so the shared network is useless */
>
> ```4.5.1https://gitlab.isc.org/isc-projects/bind9/-/issues/4118Data race lib/dns/adb.c:1537 in clean_finds_at_name2023-09-04T09:09:22ZMichal NowakData race lib/dns/adb.c:1537 in clean_finds_at_nameJob [respdiff-long:tsan](https://gitlab.isc.org/isc-private/bind9/-/jobs/3440993) failed for [d2fbe443b833d093f68bf4f5a1736242fc8d18a1](https://gitlab.isc.org/isc-private/bind9/-/commit/d2fbe443b833d093f68bf4f5a1736242fc8d18a1) (~"v9.18-...Job [respdiff-long:tsan](https://gitlab.isc.org/isc-private/bind9/-/jobs/3440993) failed for [d2fbe443b833d093f68bf4f5a1736242fc8d18a1](https://gitlab.isc.org/isc-private/bind9/-/commit/d2fbe443b833d093f68bf4f5a1736242fc8d18a1) (~"v9.18-S").
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: write M1, write M2):
#0 clean_finds_at_name lib/dns/adb.c:1537
#1 fetch_callback lib/dns/adb.c:4009
#2 task_run lib/isc/task.c:815
#3 isc_task_run lib/isc/task.c:896
#4 isc__nm_async_task netmgr/netmgr.c:848
#5 process_netievent netmgr/netmgr.c:920
#6 process_queue netmgr/netmgr.c:1013
#7 process_all_queues netmgr/netmgr.c:767
#8 async_cb netmgr/netmgr.c:796
#9 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#10 isc__trampoline_run lib/isc/trampoline.c:189
Previous read of size 4 at 0x000000000001 by thread T2:
#0 findname lib/dns/resolver.c:3749
#1 fctx_getaddresses lib/dns/resolver.c:3993
#2 fctx_try lib/dns/resolver.c:4390
#3 rctx_nextserver lib/dns/resolver.c:10356
#4 rctx_done lib/dns/resolver.c:10503
#5 resquery_response lib/dns/resolver.c:8511
#6 udp_recv lib/dns/dispatch.c:638
#7 isc__nm_async_readcb netmgr/netmgr.c:2885
#8 isc__nm_readcb netmgr/netmgr.c:2858
#9 udp_recv_cb netmgr/udp.c:650
#10 isc__nm_udp_read_cb netmgr/udp.c:1057
#11 uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:303
#12 isc__trampoline_run lib/isc/trampoline.c:189
Location is heap block of size 256 at 0x000000000025 allocated by thread T2:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:651
#1 mallocx lib/isc/jemalloc_shim.h:35
#2 mem_get lib/isc/mem.c:343
#3 isc__mem_get lib/isc/mem.c:761
#4 new_adbfind lib/dns/adb.c:1901
#5 dns_adb_createfind lib/dns/adb.c:2934
#6 findname lib/dns/resolver.c:3656
#7 fctx_getaddresses lib/dns/resolver.c:3993
#8 fctx_try lib/dns/resolver.c:4390
#9 rctx_nextserver lib/dns/resolver.c:10356
#10 rctx_done lib/dns/resolver.c:10503
#11 resquery_response lib/dns/resolver.c:8511
#12 udp_recv lib/dns/dispatch.c:638
#13 isc__nm_async_readcb netmgr/netmgr.c:2885
#14 isc__nm_readcb netmgr/netmgr.c:2858
#15 udp_recv_cb netmgr/udp.c:650
#16 isc__nm_udp_read_cb netmgr/udp.c:1057
#17 uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:303
#18 isc__trampoline_run lib/isc/trampoline.c:189
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/thread.c:73
#2 isc__netmgr_create netmgr/netmgr.c:311
#3 isc_managers_create lib/isc/managers.c:31
#4 create_managers bin/named/main.c:1042
#5 setup bin/named/main.c:1313
#6 main bin/named/main.c:1594
Thread T2 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/thread.c:73
#2 isc__netmgr_create netmgr/netmgr.c:311
#3 isc_managers_create lib/isc/managers.c:31
#4 create_managers bin/named/main.c:1042
#5 setup bin/named/main.c:1313
#6 main bin/named/main.c:1594
SUMMARY: ThreadSanitizer: data race lib/dns/adb.c:1537 in clean_finds_at_name
```Not plannedhttps://gitlab.isc.org/isc-projects/keama/-/issues/20better document logic statements are unsupported2023-09-21T07:41:57ZDarren Ankneybetter document logic statements are unsupportedThis is best shown with example.
Partial ISC DHCP configuration
```
if exists agent.circuit-id
{
log ( error, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address), " is connected to ", option agent.circuit-id));
}
...This is best shown with example.
Partial ISC DHCP configuration
```
if exists agent.circuit-id
{
log ( error, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address), " is connected to ", option agent.circuit-id));
}
option space CALIXGC;
option CALIXGC.acs-url code 1 = text;
if (substring(option vendor-class-identifier, 0, 21) = "844G.ONT.dslforum.org") {
vendor-option-space CALIXGC;
option CALIXGC.acs-url "http://example.com:8080/user/pass";
}
```
get migrated to:
```
{
"Dhcp4": {
// "statement": {
// "if": {
// "condition": {
// "exists": {
// "universe": "agent",
// "name": "circuit-id",
// "code": 1
// }
// },
// "then": [
// {
// /// Kea does not support yet log statements
// /// Reference Kea #234
// "log": {
// "priority": "error",
// "message": {
// "concat": {
// "left": "Lease for ",
// "right": {
// "concat": {
// "left": {
// "binary-to-ascii": {
// "base": 10,
// "width": 8,
// "separator": ".",
// "buffer": {
// "leased-address": null
// }
// }
// },
// "right": {
// "concat": {
// "left": " is connected to ",
// "right": {
// "option": {
// "universe": "agent",
// "name": "circuit-id",
// "code": 1
// }
// }
// }
// }
// }
// }
// }
// }
// }
// }
// ]
// }
// },
"option-def": [
{
"space": "CALIXGC",
"name": "acs-url",
"code": 1,
"type": "string"
}
]
// "statement": {
// "if": {
// "condition": {
// "equal": {
// "left": {
// "substring": {
// "expression": {
// "option": {
// "universe": "dhcp",
// "name": "vendor-class-identifier",
// "code": 60
// }
// },
// "offset": 0,
// "length": 21
// }
// },
// "right": "844G.ONT.dslforum.org"
// }
// },
// "then": [
// {
// "config": {
// "name": "vendor-option-space",
// "code": 19,
// "value": "CALIXGC"
// }
// },
// {
// "option": {
// "space": "CALIXGC",
// "name": "acs-url",
// "code": 1,
// "data": "http://example.com:8080/user/pass"
// }
// }
// ]
// }
// }
}
}
```
Perhaps just print the original unsupported logic statement from the ISC DHCP configuration with a comment about how these are not supported but there is probably another method to accomplish the intent.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/19group statements converted incorrectly (or ignored?)2023-09-21T07:41:57ZDarren Ankneygroup statements converted incorrectly (or ignored?)The best way to illustrate this is with example.
Here is an example dhcpd.conf (partial)
```
group {
filename "Xncd19r";
next-server www.microsoft.com;
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; fixed-address 10.0.3.252...The best way to illustrate this is with example.
Here is an example dhcpd.conf (partial)
```
group {
filename "Xncd19r";
next-server www.microsoft.com;
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; fixed-address 10.0.3.252; }
host ncd2 { hardware ethernet 0:c0:c3:80:fc:32; fixed-address 10.0.3.253; }
host ncd3 { hardware ethernet 0:c0:c3:22:46:81; fixed-address 10.0.3.254; }
}
host ncd10 {
hardware ethernet 00:00:00:11:11:11;
fixed-address 10.0.3.251;
filename "Xncd19r";
next-server www.microsoft.com;
}
```
which are migrated by keama to:
```
"reservations": [
{
"hostname": "ncd1",
"hw-address": "00:c0:c3:49:2b:57",
"ip-address": "10.0.3.252"
},
{
"hostname": "ncd2",
"hw-address": "00:c0:c3:80:fc:32",
"ip-address": "10.0.3.253"
},
{
"hostname": "ncd3",
"hw-address": "00:c0:c3:22:46:81",
"ip-address": "10.0.3.254"
},
{
"hostname": "ncd10",
"hw-address": "00:00:00:11:11:11",
"ip-address": "10.0.3.251",
"boot-file-name": "Xncd19r",
"next-server": "184.84.169.167"
}
```
note how ncd1, ncd2 and ncd3 are lacking the "next-server" and "boot-file-name" attributes.
Example dhcpd.conf was taken from ISC DHCP man pages.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/18next-server option causes migration failure if host is unknown2023-09-21T07:41:57ZDarren Ankneynext-server option causes migration failure if host is unknownA simple configuration like this:
```
group {
filename "Xncd19c";
next-server ncd-booter;
host ncd4 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd5 { hardware ethernet 0:c0:c3:00:14:11; }
}
```
causes the error:
```
ncd-booter...A simple configuration like this:
```
group {
filename "Xncd19c";
next-server ncd-booter;
host ncd4 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd5 { hardware ethernet 0:c0:c3:00:14:11; }
}
```
causes the error:
```
ncd-booter: host unknown.
next-server ncd-booter;
^
```
which is printed to stderr and stops the input configuration from being migrated.
It is possible that, wherever this is being run, the host may not be valid from that location (e.g., internal private network hosts). This is especially true now that it is available from the web: https://dhcp.isc.org
The above example configuration is taken from the ISC DHCP man pages.4.5.1https://gitlab.isc.org/isc-projects/bind9/-/issues/4099[PATCH] +shortans2023-05-30T13:24:54ZFredrick Brennan[PATCH] +shortans# Patch
```diff
From 6041dcb60313b5fd81076bd53713b8a53fb95f87 Mon Sep 17 00:00:00 2001
From: Fredrick Brennan <copypaste@kittens.ph>
Date: Sat, 27 May 2023 08:23:45 -0400
Subject: [PATCH] [dig] +shortans
---
bin/dig/dig.c | 48 +++++...# Patch
```diff
From 6041dcb60313b5fd81076bd53713b8a53fb95f87 Mon Sep 17 00:00:00 2001
From: Fredrick Brennan <copypaste@kittens.ph>
Date: Sat, 27 May 2023 08:23:45 -0400
Subject: [PATCH] [dig] +shortans
---
bin/dig/dig.c | 48 ++++++++++++++++++++++++++++++++++++------------
bin/dig/dig.rst | 4 ++++
doc/man/dig.1in | 5 +++++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/bin/dig/dig.c b/bin/dig/dig.c
index 694924c0f2..dd9bfcd4a7 100644
--- a/bin/dig/dig.c
+++ b/bin/dig/dig.c
@@ -286,6 +286,8 @@ help(void) {
"short\n"
" form of answers - global "
"option)\n"
+ " +[no]shortans (equivalent to `+noall"
+ "+authority +answer`)\n"
" +[no]showbadcookie (Show BADCOOKIE message)\n"
" +[no]showsearch (Search with intermediate "
"results)\n"
@@ -1901,18 +1903,40 @@ plus_option(char *option, bool is_batchfile, bool *need_clone,
goto invalid_option;
}
switch (cmd[3]) {
- case 'r': /* short */
- FULLCHECK("short");
- short_form = state;
- if (state) {
- printcmd = false;
- lookup->section_additional = false;
- lookup->section_answer = true;
- lookup->section_authority = false;
- lookup->section_question = false;
- lookup->comments = false;
- lookup->stats = false;
- lookup->rrcomments = -1;
+ case 'r': /* shor… */
+ switch(cmd[4]) {
+ case 't': /* short… */
+ switch(cmd[5]) { /* short */
+ case '\0':
+ FULLCHECK("short");
+ short_form = state;
+ if (state) {
+ printcmd = false;
+ lookup->section_additional = false;
+ lookup->section_answer = true;
+ lookup->section_authority = false;
+ lookup->section_question = false;
+ lookup->comments = false;
+ lookup->stats = false;
+ lookup->rrcomments = -1;
+ }
+ break;
+ case 'a': /* shortans */
+ FULLCHECK("shortans");
+ lookup->section_question = !state;
+ lookup->section_authority = state;
+ lookup->section_answer = state;
+ lookup->section_additional = !state;
+ lookup->comments = !state;
+ lookup->stats = !state;
+ printcmd = !state;
+ break;
+ default:
+ goto invalid_option;
+ }
+ break;
+ default:
+ goto invalid_option;
}
break;
case 'w': /* showsearch */
diff --git a/bin/dig/dig.rst b/bin/dig/dig.rst
index a5bfb86556..75237f0ae0 100644
--- a/bin/dig/dig.rst
+++ b/bin/dig/dig.rst
@@ -571,6 +571,10 @@ abbreviation is unambiguous; for example, :option:`+cd` is equivalent to
form. This option always has a global effect; it cannot be set globally and
then overridden on a per-lookup basis.
+.. option:: +shortans, +noshortans
+
+ This option expands to :option:`+noall` :option:`+authority` :option:`+answer`.
+
.. option:: +showbadcookie, +noshowbadcookie
This option toggles whether to show the message containing the
diff --git a/doc/man/dig.1in b/doc/man/dig.1in
index d5f42ed852..1607d7f2ca 100644
--- a/doc/man/dig.1in
+++ b/doc/man/dig.1in
@@ -663,6 +663,11 @@ then overridden on a per\-lookup basis.
.UNINDENT
.INDENT 0.0
.TP
+.B +shortans, +noshortans
+This option expands to \fI\%+noall\fP \fI\%+authority\fP \fI\%+answer\fP\&.
+.UNINDENT
+.INDENT 0.0
+.TP
.B +showbadcookie, +noshowbadcookie
This option toggles whether to show the message containing the
BADCOOKIE rcode before retrying the request or not. The default
--
2.40.1
```
# Detached signature
```gpg
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQS1rLeeEfG/f0nzK7hYUwVpYvFOWAUCZHH3EAAKCRBYUwVpYvFO
WOiHAP9uTERa4rrztKKeqk1TSLkqP5RgDnBbgxcbTkHAt5q7/wEAvffIjE5SUX8P
RpxZ9yS2geRmVXwyLDiS4FjxN3u7vgE=
=i92K
-----END PGP SIGNATURE-----
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4084auto-tune transfers-in, transfers-out, transfers-per-ns and friends2023-05-30T12:53:01ZCathy Almondauto-tune transfers-in, transfers-out, transfers-per-ns and friends### Description
The problem, as noted in [Support ticket #21991](https://support.isc.org/Ticket/Display.html?id=21991), is that without testing in a production environment and under specific circumstances (speed of network, configuratio...### Description
The problem, as noted in [Support ticket #21991](https://support.isc.org/Ticket/Display.html?id=21991), is that without testing in a production environment and under specific circumstances (speed of network, configuration of primaries per zone, reachability, rate of zone update propagation and so on), it's hard to know what sane values to give to the options for tuning zone transfers. The types of things that need to be optimised are:
- Speed of synchronisation/completion of refreshes following a secondary server restart
- Effective use of CPU resources so that servers are not idling while there is work that could be done
- No interruption to client services during zone refreshes (for servers that are currently client-facing)
- Effective onward zone update propagation/refreshes (for servers that are intermediaries in the zone update propagation path)
- Speed of propagation of zone updates during normal operation (i.e. not when restarting something...)
### Request
I'd like transfers-in, transfers-out, transfers-per-ns and friends to be able to auto-tune themselves based on knowledge of how the server is performing.
See other work currently ongoing:
#3883
#3914
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/keama/-/issues/11Fix keama's return code2023-09-18T10:28:27ZTomek MrugalskiFix keama's return codeAccording to `keama.8`:
> The number of conversion failures is returned.
This doesn't look like it's true. It returns the number of **successful** conversions. This has a major drawback - the return code, at least on Linux, is limited ...According to `keama.8`:
> The number of conversion failures is returned.
This doesn't look like it's true. It returns the number of **successful** conversions. This has a major drawback - the return code, at least on Linux, is limited to uint8. It would be better to return 0 on positive conversion and non-zero on failure.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/9Add new option type 'k' to keama parser2023-09-21T07:41:57ZThomas MarkwalderAdd new option type 'k' to keama parserdhcp#68 added a new option format type, this needs to be added to Keama.dhcp#68 added a new option format type, this needs to be added to Keama.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/3Update Keama option table2023-09-21T07:41:57ZFrancis DupontUpdate Keama option tableEach time a new option is supported by ISC DHCP or KEA the Keama option table must be updated.Each time a new option is supported by ISC DHCP or KEA the Keama option table must be updated.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/2Implement spawning classes (isc dhcp) => templates classes (kea) conversion2023-09-21T07:41:57ZTomek MrugalskiImplement spawning classes (isc dhcp) => templates classes (kea) conversionThe feature is now implemented. The last ticket about documentation for template classes (https://gitlab.isc.org/isc-projects/kea/-/issues/2606) will be released in upcoming Kea 2.3.3.
My belief is that subclasses can be handled in Kea ...The feature is now implemented. The last ticket about documentation for template classes (https://gitlab.isc.org/isc-projects/kea/-/issues/2606) will be released in upcoming Kea 2.3.3.
My belief is that subclasses can be handled in Kea as host reservations.
The other features - spawning classes - can now be handled with the template classes.4.5.1https://gitlab.isc.org/isc-projects/bind9/-/issues/4065Could query-source be made best-effort, not preventing startup in case of fai...2023-06-16T09:03:46ZPetr MenšíkCould query-source be made best-effort, not preventing startup in case of failure?### Description
Could be specification of outgoing addresses made non-fatal? Some users try to configure used outgoing address by named. But then they are surprised it creates problem during startup, because those addresses might not ye...### Description
Could be specification of outgoing addresses made non-fatal? Some users try to configure used outgoing address by named. But then they are surprised it creates problem during startup, because those addresses might not yet be available.
### Request
Could it be possible to specify ``query-source 10.1.2.3 optional;``, which would behave similar way to FREEBIND for listening sockets? If the socket could not be bound, just use whatever default address system provides. But try to use that address if that would work. It would allow also starting with not yet present addresses, which would appear later.
Alternative would be delaying root primining queries until listen-on machinery detects source address available. That seems a lot more complicated.
### Links / references
- https://bugzilla.redhat.com/show_bug.cgi?id=2195976https://gitlab.isc.org/isc-projects/bind9/-/issues/4057dig XDG basedir support2023-05-12T07:24:54ZPaul Töttermandig XDG basedir support### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htmlNot plannedhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/280format string report2023-04-20T08:11:52ZPeter Daviesformat string reportformat string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse...format string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse.c#L5611
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/keama/keama.c#L209
To reproduce these bugs on Ubuntu 22.04, you may follow these steps:
```
raptor@fnord:~$ cp /sbin/dhclient . # copy to local directory to bypass apparmor policy
raptor@fnord:~$ echo "include foo" > %n%n%n%n
raptor@fnord:~$ echo "include foo" > %x%x%x%x
raptor@fnord:~$ ./dhclient -cf %n%n%n%n # write to memory, caught by exploit mitigations
*** %n in writable segment detected ***
raptor@fnord:~$ ./dhclient -cf %x%x%x%x # read from memory, notice the leak in the syslog file
RTNETLINK answers: Operation not permitted
RTNETLINK answers: Operation not permitted
raptor@fnord:~$ grep "filename string expected" /var/log/syslog
Apr 7 19:28:01 fnord dhclient[5389]: 7cb92e0d7200 line 1: filename string expected.
```
I've just noticed ISC DHCP has recently reached EOL and I can't think of any scenario in which these bugs could be exploited in order to cross a security boundary. However, as format string bugs are a very powerful exploitation primitive, in my opinion they should be fixed in any case just to be careful.
Please let me know if you intend to issue a fix and/or request a CVE ID.
Regards,
--
Marco Ivaldi