Re: [Dnsmasq-discuss] trouble with host resolution
Never mind, I found the mistake: I forgot to put the "search" in resolv.conf: search prager.homeip.net On 11/20/24 2:08 PM, Bernd Prager wrote: I am running dnsmasq version 2.90 with following configuration:""" domain-needed bogus-priv no-resolv no-poll server=8.8.8.8 server=8.8.4.4 server=1.1.1.1 bind-dynamic domain=prager.homeip.net expand-hosts dhcp-range=192.168.1.120,192.168.1.200,12h dhcp-option=option:router,192.168.1.1 dhcp-option=option:ntp-server,129.6.15.28,128.138.141.172 dhcp-leasefile=/var/lib/dhcp/dnsmasq.leases dhcp-authoritative cache-size=2048 listen-address=192.168.1.2 dhcp-host=40:F0:2F:23:8F:A1,fenrir,192.168.1.2,12h dhcp-host=ec:d6:8a:16:8c:bc,fenrir,192.168.1.106,12h dhcp-host=24:5E:BE:4C:A1:9F,saga,192.168.1.6,12h ... (more hosts) ... """ "fenrir" (192.168.1.3) is the host where dnsmasq is running. I am having trouble resolving the hosts:""" ❯ host saga.prager.homeip.net saga.prager.homeip.net has address 192.168.1.6 saga.prager.homeip.net is an alias for prager.homeip.net. saga.prager.homeip.net is an alias for prager.homeip.net. ❯ resolvectl query saga.prager.homeip.net saga.prager.homeip.net: 76.175.52.6 -- link: enp2s0 (prager.homeip.net) -- Information acquired via protocol DNS in 6.8ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: cache network ❯ ping saga ping: saga: Name or service not known """ The 'host' command is resolving "saga" correctly, but 'resolvectl' gets me the external IP address of my network. Could somebody please tell me what I am missing? My '/etc/resolve.conf' is just """ # Home nameserver 192.168.1.2 # Cloudflare nameserver 1.1.1.1 # Google nameserver 8.8.8.8 """ Thank you for any help. -- Bernd ___ 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] [PATCH 1/1] forward.c: fix handling of truncated response
On 10/2/24 17:00, Dominik Derigs via Dnsmasq-discuss wrote: Hey all, having this configurable makes sense particularly thinking about the multitude of IoT devices often receiving not all that much attention from their manufacturers. A particular example is the camera Tapo C-310 which seems to be widely used and has often been reported in the Pi-hole forums to cause a huge amount of queries due to exactly this truncation method we are talking about here (when dnsmasq is used with DNSSEC, the query A time.nist.gov results in truncation). Said Tapo camera is not behaving nicely and does not retry over TCP. Instead, it retries the same query roughly one second later, resulting in a whooping 86,400 identical queries, all being truncated. A workaround is querying this domain periodically manually over TCP but it is a rather ugly workaround. If there would be an option to allow truncated content to remain, I would indeed find it very useful for situations like the one mentioned above. I confirmed that the camera could successfully reads the returned CNAME/A record. This is what I got when simply applying the submitted patch (but keeping the logging): Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 query[A] time.nist.gov from 127.0.0.1 Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 forwarded time.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 26 dnssec-query[DS] gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 26 reply gov is DS for keytag 2536, algo 13, digest 2 Oct 2 17:46:53 dnsmasq[1861633]: 27 dnssec-query[DS] nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 28 dnssec-query[DNSKEY] gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag 2536, algo 13 Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag 35496, algo 13 Oct 2 17:46:53 dnsmasq[1861633]: 27 reply nist.gov is DS for keytag 33751, algo 8, digest 2 Oct 2 17:46:53 dnsmasq[1861633]: 29 dnssec-query[DNSKEY] nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY keytag 18303, algo 8 Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY keytag 33751, algo 8 Oct 2 17:46:53 dnsmasq[1861633]: 30 dnssec-query[DS] glb.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for keytag 56235, algo 7, digest 1 Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for keytag 4395, algo 7, digest 1 Oct 2 17:46:53 dnsmasq[1861633]: 31 dnssec-query[DNSKEY] glb.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 31 reply glb.nist.gov is truncated[DNSKEY] Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 validation result is TRUNCATED Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 reply is truncated For testing, "dig +ignore + notcp time.nist.gov" is handy as it is guaranteed to be truncated with dnsmasq and DNSSEC enabled if the domain isn't already in your local cache through a preceding TCP query. Best, Dominik This sent my down a very deep rabbit-hole. In case people haven't realised, the answer to the time.nist.gov query is easily small enough to fit in a UDP packet. What's happening here is that one of the DNSSEC key queries needed to validate the time.nist.gov query is too long to fit in a UDP packet. Dnsmasq can validate a DNSSEC query either in UDP mode or TCP mode but not a mixture, so as soon as it gets a truncated reply to the DNSKEY query, it abandons the validation and returns a truncated repsonse to the original query in the expectation that the client will send the query again over TCP. That will allow dnsmasq to validate it and eventually return a reply. That reply would be easily small enough to fit in UDP packet. There are some other cases were the same thing can be triggered, for instance if the answer to the original query exceeds a UDP packet size when RRSIGs are added to it, but the answer without RRSIGS fits in a UDP packet. That also causes dnsmasq to add it's own TRUNCATED bit to the reply in the expectation that the client will retry (or break horribly, in the example above.) I now have code which avoid this hack: dnsmasq can swap from the UDP code path to the TCP code path to get the answers to intermediate questions or a DNSSEC-decorated reply to the original question, and as long as the final answer fits in a UDP packet, it won't ever return a truncated reply. This code has taken some time to get right and to test, but expect an upload in the next day or two for further testing purposes. On the same theme of accommodating broken clients, and because dnsmasq will not longer be artificially truncating answers, expect that code dump to include Rahul's patch as well. Cheers, Simon. Am 10/2/24 um 12:30 AM schrieb Petr Menšík: I think Simon has pointed out this is intentional. Partial reply is incomplete and for well behaving clients carries not useful informa
[Dnsmasq-discuss] trouble with host resolution
I am running dnsmasq version 2.90 with following configuration:""" domain-needed bogus-priv no-resolv no-poll server=8.8.8.8 server=8.8.4.4 server=1.1.1.1 bind-dynamic domain=prager.homeip.net expand-hosts dhcp-range=192.168.1.120,192.168.1.200,12h dhcp-option=option:router,192.168.1.1 dhcp-option=option:ntp-server,129.6.15.28,128.138.141.172 dhcp-leasefile=/var/lib/dhcp/dnsmasq.leases dhcp-authoritative cache-size=2048 listen-address=192.168.1.2 dhcp-host=40:F0:2F:23:8F:A1,fenrir,192.168.1.2,12h dhcp-host=ec:d6:8a:16:8c:bc,fenrir,192.168.1.106,12h dhcp-host=24:5E:BE:4C:A1:9F,saga,192.168.1.6,12h ... (more hosts) ... """ "fenrir" (192.168.1.3) is the host where dnsmasq is running. I am having trouble resolving the hosts:""" ❯ host saga.prager.homeip.net saga.prager.homeip.net has address 192.168.1.6 saga.prager.homeip.net is an alias for prager.homeip.net. saga.prager.homeip.net is an alias for prager.homeip.net. ❯ resolvectl query saga.prager.homeip.net saga.prager.homeip.net: 76.175.52.6 -- link: enp2s0 (prager.homeip.net) -- Information acquired via protocol DNS in 6.8ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: cache network ❯ ping saga ping: saga: Name or service not known """ The 'host' command is resolving "saga" correctly, but 'resolvectl' gets me the external IP address of my network. Could somebody please tell me what I am missing? My '/etc/resolve.conf' is just """ # Home nameserver 192.168.1.2 # Cloudflare nameserver 1.1.1.1 # Google nameserver 8.8.8.8 """ Thank you for any help. -- Bernd ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] About resolution performance and adblock
On Tue, Nov 19, 2024 at 8:05 PM Ercolino de Spiacico wrote: > If given the possibility, I would be very happy to map a file in RAM knowing > that > this is handled differently from the "standard" conf-file. I agree with this point and I'm developing libddt (dense domain table) that is basically a mmap()'able tire representing a list of domains. The data structure resembles the one libpsl uses to store publicsuffix.org database. Preliminary results for a test-case of 500k domains were ~2 MiB of RAM usage and sub-10ms resolution latency. However, I got no replies for my call-for-test-cases[1] a few months ago, so I moved my focus to other sub-projects of that project for a while. I would be grateful if you can share your block-lists with me, so I can test my code with more cases. Also, please tell me, if you have any interest in testing the patch-set. We can't know if it'll be merged to the main dnsmasq repo, but extra testing and feedback kinda increases chances of that happening :-) [1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q3/017627.html -- WBRBW, Leonid Evdokimov, https://darkk.net.ru tel:+79816800702 PGP: 6691 DE6B 4CCD C1C1 76A0 0D4A E1F2 A980 7F50 FAB2 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] About resolution performance and adblock
Indeed, I think the point is straight forward, there are part of dnsmasq where we do want to comply with RFC, etc, others that are locally significant only and can bypass certain check, adblock being one of those. There are a number of lists I can suggest, see this link we maintain: https://wiki.freshtomato.org/doku.php/adblock_dns_filtering However, unless you have de-duplication run internally at code level, you can simply pick up any list and append it (>>) multiple times to a temp file. That's what I did in my test to then echo in a bogus domain at the bottom of the file to satisfy the grep test. This gives you great control on the file size and number of records. I'll have to see what it takes to suck the patch in, but I can ask help from our community. So yes it is of interest for sure! In my mind I see the margin for a new directive, e.g named block-file or something where based on the directive syntax each domain in that file will return the very same result e.g. block-file=dnsmasq.adblockme/# Returning NX for its content and BTW this special file would only need domains defined not the full address/local syntax Likewise block-file=dnsmasq.adblockme/ would return 0.0.0.0 Pretty much the same syntax as we currently have for individual domains. Somehow, at code level I do see how this could be treated as an upstream server with "special file operation" and queried with the highest priority in a hard-coded strict-order leaving unresolved domains to the standard DNS operation (strict,no-fail,round-robin) Thanks On 20/11/2024 15:06, Leonid Evdokimov wrote: On Tue, Nov 19, 2024 at 8:05 PM Ercolino de Spiacico wrote: If given the possibility, I would be very happy to map a file in RAM knowing that this is handled differently from the "standard" conf-file. I agree with this point and I'm developing libddt (dense domain table) that is basically a mmap()'able tire representing a list of domains. The data structure resembles the one libpsl uses to store publicsuffix.org database. Preliminary results for a test-case of 500k domains were ~2 MiB of RAM usage and sub-10ms resolution latency. However, I got no replies for my call-for-test-cases[1] a few months ago, so I moved my focus to other sub-projects of that project for a while. I would be grateful if you can share your block-lists with me, so I can test my code with more cases. Also, please tell me, if you have any interest in testing the patch-set. We can't know if it'll be merged to the main dnsmasq repo, but extra testing and feedback kinda increases chances of that happening :-) [1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q3/017627.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] About resolution performance and adblock
On Wed, Nov 20, 2024 at 04:06:08PM +0300, Leonid Evdokimov wrote: > On Tue, Nov 19, 2024 at 8:05 PM Ercolino de Spiacico > wrote: > > If given the possibility, I would be very happy to map a file in RAM > > knowing that > > this is handled differently from the "standard" conf-file. > > I agree with this point and I'm developing libddt (dense domain table) > that is basically a mmap()'able tire representing a list of domains. > The data structure resembles the one libpsl uses to store > publicsuffix.org database. > > Preliminary results for a test-case of 500k domains were ~2 MiB of RAM > usage and sub-10ms resolution latency. > > However, I got no replies for my call-for-test-cases[1] a few months > ago, so I moved my focus to other sub-projects of that project for a > while. > > I would be grateful if you can share your block-lists with me, so I > can test my code with more cases. > > Also, please tell me, if you have any interest in testing the > patch-set. We can't know if it'll be merged to the main dnsmasq repo, > but extra testing and feedback kinda increases chances of that > happening :-) > > [1] > https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q3/017627.html > This might interest me too. I run dnsmasq with a 'blacklist' on two systems. One is a ThinkPad t470 laptop with 8Gb of memory and more disk space than I know what to do with so I doubt if reducing dnsmasq's memory footprint will make much difference there. However I'm also running dnsmasq with a blacklist on an Asus DSL-AC68U router (running ASUSWRT-Merlin) and that has only 256Mb memory so reducing the amount that dnsmasq uses could well be a good thing. The blacklist I use comes from:- https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts I run a trivial awk script to convert it so I can just put the converted file into /etc/dnsmasq.d. An example of the converted file is:- address=/uk2.thor.rtk.io/ address=/www.rtk.io/ address=/mt.rtmark.net/ address=/my.rtmark.net/ address=/token.rubiconproject.com/ address=/runative-syndicate.com/ address=/pixel.runative-syndicate.com/ address=/s.sh/ address=/log-1.samsungacr.com/ address=/log-2.samsungacr.com/ Currently the file has a bit over 121k entries and is about 3.7Mb. At the moment I can't see a way to monitor memory usage on the DSL-AC68U, top just says 'no process info in /proc'. I can install things via opkg on it. There's 'collectd-mod-memory' which says it's a "physical memory usage input plugin". -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH 1/1] forward.c: fix handling of truncated response
Apolgies for top-posting. Here's a log extract showing a validated answer for time.nist.gov WITHOUT returning a TRUNCATED answer to the client. Simon. dnsmasq: UDP 1 ::1/41670 query[A] time.nist.gov from ::1 dnsmasq: UDP 1 ::1/41670 forwarded time.nist.gov to 8.8.8.8 dnsmasq: UDP 1 ::1/41670 forwarded time.nist.gov to 8.8.4.4 dnsmasq: UDP 2 dnssec-query[DS] gov to 8.8.8.8 dnsmasq: UDP 3 dnssec-query[DNSKEY] . to 8.8.8.8 dnsmasq: UDP 3 reply . is DNSKEY keytag 20326, algo 8 dnsmasq: UDP 3 reply . is DNSKEY keytag 61050, algo 8 dnsmasq: UDP 2 reply gov is DS for keytag 2536, algo 13, digest 2 dnsmasq: UDP 4 dnssec-query[DS] nist.gov to 8.8.8.8 dnsmasq: UDP 5 dnssec-query[DNSKEY] gov to 8.8.8.8 dnsmasq: UDP 5 reply gov is DNSKEY keytag 35496, algo 13 dnsmasq: UDP 5 reply gov is DNSKEY keytag 2536, algo 13 dnsmasq: UDP 4 reply nist.gov is DS for keytag 33751, algo 8, digest 2 dnsmasq: UDP 6 dnssec-query[DNSKEY] nist.gov to 8.8.8.8 dnsmasq: UDP 6 reply nist.gov is DNSKEY keytag 18303, algo 8 dnsmasq: UDP 6 reply nist.gov is DNSKEY keytag 33751, algo 8 dnsmasq: UDP 7 dnssec-query[DS] glb.nist.gov to 8.8.8.8 dnsmasq: UDP 7 reply glb.nist.gov is DS for keytag 56235, algo 7, digest 1 dnsmasq: UDP 7 reply glb.nist.gov is DS for keytag 4395, algo 7, digest 1 dnsmasq: UDP 8 dnssec-query[DNSKEY] glb.nist.gov to 8.8.8.8 dnsmasq: UDP 8 reply glb.nist.gov is truncated dnsmasq: TCP 8 dnssec-query[DNSKEY] glb.nist.gov to 8.8.8.8 dnsmasq: TCP 8 reply glb.nist.gov is DNSKEY keytag 57306, algo 7 dnsmasq: TCP 8 reply glb.nist.gov is DNSKEY keytag 56235, algo 7 dnsmasq: TCP 8 reply glb.nist.gov is DNSKEY keytag 49100, algo 7 dnsmasq: TCP 8 reply glb.nist.gov is DNSKEY keytag 17402, algo 7 dnsmasq: UDP 1 ::1/41670 validation result is SECURE dnsmasq: UDP 1 ::1/41670 reply time.nist.gov is (DNSSEC signed) dnsmasq: UDP 1 ::1/41670 reply ntp1.glb.nist.gov is 132.163.96.3 (DNSSEC signed) On 10/2/24 21:34, Simon Kelley wrote: On 02/10/2024 17:00, Dominik Derigs via Dnsmasq-discuss wrote: Hey all, having this configurable makes sense particularly thinking about the multitude of IoT devices often receiving not all that much attention from their manufacturers. A particular example is the camera Tapo C-310 which seems to be widely used and has often been reported in the Pi-hole forums to cause a huge amount of queries due to exactly this truncation method we are talking about here (when dnsmasq is used with DNSSEC, the query A time.nist.gov results in truncation). Said Tapo camera is not behaving nicely and does not retry over TCP. Instead, it retries the same query roughly one second later, resulting in a whooping 86,400 identical queries, all being truncated. A workaround is querying this domain periodically manually over TCP but it is a rather ugly workaround. If there would be an option to allow truncated content to remain, I would indeed find it very useful for situations like the one mentioned above. I confirmed that the camera could successfully reads the returned CNAME/A record. This is what I got when simply applying the submitted patch (but keeping the logging): Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 query[A] time.nist.gov from 127.0.0.1 Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 forwarded time.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 26 dnssec-query[DS] gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 26 reply gov is DS for keytag 2536, algo 13, digest 2 Oct 2 17:46:53 dnsmasq[1861633]: 27 dnssec-query[DS] nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 28 dnssec-query[DNSKEY] gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag 2536, algo 13 Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag 35496, algo 13 Oct 2 17:46:53 dnsmasq[1861633]: 27 reply nist.gov is DS for keytag 33751, algo 8, digest 2 Oct 2 17:46:53 dnsmasq[1861633]: 29 dnssec-query[DNSKEY] nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY keytag 18303, algo 8 Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY keytag 33751, algo 8 Oct 2 17:46:53 dnsmasq[1861633]: 30 dnssec-query[DS] glb.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for keytag 56235, algo 7, digest 1 Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for keytag 4395, algo 7, digest 1 Oct 2 17:46:53 dnsmasq[1861633]: 31 dnssec-query[DNSKEY] glb.nist.gov to 127.0.0.1#5335 Oct 2 17:46:53 dnsmasq[1861633]: 31 reply glb.nist.gov is truncated[DNSKEY] Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 validation result is TRUNCATED Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 reply is truncated For testing, "dig +ignore + notcp time.nist.gov" is handy as it is guaranteed to be truncated with dnsmasq and DNSSEC enabled if the domain isn't already in your local cache through a preceding TCP query. I'm in the proces
