Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 10/08/2021 14:53, Dominik wrote: > Hey Simon, > > various dnsmasq-2.86 test tags are around and it doesn't look like > there are any intermediate bugs around. The Pi-hole beta seems to have > attracted at least a few couple of dozen additional testers and nothing > seems to have come up here, either. > > How do you feel about tagging a v2.86 release? > > Best regards, > Dominik > > I've been accumulating patches for a couple of weeks, and started working through those tonight. None are very intrusive or controversial. Once those are done, I'll tag rc1. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 10/08/2021 23:11, Simon Kelley wrote: On 10/08/2021 14:53, Dominik wrote: Hey Simon, various dnsmasq-2.86 test tags are around and it doesn't look like there are any intermediate bugs around. The Pi-hole beta seems to have attracted at least a few couple of dozen additional testers and nothing seems to have come up here, either. How do you feel about tagging a v2.86 release? Best regards, Dominik I've been accumulating patches for a couple of weeks, and started working through those tonight. None are very intrusive or controversial. Once those are done, I'll tag rc1. I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are vague so far but ever since I've started DoT with stubby as upstream server, dnsmasq every now and then gets into a mode where it stops responding to request completely and just sits there using 100% cpu power on one core. I haven't found a way yet to trigger that reliably, but it feels like timing/parallel requests. Does that ring any bells? Any hints on how to get more relevant info on the situation? Sometimes it takes over a day, so verbose logs seem to be out of the question (since it's a small router). How to I get a backtrace without gdb? config created by OpenWrt: conf-file=/etc/dnsmasq.conf dhcp-authoritative domain-needed no-resolv localise-queries enable-ubus=dnsmasq expand-hosts bind-dynamic local-service quiet-dhcp edns-packet-max=1280 domain=internal local=/internal/ server=127.0.0.1#5453 addn-hosts=/tmp/hosts dhcp-leasefile=/tmp/dhcp.leases stop-dns-rebind conf-file=/usr/share/dnsmasq/trust-anchors.conf dnssec dhcp-broadcast=tag:needs-broadcast conf-dir=/tmp/dnsmasq.d user=dnsmasq group=dnsmasq dhcp-ignore-names=tag:dhcp_bogus_hostname conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf bogus-priv conf-file=/usr/share/dnsmasq/rfc6761.conf no-dhcp-interface=pppoe-wan dhcp-range=set:lan,192.168.0.200,192.168.0.254,255.255.255.0,12h stubby config created by OpenWrt: resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" trust_anchors_backoff_time: 2500 tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 1 listen_addresses: - 127.0.0.1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: - address_data: 5.1.66.255 tls_auth_name: "dot.ffmuc.net" - address_data: 185.150.99.255 tls_auth_name: "dot.ffmuc.net" - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hi Andre, This is curious ‘cos I’ve just been running 2.88test6 for the past 28 days (I was away in Japan for a month and was banned from touching the openwrt router whilst I was away) with stubby without any problems. My stubby config is different: # Autogenerated configuration from uci data resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/etc/stubby" trust_anchors_backoff_time: 2500 tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 1 listen_addresses: - 127.0.0.1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: - address_data: 2606:4700:4700:: tls_auth_name: "cloudflare-dns.com" - address_data: 2606:4700:4700::1001 tls_auth_name: "cloudflare-dns.com" - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" - address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com” and my dnsmasq config is wildly different, so I’m not sure looking for differences in config is going to help, although I note I don’t validate dnssec instead trusting my upstreams to do it. Try installing & using ’strace’ on the errant dnsmasq to get a flavour of what it’s doing syscall wise, hopefully that will give some clues whilst the clever people on this list come up with better suggestions. An additional idea, enable ‘log-queries’, an idea of the last queries handled by dnsmasq before it goes AWOL might reveal a pattern. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hey Andre, On Wed, 2021-08-11 at 08:36 +0200, Andre Heider wrote: > How to I get a backtrace without gdb? Maybe running the much smaller gdbserver on the router can be a solution. gdb itself would be running in another (more beefy) computer. Have a look here https://openwrt.org/docs/guide-developer/gdb I don't know feasible this solution would be for you. Best, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 11/08/2021 10:13, Dominik wrote: Hey Andre, On Wed, 2021-08-11 at 08:36 +0200, Andre Heider wrote: How to I get a backtrace without gdb? Maybe running the much smaller gdbserver on the router can be a solution. gdb itself would be running in another (more beefy) computer. Have a look here https://openwrt.org/docs/guide-developer/gdb I don't know feasible this solution would be for you. Nice, thanks! It's up and running, now it has to trigger... ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hi Andre, et al. > On Aug 11, 2021, at 1:36 AM, Andre Heider wrote: > > I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are > vague so far but ever since I've started DoT with stubby as upstream server, > dnsmasq every now and then gets into a mode where it stops responding to > request completely and just sits there using 100% cpu power on one core. > I haven't found a way yet to trigger that reliably, but it feels like > timing/parallel requests. > > Does that ring any bells? Our project experienced a similar issue (pre-2021) when we used dnsmasq->stubby for DoT, at the time we were using dnsmasq 2.82 and getdns/stubby 1.5.2/0.2.6. The issue was upstream DNS would randomly "stall", it could be a couple days, a week or a month before the "stall" reoccured. The DoT provider also seemed to make a difference ... for example it stalled more often with Quad9 than with Cloudflare. Keeping all things equal, we tested using unbound 1.13.0 (now 1.13.1) configured only as a DoT forwarder (forward-zone:) replacing getdns/stubby and the random stalls no longer occurred. This dnsmasq->unbound(DoT) is now our production implementation for upstream DoT. Side notes: 1) Our project used libunbound previously, so building the extra unbound daemon added about the same amount of code as the removed getdns/stubby code. 2) As of unbound 1.13.0, its DoT features are on par with stubby, ex. stream reuse and tcp fast open. 3) Our default DNS is provided by dnsmasq, only upstream DoT users start the unbound daemon. 4) Additionally, getdns/stubby dropping autotools (in favor of cmake) was a thorn in my paw. I personally use dnsmasq->unbound(DoT) and no issues since dropping getdns/stubby at the end of 2020. Lonnie ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 11/08/2021 16:10, Lonnie Abelbeck wrote: Hi Andre, et al. On Aug 11, 2021, at 1:36 AM, Andre Heider wrote: I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are vague so far but ever since I've started DoT with stubby as upstream server, dnsmasq every now and then gets into a mode where it stops responding to request completely and just sits there using 100% cpu power on one core. I haven't found a way yet to trigger that reliably, but it feels like timing/parallel requests. Does that ring any bells? Our project experienced a similar issue (pre-2021) when we used dnsmasq->stubby for DoT, at the time we were using dnsmasq 2.82 and getdns/stubby 1.5.2/0.2.6. The issue was upstream DNS would randomly "stall", it could be a couple days, a week or a month before the "stall" reoccured. The DoT provider also seemed to make a difference ... for example it stalled more often with Quad9 than with Cloudflare. Yeah, maybe. But I've also tried dnsproxy instead of stubby, same hangs (but same DoT upstreams). If the hangs occurs and I restart either of those, it doesn't fix itself, dnsmasq still hogs the cpu. If I leave stubby or dnsproxy as-is and restart dnsmasq it works again. Keeping all things equal, we tested using unbound 1.13.0 (now 1.13.1) configured only as a DoT forwarder (forward-zone:) replacing getdns/stubby and the random stalls no longer occurred. This dnsmasq->unbound(DoT) is now our production implementation for upstream DoT. Side notes: 1) Our project used libunbound previously, so building the extra unbound daemon added about the same amount of code as the removed getdns/stubby code. 2) As of unbound 1.13.0, its DoT features are on par with stubby, ex. stream reuse and tcp fast open. 3) Our default DNS is provided by dnsmasq, only upstream DoT users start the unbound daemon. 4) Additionally, getdns/stubby dropping autotools (in favor of cmake) was a thorn in my paw. I personally use dnsmasq->unbound(DoT) and no issues since dropping getdns/stubby at the end of 2020. Lonnie ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hi there, On 11/08/2021 09:45, Kevin Darbyshire-Bryant wrote: Hi Andre, This is curious ‘cos I’ve just been running 2.88test6 for the past 28 days (I was away in Japan for a month and was banned from touching the openwrt router whilst I was away) with stubby without any problems. My stubby config is different: # Autogenerated configuration from uci data resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/etc/stubby" trust_anchors_backoff_time: 2500 tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 1 listen_addresses: - 127.0.0.1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: - address_data: 2606:4700:4700:: tls_auth_name: "cloudflare-dns.com" - address_data: 2606:4700:4700::1001 tls_auth_name: "cloudflare-dns.com" - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" - address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com” hint from the other thread: Can you trigger the issue when using my stubby DoT upstreams? and my dnsmasq config is wildly different, so I’m not sure looking for differences in config is going to help, although I note I don’t validate dnssec instead trusting my upstreams to do it. Try installing & using ’strace’ on the errant dnsmasq to get a flavour of what it’s doing syscall wise, hopefully that will give some clues whilst the clever people on this list come up with better suggestions. An additional idea, enable ‘log-queries’, an idea of the last queries handled by dnsmasq before it goes AWOL might reveal a pattern. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 11/08/2021 16:19, Andre Heider wrote:
Hi there,
it seems I can trigger this semi-reliably while powering up 2 KVM
windows instances in parallel.
This is the tail of log-queries:
dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
dnsmasq[6591]: query[] foo.internal from 192.168.0.foo
dnsmasq[6591]: config foo.internal is NODATA-IPv6
dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo
And this is where dnsmasq stop replying altogether and hogs the cpu.
Note that foo.internal is the kvm host with the ip 192.168.0.foo.
Using gdbserver doesn't yield too much info, looks like because of lto
maybe (which OpenWrt does for dnsmasq)?
(gdb) info threads
Id Target Id Frame
* 1 Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
(gdb) bt full
#0 0x555715f1 in forward_query.lto_priv ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Without LTO, another hang with the last log-queries 'dnsmasq[6842]:
query[A] ipv4only.arpa from 192.168.0.foo' again:
#0 0x55568969 in forward_query (udpfd=,
udpaddr=0x7fffbab8, dst_addr=0x7fffbaa8, dst_iface=15,
header=0x5561c080, plen=31, limit=0x5561c280 "", now=958007,
forward=0x5563e8e0, ad_reqd=0, do_bit=0) at forward.c:319
is_sign = 1432469663
pheader = 0x0
flags = 0
fwd_flags =
is_dnssec = 0
master =
gotname = 128
hash = 0x55624a10
oph = 0x0
old_src =
first = 1432469663
last = 12
start = 0
subnet = 0
cacheable = 1431977952
forwarded = 0
edns0_len = 1431725623
pheader = 0x80088
ede = -1
#1 0x5556947d in receive_query (listen=0x5561f5c0, now=958007) at
forward.c:1640
ad_reqd = 0
header = 0x5561c080
source_addr = {sa = {sa_family = 2, sa_data =
"\306d\300\250\000(\000\000\000\000\000\000\000"}, in = {sin_family = 2,
sin_port = 50788, sin_addr = {s_addr = 3232235560}, sin_zero =
"\000\000\000\000\000\000\000"}, in6 = {sin6_family = 2, sin6_port =
50788, sin6_flowinfo = 3232235560, sin6_addr = {
__in6_union = {__s6_addr =
"\000\000\000\000\000\000\000\000\000\000\001Ww\347", sequence \360>, __s6_addr16 = {0, 0, 0, 0, 0, 343, 30695, 3824},
__s6_addr32 = {0, 0, 343, 2011631344}}}, sin6_scope_id = 8162}}
pheader = 0x7fffbb68 "UZ?\340w\373+x"
type = 1
udp_size =
dst_addr = {addr4 = {s_addr = 3232235521}, addr6 = {__in6_union
= {__s6_addr =
"\300\250\000\001a\023\340\345\000\004\024\231w\354\066\240",
__s6_addr16 = {49320, 1, 24851, 57573, 4, 5273, 30700, 13984},
__s6_addr32 = {3232235521, 1628692709, 267417, 2011969184}}}, cname =
{target = {cache = 0xc0a80001,
name = 0xc0a80001 0xc0a80001>}, uid = 1628692709, is_name_ptr = 267417}, key = {keydata =
0xc0a80001, keylen = 24851, flags = 57573, keytag = 4, algo = 20
'\024'}, ds = {keydata = 0xc0a80001, keylen = 24851, keytag = 57573,
algo = 0 '\000', digest = 4 '\004'},
srv = {target = 0xc0a80001, targetlen = 24851, srvport =
57573, priority = 4, weight = 5273}, log = {keytag = 49320, algo = 1,
digest = 24851, rcode = 57573, ede = 267417}}
netmask = {s_addr = }
dst_addr_4 = {s_addr = 3232235521}
m = 0
n = 31
if_index = 15
auth_dns = 0
do_bit = 0
have_pseudoheader = 0
mark = 0
have_mark = 0
is_single_query =
allowed =
local_auth =
iov = {{iov_base = 0x5561c080, iov_len = 1280}}
msg = {msg_name = 0x7fffbab8, msg_namelen = 16, msg_iov =
0x7fffbaa0, msg_iovlen = 1, msg_control = 0x7fffbad4, msg_controllen =
24, msg_flags = 0}
cmptr =
control_u = {align = {cmsg_len = 24, cmsg_level = 0, cmsg_type
= 8}, control6 =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001\000\000\000\030\000\000\000",
control =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001"}
family =
check_dst =
#2 0x5556c853 in check_dns_listeners (now=) at
dnsmasq.c:1802
serverfdp =
listener = 0x5561f5c0
rfl =
i =
pipefd = {1431977952, 2012949368}
#3 0x70f9 in main (argc=, argv=) at
dnsmasq.c:1229
timeout =
bind_fallback = 0
now = 958007
sigact = {__sa_handler = {sa_handler = 0x1, sa_sigaction =
0x1}, sa_mask = {__bits = {0, 0, 0, 0, 0, 2013266592, 17788, 2013238320,
2013238324, 2013245196, 4, 0, 80, 0, 2012700248, 2012708864, 2013167616,
2013233152, 2013237244, 0, 691091872, 2013233152, 4, 2147466580,
1431657089, 2013091140, 2013086164,
2013165476, 0, 0, 2013095836, 15630}}, sa_flags = 0,
sa_restorer = 0x22358}
if_tmp =
piperead = 24
pipefd = {
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hi there, it seems I can trigger this semi-reliably while powering up 2 KVM windows instances in parallel. This is the tail of log-queries: dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo dnsmasq[6591]: query[] foo.internal from 192.168.0.foo dnsmasq[6591]: config foo.internal is NODATA-IPv6 dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo And this is where dnsmasq stop replying altogether and hogs the cpu. Note that foo.internal is the kvm host with the ip 192.168.0.foo. Using gdbserver doesn't yield too much info, looks like because of lto maybe (which OpenWrt does for dnsmasq)? (gdb) info threads Id Target Id Frame * 1Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv () (gdb) bt full #0 0x555715f1 in forward_query.lto_priv () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) Does that help, maybe? Regards, Andre On 11/08/2021 08:36, Andre Heider wrote: On 10/08/2021 23:11, Simon Kelley wrote: On 10/08/2021 14:53, Dominik wrote: Hey Simon, various dnsmasq-2.86 test tags are around and it doesn't look like there are any intermediate bugs around. The Pi-hole beta seems to have attracted at least a few couple of dozen additional testers and nothing seems to have come up here, either. How do you feel about tagging a v2.86 release? Best regards, Dominik I've been accumulating patches for a couple of weeks, and started working through those tonight. None are very intrusive or controversial. Once those are done, I'll tag rc1. I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are vague so far but ever since I've started DoT with stubby as upstream server, dnsmasq every now and then gets into a mode where it stops responding to request completely and just sits there using 100% cpu power on one core. I haven't found a way yet to trigger that reliably, but it feels like timing/parallel requests. Does that ring any bells? Any hints on how to get more relevant info on the situation? Sometimes it takes over a day, so verbose logs seem to be out of the question (since it's a small router). How to I get a backtrace without gdb? config created by OpenWrt: conf-file=/etc/dnsmasq.conf dhcp-authoritative domain-needed no-resolv localise-queries enable-ubus=dnsmasq expand-hosts bind-dynamic local-service quiet-dhcp edns-packet-max=1280 domain=internal local=/internal/ server=127.0.0.1#5453 addn-hosts=/tmp/hosts dhcp-leasefile=/tmp/dhcp.leases stop-dns-rebind conf-file=/usr/share/dnsmasq/trust-anchors.conf dnssec dhcp-broadcast=tag:needs-broadcast conf-dir=/tmp/dnsmasq.d user=dnsmasq group=dnsmasq dhcp-ignore-names=tag:dhcp_bogus_hostname conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf bogus-priv conf-file=/usr/share/dnsmasq/rfc6761.conf no-dhcp-interface=pppoe-wan dhcp-range=set:lan,192.168.0.200,192.168.0.254,255.255.255.0,12h stubby config created by OpenWrt: resolution_type: GETDNS_RESOLUTION_STUB round_robin_upstreams: 1 appdata_dir: "/var/lib/stubby" trust_anchors_backoff_time: 2500 tls_authentication: GETDNS_AUTHENTICATION_REQUIRED tls_query_padding_blocksize: 128 edns_client_subnet_private: 1 idle_timeout: 1 listen_addresses: - 127.0.0.1@5453 dns_transport_list: - GETDNS_TRANSPORT_TLS upstream_recursive_servers: - address_data: 5.1.66.255 tls_auth_name: "dot.ffmuc.net" - address_data: 185.150.99.255 tls_auth_name: "dot.ffmuc.net" - address_data: 185.95.218.42 tls_auth_name: "dns.digitale-gesellschaft.ch" - address_data: 185.95.218.43 tls_auth_name: "dns.digitale-gesellschaft.ch" ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hey Andre,
On Wed, 2021-08-11 at 16:50 +0200, Andre Heider wrote:
> Continuing and breaking again about 30 times mostly yields line 319 as
> above (which is 'difftime(now, master->forwardtime) > FORWARD_TIME ||')
>
> A few times it hits 341 though ('while (forward->blocking_query)'):
Do you have a chance to run latest master code or are you bound to test
tags on your system?
I don't (yet) think there is a loop going nuts, could you add a
breakpoint to the call to forward_query() in receive_query() and check
if the function is just repeatedly called? And, if so, do it one
further level down in the backtrace (break in check_dns_listeners()
where receive_query() is called, etc.) so we can see where the issue
is.
When you got the right one, there should be no CPU core spinning as you
will always end up in the breakpoint immediately.
Best,
Dominik
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
This is useful information, but the backtraces are puzzling: the code
isn't in tight loop, certainly.
I wonder if the v4only.arpa thing is not a coincidence?
Some things to try, please.
1) When the dnsmasq process is faulted, run
strace -p
2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case
that's the whole trigger.
3) Same but straight to stubby
dig @127.0.0.1 -p 5453 ipv4only.arpa
4) Take a look in /usr/share/dnsmasq/rfc6761.conf
Is .arpa mentioned in there?
Cheers,
Simon.
On 11/08/2021 15:50, Andre Heider wrote:
> On 11/08/2021 16:19, Andre Heider wrote:
>> Hi there,
>>
>> it seems I can trigger this semi-reliably while powering up 2 KVM
>> windows instances in parallel.
>>
>> This is the tail of log-queries:
>> dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
>> dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
>> dnsmasq[6591]: query[] foo.internal from 192.168.0.foo
>> dnsmasq[6591]: config foo.internal is NODATA-IPv6
>> dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo
>>
>> And this is where dnsmasq stop replying altogether and hogs the cpu.
>> Note that foo.internal is the kvm host with the ip 192.168.0.foo.
>>
>> Using gdbserver doesn't yield too much info, looks like because of lto
>> maybe (which OpenWrt does for dnsmasq)?
>> (gdb) info threads
>> Id Target Id Frame
>> * 1 Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
>> (gdb) bt full
>> #0 0x555715f1 in forward_query.lto_priv ()
>> No symbol table info available.
>> Backtrace stopped: previous frame identical to this frame (corrupt
>> stack?)
>
> Without LTO, another hang with the last log-queries 'dnsmasq[6842]:
> query[A] ipv4only.arpa from 192.168.0.foo' again:
>
> #0 0x55568969 in forward_query (udpfd=,
> udpaddr=0x7fffbab8, dst_addr=0x7fffbaa8, dst_iface=15,
> header=0x5561c080, plen=31, limit=0x5561c280 "", now=958007,
> forward=0x5563e8e0, ad_reqd=0, do_bit=0) at forward.c:319
> is_sign = 1432469663
> pheader = 0x0
> flags = 0
> fwd_flags =
> is_dnssec = 0
> master =
> gotname = 128
> hash = 0x55624a10
> oph = 0x0
> old_src =
> first = 1432469663
> last = 12
> start = 0
> subnet = 0
> cacheable = 1431977952
> forwarded = 0
> edns0_len = 1431725623
> pheader = 0x80088
> ede = -1
> #1 0x5556947d in receive_query (listen=0x5561f5c0, now=958007) at
> forward.c:1640
> ad_reqd = 0
> header = 0x5561c080
> source_addr = {sa = {sa_family = 2, sa_data =
> "\306d\300\250\000(\000\000\000\000\000\000\000"}, in = {sin_family = 2,
> sin_port = 50788, sin_addr = {s_addr = 3232235560}, sin_zero =
> "\000\000\000\000\000\000\000"}, in6 = {sin6_family = 2, sin6_port =
> 50788, sin6_flowinfo = 3232235560, sin6_addr = {
> __in6_union = {__s6_addr =
> "\000\000\000\000\000\000\000\000\000\000\001Ww\347", sequence \360>, __s6_addr16 = {0, 0, 0, 0, 0, 343, 30695, 3824},
> __s6_addr32 = {0, 0, 343, 2011631344}}}, sin6_scope_id = 8162}}
> pheader = 0x7fffbb68 "UZ?\340w\373+x"
> type = 1
> udp_size =
> dst_addr = {addr4 = {s_addr = 3232235521}, addr6 = {__in6_union
> = {__s6_addr =
> "\300\250\000\001a\023\340\345\000\004\024\231w\354\066\240",
> __s6_addr16 = {49320, 1, 24851, 57573, 4, 5273, 30700, 13984},
> __s6_addr32 = {3232235521, 1628692709, 267417, 2011969184}}}, cname =
> {target = {cache = 0xc0a80001,
> name = 0xc0a80001 0xc0a80001>}, uid = 1628692709, is_name_ptr = 267417}, key = {keydata =
> 0xc0a80001, keylen = 24851, flags = 57573, keytag = 4, algo = 20
> '\024'}, ds = {keydata = 0xc0a80001, keylen = 24851, keytag = 57573,
> algo = 0 '\000', digest = 4 '\004'},
> srv = {target = 0xc0a80001, targetlen = 24851, srvport =
> 57573, priority = 4, weight = 5273}, log = {keytag = 49320, algo = 1,
> digest = 24851, rcode = 57573, ede = 267417}}
> netmask = {s_addr = }
> dst_addr_4 = {s_addr = 3232235521}
> m = 0
> n = 31
> if_index = 15
> auth_dns = 0
> do_bit = 0
> have_pseudoheader = 0
> mark = 0
> have_mark = 0
> is_single_query =
> allowed =
> local_auth =
> iov = {{iov_base = 0x5561c080, iov_len = 1280}}
> msg = {msg_name = 0x7fffbab8, msg_namelen = 16, msg_iov =
> 0x7fffbaa0, msg_iovlen = 1, msg_control = 0x7fffbad4, msg_controllen =
> 24, msg_flags = 0}
> cmptr =
> control_u = {align = {cmsg_len = 24, cmsg_level = 0, cmsg_type =
> 8}, control6 =
> "\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001\000\000\000\030\000\000\000",
>
> control =
> "\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001"}
>
> family =
> check_dst =
> #2 0x5556c853 in c
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 09:50, Dominik wrote: > Hey Andre, > > Do you have a chance to run latest master code or are you bound to test > tags on your system? I just tagged the latest code as 2.86test7, in case that helps. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
> On 12 Aug 2021, at 10:06, Simon Kelley wrote: > > This is useful information, but the backtraces are puzzling: the code > isn't in tight loop, certainly. > > > I wonder if the v4only.arpa thing is not a coincidence? > > Some things to try, please. > > 1) When the dnsmasq process is faulted, run > > strace -p > > 2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case > that's the whole trigger. > > 3) Same but straight to stubby > > dig @127.0.0.1 -p 5453 ipv4only.arpa > > > 4) Take a look in /usr/share/dnsmasq/rfc6761.conf > > Is .arpa mentioned in there? For reference, the default content is # RFC6761 included configuration file for dnsmasq # # includes a list of domains that should not be forwarded to Internet name servers # to reduce burden on them, asking questions that they won't know the answer to. server=/bind/ server=/invalid/ server=/local/ server=/localhost/ server=/onion/ server=/test/ I wrote it :-) Kevin signature.asc Description: Message signed with OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 11:34, Andre Heider wrote: > On 12/08/2021 11:33, Simon Kelley wrote: >> >> >> On 12/08/2021 09:50, Dominik wrote: >>> Hey Andre, >>> >> >>> Do you have a chance to run latest master code or are you bound to test >>> tags on your system? >> >> I just tagged the latest code as 2.86test7, in case that helps. > > It may? But your httpd seems down, at least for me? > Working here, and no evidence of problems in the logs. Are you still seeing errors? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 11:06, Simon Kelley wrote:
This is useful information, but the backtraces are puzzling: the code
isn't in tight loop, certainly.
I wonder if the v4only.arpa thing is not a coincidence?
Some things to try, please.
1) When the dnsmasq process is faulted, run
strace -p
Will do, so far I haven't been able to reproduce the issue today...
2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case
that's the whole trigger.
3) Same but straight to stubby
dig @127.0.0.1 -p 5453 ipv4only.arpa
Both work just fine, so maybe that was just a red herring.
4) Take a look in /usr/share/dnsmasq/rfc6761.conf
Is .arpa mentioned in there?
Nope, it's the default file as Kevin pasted
Cheers,
Simon.
On 11/08/2021 15:50, Andre Heider wrote:
On 11/08/2021 16:19, Andre Heider wrote:
Hi there,
it seems I can trigger this semi-reliably while powering up 2 KVM
windows instances in parallel.
This is the tail of log-queries:
dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
dnsmasq[6591]: query[] foo.internal from 192.168.0.foo
dnsmasq[6591]: config foo.internal is NODATA-IPv6
dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo
And this is where dnsmasq stop replying altogether and hogs the cpu.
Note that foo.internal is the kvm host with the ip 192.168.0.foo.
Using gdbserver doesn't yield too much info, looks like because of lto
maybe (which OpenWrt does for dnsmasq)?
(gdb) info threads
Id Target Id Frame
* 1 Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
(gdb) bt full
#0 0x555715f1 in forward_query.lto_priv ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
Without LTO, another hang with the last log-queries 'dnsmasq[6842]:
query[A] ipv4only.arpa from 192.168.0.foo' again:
#0 0x55568969 in forward_query (udpfd=,
udpaddr=0x7fffbab8, dst_addr=0x7fffbaa8, dst_iface=15,
header=0x5561c080, plen=31, limit=0x5561c280 "", now=958007,
forward=0x5563e8e0, ad_reqd=0, do_bit=0) at forward.c:319
is_sign = 1432469663
pheader = 0x0
flags = 0
fwd_flags =
is_dnssec = 0
master =
gotname = 128
hash = 0x55624a10
oph = 0x0
old_src =
first = 1432469663
last = 12
start = 0
subnet = 0
cacheable = 1431977952
forwarded = 0
edns0_len = 1431725623
pheader = 0x80088
ede = -1
#1 0x5556947d in receive_query (listen=0x5561f5c0, now=958007) at
forward.c:1640
ad_reqd = 0
header = 0x5561c080
source_addr = {sa = {sa_family = 2, sa_data =
"\306d\300\250\000(\000\000\000\000\000\000\000"}, in = {sin_family = 2,
sin_port = 50788, sin_addr = {s_addr = 3232235560}, sin_zero =
"\000\000\000\000\000\000\000"}, in6 = {sin6_family = 2, sin6_port =
50788, sin6_flowinfo = 3232235560, sin6_addr = {
__in6_union = {__s6_addr =
"\000\000\000\000\000\000\000\000\000\000\001Ww\347", , __s6_addr16 = {0, 0, 0, 0, 0, 343, 30695, 3824},
__s6_addr32 = {0, 0, 343, 2011631344}}}, sin6_scope_id = 8162}}
pheader = 0x7fffbb68 "UZ?\340w\373+x"
type = 1
udp_size =
dst_addr = {addr4 = {s_addr = 3232235521}, addr6 = {__in6_union
= {__s6_addr =
"\300\250\000\001a\023\340\345\000\004\024\231w\354\066\240",
__s6_addr16 = {49320, 1, 24851, 57573, 4, 5273, 30700, 13984},
__s6_addr32 = {3232235521, 1628692709, 267417, 2011969184}}}, cname =
{target = {cache = 0xc0a80001,
name = 0xc0a80001 }, uid = 1628692709, is_name_ptr = 267417}, key = {keydata =
0xc0a80001, keylen = 24851, flags = 57573, keytag = 4, algo = 20
'\024'}, ds = {keydata = 0xc0a80001, keylen = 24851, keytag = 57573,
algo = 0 '\000', digest = 4 '\004'},
srv = {target = 0xc0a80001, targetlen = 24851, srvport =
57573, priority = 4, weight = 5273}, log = {keytag = 49320, algo = 1,
digest = 24851, rcode = 57573, ede = 267417}}
netmask = {s_addr = }
dst_addr_4 = {s_addr = 3232235521}
m = 0
n = 31
if_index = 15
auth_dns = 0
do_bit = 0
have_pseudoheader = 0
mark = 0
have_mark = 0
is_single_query =
allowed =
local_auth =
iov = {{iov_base = 0x5561c080, iov_len = 1280}}
msg = {msg_name = 0x7fffbab8, msg_namelen = 16, msg_iov =
0x7fffbaa0, msg_iovlen = 1, msg_control = 0x7fffbad4, msg_controllen =
24, msg_flags = 0}
cmptr =
control_u = {align = {cmsg_len = 24, cmsg_level = 0, cmsg_type =
8}, control6 =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001\000\000\000\030\000\000\000",
control =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001"}
family =
check_dst =
#2 0x5
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 12:58, Simon Kelley wrote: On 12/08/2021 11:34, Andre Heider wrote: On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? Working here, and no evidence of problems in the logs. Are you still seeing errors? Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 13:17, Andre Heider wrote: On 12/08/2021 12:58, Simon Kelley wrote: On 12/08/2021 11:34, Andre Heider wrote: On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? Working here, and no evidence of problems in the logs. Are you still seeing errors? Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 It works with dnssec enabled but 'ednspacket_max 1280' removed... ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 10:48, Kevin Darbyshire-Bryant wrote: > > # RFC6761 included configuration file for dnsmasq > # > # includes a list of domains that should not be forwarded to Internet name > servers > # to reduce burden on them, asking questions that they won't know the answer > to. > > server=/bind/ > server=/invalid/ > server=/local/ > server=/localhost/ > server=/onion/ > server=/test/ > > I wrote it :-) > That's what I see on my systems. I just wondered of arpa had got in there on Andre's. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 12:23, Andre Heider wrote: >> Hm, works if I disable dnssec on dnsmask: >> >> dig thekelleys.org.uk >> >> ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 1280 >> ;; QUESTION SECTION: >> ;thekelleys.org.uk. IN A >> >> ;; ANSWER SECTION: >> thekelleys.org.uk. 36717 IN A 85.119.82.65 >> >> ;; Query time: 3 msec >> ;; SERVER: 192.168.0.1#53(192.168.0.1) >> ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 >> ;; MSG SIZE rcvd: 62 >> >> >> But with it enabled: >> >> dig thekelleys.org.uk >> ;; Truncated, retrying in TCP mode. >> >> ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; EDE: 14 (Not Ready) >> ;; QUESTION SECTION: >> ;thekelleys.org.uk. IN A >> >> ;; Query time: 7 msec >> ;; SERVER: 192.168.0.1#53(192.168.0.1) >> ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 >> ;; MSG SIZE rcvd: 52 > > It works with dnssec enabled but 'ednspacket_max 1280' removed... > This may be getting closer to the original problem. What do the query logs look like when that fails? Also is stubby handling queries on TCP OK? dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 13:34, Simon Kelley wrote: On 12/08/2021 12:23, Andre Heider wrote: Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 It works with dnssec enabled but 'ednspacket_max 1280' removed... This may be getting closer to the original problem. What do the query logs look like when that fails? Also is stubby handling queries on TCP OK? dnsmasq[20540]: query[A] thekelleys.org.uk from 192.168.0.40 dnsmasq[20540]: forwarded thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DS] uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] . to 127.0.0.1 dnsmasq[20540]: reply . is DNSKEY keytag 26838, algo 8 dnsmasq[20540]: reply . is DNSKEY keytag 20326, algo 8 dnsmasq[20540]: reply uk is DS keytag 43876, algo 8, digest 2 dnsmasq[20540]: dnssec-query[DS] org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] uk to 127.0.0.1 dnsmasq[20540]: reply uk is DNSKEY keytag 43056, algo 8 dnsmasq[20540]: reply uk is DNSKEY keytag 43876, algo 8 dnsmasq[20540]: reply org.uk is DS keytag 41523, algo 8, digest 2 dnsmasq[20540]: dnssec-query[DS] thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] org.uk to 127.0.0.1 dnsmasq[20540]: reply org.uk is DNSKEY keytag 41523, algo 8 dnsmasq[20540]: reply thekelleys.org.uk is DS keytag 60318, algo 10, digest 2 dnsmasq[20540]: reply thekelleys.org.uk is DS keytag 7713, algo 10, digest 2 dnsmasq[20540]: dnssec-query[DNSKEY] thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: reply thekelleys.org.uk is 85.119.82.65 dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk ; <<>> DiG 9.17.13 <<>> @127.0.0.1 -p 5453 +vc thekelleys.org.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9671 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 34162 IN A 85.119.82.65 ;; Query time: 170 msec ;; SERVER: 127.0.0.1#5453(127.0.0.1) (TCP) ;; WHEN: Thu Aug 12 13:55:03 CEST 2021 ;; MSG SIZE rcvd: 62 To be honest I'm not sure why I added --edns-packet-max=1280. It may have been just because of dnsmasq logging about reducing packet sizes to syslog over and over again? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 13:34, Simon Kelley wrote: On 12/08/2021 12:23, Andre Heider wrote: It works with dnssec enabled but 'ednspacket_max 1280' removed... This may be getting closer to the original problem. What do the query logs look like when that fails? Also is stubby handling queries on TCP OK? dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk For the record: I updated to 2.86test7 a week ago too, removed 'ednspacket_max 1280' and haven't seen a single failure yet. That's unusual, sometimes it took a day or two, but never a full week. So it looks like it was either fixed or that option is the culprit? Cheers, Andre ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 19/08/2021 10:01, Andre Heider wrote: > On 12/08/2021 13:34, Simon Kelley wrote: >> On 12/08/2021 12:23, Andre Heider wrote: >>> It works with dnssec enabled but 'ednspacket_max 1280' removed... >>> >> This may be getting closer to the original problem. What do the query >> logs look like when that fails? Also is stubby handling queries on TCP >> OK? >> >> dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk > > For the record: > > I updated to 2.86test7 a week ago too, removed 'ednspacket_max 1280' and > haven't seen a single failure yet. That's unusual, sometimes it took a > day or two, but never a full week. > > So it looks like it was either fixed or that option is the culprit? > > Cheers, > Andre > Thanks for the update. I think that's enough to make me happy to make a 2.86 release candidate, to get back to the original subject of this thread. In the event that there's a real problem lurking still that will probably find it :( Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
