[Dnsmasq-discuss] IPv6 link-local upstream servers with «@if» no longer works
Hello, Prior to commit «3934155 Cope with multiple interfaces with the same LL address.» this worked fine: $ dnsmasq -dqhRS fe80::1234@eth0 After the mentioned commit this no longer works. I can confirm (using tcpdump) that the queries are forwarded just fine to fe80::1234 on the eth0 interface. However it appears that dnsmasq simply ignores the responses that come back, thus no responses are being returned to the stub resolver (which eventually times out). Since commit «7de060b import of dnsmasq-2.58.tar.gz» it is possible to use «%» as a delimiter instead of «@», and this works fine. However, it seems as if that there is no longer a method of specifying an IPv6 link-local upstream server that works regardless of dnsmasq version. For the record, the change broke NetworkManager, which explicitly uses «@» as the delimiter in order to support dnsmasq versions prior to 2.58: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager/nm-dns-dnsmasq.c#n141 The change clearly broke backwards compatibility, but seeing how there are no warnings about that in the changelog I assuming it was unintentional and thus a bug? Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
* Simon Kelley > I just pushed > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=fef2f1c75eba56b7355cbe729e4362474d558aa4 > > Which makes the following changes: > > 1) No longer fail to validate a reply proving that a DS record doesn't > exist if RRs in the auth section other the the NSEC/NSEC3 records needed > for non-existence proof are not signed. > > 2) Use the TTL of the NSEC record when caching the non-existence of DS > records. > > I'm currently testing this live here, and I'd appreciate it if you could > give it a whirl too. Excellent. I've been running it for a few hours now, no problems whatsoever so far. In comparison, with HEAD^1, I could hardly use my computer for anything Internet-related. So this is very promising indeed. Thanks! Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
Hi Simon, > A quick bit of differential analysis of the first query reveals that the > problem is the mythic-beasts.com DNSKEY RRset. > > 8.8.8.8, and the mythic-beasts authoritative server I tried gives the > following answer for that RRset. > > ;; ANSWER SECTION: > mythic-beasts.com.86400 IN DNSKEY 257 3 10 > AwEAAaXuiwGP7BTBwrhYj8V+J7VQ+nalXaK3Mo5pXI4x//xD4O8ZN9ZF > CMuvKYhPW+VjsDWYO/QT6KqcqHEErWgYjv/c5vdxJAkM5zfa8UJiOp0q > X2S7RJinMkGqXz05YNp7o+ZE5W/Yykzwfn3k036Mrf4NY9FYKU5uznrc > fzW4vP8vQzXLNBEn+/ErWfbG3mYFjmhYxVsvw0yoIAmhL6xzagdQHJId > vc1G00tqjIFWXwqm3med63G/SX0ggiT/QPwe/D618wibbXu7cUpSjSpP > NxSZg+pX+hejg1DTU6x3UJ6EwMIZWzCccAg0S4KJIy8uOZrifACD4okB OM6yRjFq+TM= > mythic-beasts.com.86400 IN DNSKEY 256 3 10 > AwEAAc5oGCn44Da0km1yuWnqDWJV41f/ieZFaxZxdeRTwsTllcnw3H6a > IHsgYwArtkWqVe9CatuXjBpVmdbS9xJ1V4KrSsGdasCnZpXbtoKKy7Be > tCDUES89uhMG3noqi55rEU5OS3htgmx8fNIuVLuUto5KCbp3O9Rp3+9C > 5yQbW3eZuuDwBDEJ2DgbikiTU80MexCzkhEB3ihXhYYOnEuk4n71cSYB > IM1YcEFaECkLN/meQ077fiAgyF+hkMIzs/VFlA/mOtkNhJeP81lUVT37 > Gjo1w46qWilFtRq1TJTfB47XXDxoLHZZcFmtW9fk6BR/a+4NlxL7X8xI dII0Z9B3I40= > mythic-beasts.com.86400 IN DNSKEY 256 3 10 > AwEAAbiUu+uoyM7HirzFV/VsIO+j0vLNBMcursO6mgjX8cZPrEHKZV0O > NENhRZKrNL0hFVvpjW5I60qxGaBQ+VbcJyK8XMPPnYRnsRDRez9f5I92 > yOJDqjXNca0fj8iqqx9PztolU8SPUebhJgW22GQd2PHkKPDZaUa1Oag2 > OUq6JJRUPwmeZO9dMMtXa3kY/11nj5YoD8FpJPwCZv8VMbVFrORt0kMc > HlpB/hLYpaxzPWKIs95V1o2rL0zxlIkKSwxuZCli7W5ipORB5NM2Vawq > c6m6UfoOabP2SJUm/aTKlom/ZtS4kDaO/9DIeN0F3bG1nLFRRUwRaC4M UjNs4eHCapE= > mythic-beasts.com.86400 IN RRSIG DNSKEY 10 2 86400 20191002000509 > 20190901230509 42918 mythic-beasts.com. > UltVyLHHD+qVowOQIqZLtTc9cA5T/O4t72EiLsgiH9oRjLz7D0MgB+F2 > 0TXv8OoufV3mzf2bjaou1ziIi6FBb5j1RQSqGT44O1zJyQmX40z3LQ3L > UUB6hQU5eh9Q4JTgChHNDpvlvWBTnObTy6NuJn5hdtQKtGN8yZ4gGHM7 > gGB+Y2N595abpWcz9xq2mtXQgGbVJUshe+JfQ3JgU034eDTlvLBTdM73 > HVjpfbxCoMboXOCtjndEB0200gloJSumqdEnlFufWfISqXhruSIB6IKP > 5o2yUSv4mtQUOtVm+RPwcIoprm6ON5Ln2tFHJlgquuJA5vhrIIl+/e99 qarI4Q== > > > Note, three DNSKEY records and the signature that signs the RRset. Note > that this is a self-signature: the signature, along with key 41918 signs > the digest of the set of three records. key 41918 is proved to be valid > by a separate DS record that propagates the chain of trust down from the > .com zone. > > The answer to the same query in your pcap has only two DNSKEY RRs. The > value of the signature is different, so it's possible that this still a > valid, but different, RRset. However dnsmasq thinks it is not valid, and > my feeling is that we should try and answer the question "where has this > RRset come from" before we assume it's valid and dnsmasq is mistaken. > > So, what happens when you ask your upstream server the query > > dig +dnssec DNSKEY mythic-beasts.com > > ? ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> @87.238.33.1 +dnssec DNSKEY mythic-beasts.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50476 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mythic-beasts.com. IN DNSKEY ;; ANSWER SECTION: mythic-beasts.com. 86397 IN DNSKEY 256 3 10 AwEAAbiUu+uoyM7HirzFV/VsIO+j0vLNBMcursO6mgjX8cZPrEHKZV0O NENhRZKrNL0hFVvpjW5I60qxGaBQ+VbcJyK8XMPPnYRnsRDRez9f5I92 yOJDqjXNca0fj8iqqx9PztolU8SPUebhJgW22GQd2PHkKPDZaUa1Oag2 OUq6JJRUPwmeZO9dMMtXa3kY/11nj5YoD8FpJPwCZv8VMbVFrORt0kMc HlpB/hLYpaxzPWKIs95V1o2rL0zxlIkKSwxuZCli7W5ipORB5NM2Vawq c6m6UfoOabP2SJUm/aTKlom/ZtS4kDaO/9DIeN0F3bG1nLFRRUwRaC4M UjNs4eHCapE= mythic-beasts.com. 86397 IN DNSKEY 256 3 10 AwEAAc5oGCn44Da0km1yuWnqDWJV41f/ieZFaxZxdeRTwsTllcnw3H6a IHsgYwArtkWqVe9CatuXjBpVmdbS9xJ1V4KrSsGdasCnZpXbtoKKy7Be tCDUES89uhMG3noqi55rEU5OS3htgmx8fNIuVLuUto5KCbp3O9Rp3+9C 5yQbW3eZuuDwBDEJ2DgbikiTU80MexCzkhEB3ihXhYYOnEuk4n71cSYB IM1YcEFaECkLN/meQ077fiAgyF+hkMIzs/VFlA/mOtkNhJeP81lUVT37 Gjo1w46qWilFtRq1TJTfB47XXDxoLHZZcFmtW9fk6BR/a+4NlxL7X8xI dII0Z9B3I40= mythic-beasts.com. 86397 IN DNSKEY 257 3 10 AwEAAaXuiwGP7BTBwrhYj8V+J7VQ+nalXaK3Mo5pXI4x//xD4O8ZN9ZF CMuvKYhPW+VjsDWYO/QT6KqcqHEErWgYjv/c5vdxJAkM5zfa8UJiOp0q X2S7RJinMkGqXz05YNp7o+ZE5W/Yykzwfn3k036Mrf4NY9FYKU5uznrc fzW4vP8vQzXLNBEn+/ErWfbG3mYFjmhYxVsvw0yoIAmhL6xzagdQHJId vc1G00tqjIFWXwqm3med63G/SX0ggiT/QPwe/D618wibbXu7cUpSjSpP NxSZg+pX+hejg1DTU6x3UJ6EwMIZWzCccAg0S4KJIy8uOZrifACD4okB OM6yRjFq+TM= mythic-beasts.com. 86397 IN RRSIG DNSKEY 10 2 86400 20191002000509 20190901230509 42918 mythic-beasts.com. UltVyLHHD+qVowOQIqZLtTc9cA5T/O4t72EiLsgiH9oRjLz7D0MgB+F2 0TXv8OoufV3mzf2bjaou1ziIi6FBb5j1RQSqGT44O1zJyQmX40z3LQ3L UUB6hQU5eh9Q4JTgChHNDpvlvWBTnObTy6NuJn5hdtQKtGN8yZ4gGHM7 gGB+Y2N595abpWcz9xq2mtXQgGbVJUshe+JfQ3JgU034eDTlvLBTdM73 HVjpfbxCoMboXOCtjndEB0200gloJSumqdEnlFufWfISqXhruSIB6IKP 5o2yUSv4mtQUOtVm+RPwcIoprm6ON5Ln2tFHJlgquuJA5vhrIIl+/e99 qarI4Q==
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
Hi again, > OK. scratch that. Looks like we just captured an irrelevant key-rollover. > > The problem here is that the reply to the original query contains an > unsigned RRset of NS records in the auth section. Said NS records are in > a signed zone, which flags them as bogus. As far as I can see, that's > correct for records in the answer section, but for records in the auth > section, it merely renders the reply as insecure. That would seem to > make the AD bit rather useless, but I guess it's useless anyway. > > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=69a0477b741c1f8195c64417fec4a92a50c9291a > > Attempts to fix this. > > Thanks again for your work testing and diagnosing this. I can confirm that Dnsmasq 69a0477 resolves www.linuxquestions.org and www.ipv6.org.uk as expected (DNSSEC state insecure). Great work, thanks! Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Tore Anderson > Apologies, I botched my test (using the wrong upstream server). It does *not* > work, but the error is different: > > $ src/dnsmasq -d -p 5353 > dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 > dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP > DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile > dnsmasq: DNSSEC validation enabled > dnsmasq: configured with trust anchor for keytag 20326 > dnsmasq: configured with trust anchor for keytag 19036 > dnsmasq: using nameserver 87.238.33.1#53 > dnsmasq: cleared cache > dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 > dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DS] uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 > dnsmasq: reply . is DNSKEY keytag 59944, algo 8 > dnsmasq: reply . is DNSKEY keytag 20326, algo 8 > dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 > dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 > dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 > dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 > dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 > dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 > dnsmasq: reply ipv6.org.uk is no DS > [...] > > This query is repeated ~44 times in a tight loop. It makes a total of 50 > queries before giving up, I guess it hits a built-in limit. > > PCAP attached. > > It seems to happen with *all* Insecure domain names (not only those that have > CNAMES pointing to other Secure domain names). Bisected: ae7a3b9d2e8705af203a1347c397718a24331747 is the first bad commit commit ae7a3b9d2e8705af203a1347c397718a24331747 Author: Simon Kelley Date: Tue Sep 3 14:40:47 2019 +0100 DNSSEC: implement RFC-4036 para 5.3.3. rules on TTL values. :04 04 52d7ead3d28019308dff0cb0dfcd80e4ef0341de 60ff380eb9c6b813d5081dee470d276be2109480 M src If I revert this one, www.ipv6.org.uk and www.linuxquestions.org both resolve fine (as Insecure). So the fix in 69a0477 seems good. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
Hi Simon, > Now, it's certainly possible to verify that the DS record doesn't exist > without relying on the data in the SOA record. BUT there is a problem: > having determined securely that the DS record doesn't exist, dnsmasq > caches that information, and it uses data from the SOA record to > determine the time-to-live of that cache record. > > So, in theory, and attacker could replace the SOA record in the reply > with one which gave, say, a very long TTL for the cached negative DS > record. I don't know is that's real weakness, but if so, the solution > may be not to cache the DS record if the SOA record is not signed. I think it is more logical to use the TTL of the NSEC[3] record that proved the non-existence of the DS record in the first place. These RFCs says the TTL on NSEC[3] records should be identical with the SOA minimum: https://tools.ietf.org/html/rfc4035#section-2.3 https://tools.ietf.org/html/rfc5155#section-3 Also, this one «allows validating resolvers to respond with a negative answer immediately if the name in question falls into a range expressed by an NSEC[3] resource record already in the cache»: https://tools.ietf.org/html/rfc8198 My ISP's name server does consistently include RRSIGs for the NSEC[3] records it answers with in the authority section, so the proof of non-existence is Secure and it does come with a lifetime. Another approach would be to explicitly query for the SOA record (if its RRSIG was not included in the authority section of the DS response to begin with). My ISP's name server will consistently include the SOA RRSIG in the answer section when answering such queries, for what it is worth. This should allow Dnsmasq to determine that the SOA provided is Secure so it can safely use its minimum field for the negative cache lifetime. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
I've noticed that Dnsmasq git master (2.80-68-gfef2f1c) will sometimes incorrectly return SERVFAIL and log a Bogus verdict when looking up domain names which are Insecure CNAMEs for a Secure names. For example: www.ipv6.org.uk. IN CNAME proxy.mythic-beasts.com. www.linuxquestions.org. IN CNAME www.linuxquestions.org.cdn.cloudflare.net. ipv6.org.uk and linuxquestions.org are both Insecure (non-existence of DS record in parent zone is proven with signed NSEC3). proxy.mythic-beasts.com and www.linuxquestions.org.cdn.cloudflare.net are Secure, on the other hand. See http://dnsviz.net/d/www.ipv6.org.uk/dnssec/ and http://dnsviz.net/d/www.linuxquestions.org/dnssec/ for detailed analysis. I have more examples, but I figured two was probably enough. /etc/dnsmasq.conf contains: dnssec conf-file = /usr/share/dnsmasq/trust-anchors.conf log-queries no-hosts no-resolv server=87.238.33.1 When I try to look up the two problematic hostnames (using "dig @127.0.0.1 -p 5353 IN A") I get the following (blank lines inserted for clarity): $ dnsmasq -d -p 5353 dnsmasq: started, version 2.80-68-gfef2f1c cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile dnsmasq: DNSSEC validation enabled dnsmasq: configured with trust anchor for keytag 20326 dnsmasq: configured with trust anchor for keytag 19036 dnsmasq: using nameserver 87.238.33.1#53 dnsmasq: cleared cache dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DS] uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 dnsmasq: reply . is DNSKEY keytag 20326, algo 8 dnsmasq: reply . is DNSKEY keytag 59944, algo 8 dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] com to 87.238.33.1 dnsmasq: reply com is DS keytag 30909, algo 8, digest 2 dnsmasq: dnssec-query[DS] mythic-beasts.com to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] com to 87.238.33.1 dnsmasq: reply com is DNSKEY keytag 30909, algo 8 dnsmasq: reply com is DNSKEY keytag 17708, algo 8 dnsmasq: reply mythic-beasts.com is DS keytag 42918, algo 10, digest 2 dnsmasq: dnssec-query[DNSKEY] mythic-beasts.com to 87.238.33.1 dnsmasq: reply mythic-beasts.com is DNSKEY keytag 42918, algo 10 dnsmasq: reply mythic-beasts.com is DNSKEY keytag 39980, algo 10 dnsmasq: validation www.ipv6.org.uk is BOGUS dnsmasq: reply www.ipv6.org.uk is dnsmasq: reply proxy.mythic-beasts.com is 46.235.225.189 dnsmasq: reply proxy.mythic-beasts.com is 93.93.129.174 dnsmasq: query[A] www.linuxquestions.org from 127.0.0.1 dnsmasq: forwarded www.linuxquestions.org to 87.238.33.1 dnsmasq: dnssec-query[DS] org to 87.238.33.1 dnsmasq: reply org is DS keytag 9795, algo 7, digest 2 dnsmasq: reply org is DS keytag 9795, algo 7, digest 1 dnsmasq: dnssec-query[DS] linuxquestions.org to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] org to 87.238.33.1 dnsmasq: reply org is DNSKEY keytag 9795, algo 7 dnsmasq: reply org is DNSKEY keytag 17883, algo 7 dnsmasq: reply org is DNSKEY keytag 47612, algo 7 dnsmasq: reply org is DNSKEY keytag 44078, algo 7 dnsmasq: reply linuxquestions.org is no DS dnsmasq: dnssec-query[DS] net to 87.238.33.1 dnsmasq: reply net is DS keytag 35886, algo 8, digest 2 dnsmasq: dnssec-query[DS] cloudflare.net to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] net to 87.238.33.1 dnsmasq: reply net is DNSKEY keytag 59540, algo 8 dnsmasq: reply net is DNSKEY keytag 35886, algo 8 dnsmasq: reply net is DNSKEY keytag 2129, algo 8 dnsmasq: reply cloudflare.net is DS keytag 2371, algo 13, digest 2 dnsmasq: dnssec-query[DNSKEY] cloudflare.net to 87.238.33.1 dnsmasq: reply cloudflare.net is DNSKEY keytag 34505, algo 13 dnsmasq: reply cloudflare.net is DNSKEY keytag 2371, algo 13 dnsmasq: validation www.linuxquestions.org is BOGUS dnsmasq: reply www.linuxquestions.org is dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.158.7 dnsmasq: reply www.linuxquestions.org.cdn.cloudflare.net is 104.25.159.7 The upstream DNS server is running BIND 9.9.5 with DNSSEC validation enabled. I suspect the problem might be related to something in the Authority or Additional sections of the answer packet, since I don't get this problem if I use 1.1.1.1 or 8.8.8.8 as the upstream server. I tested Knot Resolver towards the same upstream server, and it gave the correct Insecure verdict for both queries. If I query for the CNAME directly (using "dig @127.0.0.1 -p 5353 IN CNAME"), I
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Simon Kelley > OK. I think I see the problem.. > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e24abf28a29574069717af78c1d3e0ede64388ff > > should fix. It does indeed. Good catch! (By the way, I did send the promised PCAP yesterday. However, because the message was >40KB, it was queued for moderation by the mailing list administrator.) Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus
* Tore Anderson > I can confirm that Dnsmasq 69a0477 resolves www.linuxquestions.org and > www.ipv6.org.uk as expected (DNSSEC state insecure). Great work, thanks! Apologies, I botched my test (using the wrong upstream server). It does *not* work, but the error is different: $ src/dnsmasq -d -p 5353 dnsmasq: started, version 2.80-71-g69a0477 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile dnsmasq: DNSSEC validation enabled dnsmasq: configured with trust anchor for keytag 20326 dnsmasq: configured with trust anchor for keytag 19036 dnsmasq: using nameserver 87.238.33.1#53 dnsmasq: cleared cache dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1 dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DS] uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1 dnsmasq: reply . is DNSKEY keytag 59944, algo 8 dnsmasq: reply . is DNSKEY keytag 20326, algo 8 dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2 dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1 dnsmasq: reply uk is DNSKEY keytag 43876, algo 8 dnsmasq: reply uk is DNSKEY keytag 43056, algo 8 dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2 dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1 dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1 dnsmasq: reply ipv6.org.uk is no DS [...] This query is repeated ~44 times in a tight loop. It makes a total of 50 queries before giving up, I guess it hits a built-in limit. PCAP attached. It seems to happen with *all* Insecure domain names (not only those that have CNAMES pointing to other Secure domain names). Tore foo.pcap Description: application/vnd.tcpdump.pcap ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface
Start out with the following /etc/dnsmasq.conf, replacing «wlp2s0» as appropriate: log-queries no-hosts no-resolv server=1.1.1.1@wlp2s0 Start Dnsmasq and send it a TCP query: $ src/dnsmasq -d -p 5333 dnsmasq: started, version 2.80-72-ge24abf2 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile dnsmasq: using nameserver 1.1.1.1#53(via wlp2s0) dnsmasq: cleared cache $ dig @127.0.0.1 -p 5333 fud.no A +vc | grep HEADER ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2916 Output from Dnsmasq following the above query: dnsmasq: query[A] fud.no from 127.0.0.1 dnsmasq: config error is REFUSED It makes no attempt to contact the upstream server. If I remove «@wlp2s0» from the server config, it works fine. A practical consequence of this bug is that I cannot resolve any domain names under *.org with DNSSEC enabled. The initial UDP query results in a truncated answer, so libc/dig retries in TCP mode and fails. Note that NetworkManager automatically configures the upstream DNS servers with a specific interface via D-Bus, this behaviour appears hard-coded. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface
* Tore Anderson > Start out with the following /etc/dnsmasq.conf, replacing «wlp2s0» as > appropriate: > > log-queries > no-hosts > no-resolv > server=1.1.1.1@wlp2s0 > > Start Dnsmasq and send it a TCP query: > > $ src/dnsmasq -d -p 5333 Bisected: 305ffb5ef0ba5ab1df32ef80f266a4c9e395ca13 is the first bad commit commit 305ffb5ef0ba5ab1df32ef80f266a4c9e395ca13 Author: Simon Kelley Date: Sat Mar 16 18:17:17 2019 + Improve kernel-capability manipulation code under Linux. Dnsmasq now fails early if a required capability is not available, and tries not to request capabilities not required by its configuration. :100644 100644 b942ec269cc6c1b7614a9d57cb0b9468507f031c f2d38a0f9bb73b4f480cd323f49cd574fc3e2744 M CHANGELOG :04 04 a4dd29e7fbdac449dd9b502e012beb2c25a47387 7b0eb0f197c0cb857981c607be8b08d62cee9ff3 M src After some more debugging I realised that this is a heisenbug. Starting Dnsmasq with the «-d» option does not accurately reproduce the problem, since it will not drop privileges in debug mode. To me it looks as if using a server specified with an interface requires root privileges. Thus, to trigger the actual bug, there are two options: 1) Start Dnsmasq as non-root (broken on any version, at least since v2.80). 2) Start Dnsmasq as root (this works in v2.80, but is broken since 305ffb5 presumably because Dnsmasq now drops privileges it is going to need later on). Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface
* B. Cook > I can't find the actual documentation at the moment.. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=man/dnsmasq.8;h=bc5ae6360f5459d99cafb78d34c532e5b087abf6;hb=HEAD#l474 > iirc dnsmasq port designation is # not @ While that is true, it is irrelevant, as I am not specifying a port, nor am I attempting to do so. What I am specifying is the outgoing interface, through which 1.1.1.1 is reachable perfectly fine (to answer Geert Stappers's comment). > but Cloudflare doesn't do unencrypted DNS.. Yes they do, but again, that is irrelevant as no packets are being sent to the upstream server. > Not sure if the @ is something new.. Not at all. According to git blame it was added in: commit 824af85bdf7a19ea2281b85826180696fed22125 (tag: v2.41) Author: Simon Kelley Date: Tue Feb 12 20:43:05 2008 + import of dnsmasq-2.41.tar.gz Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface
* Simon Kelley > I got the wrong capability, it needs CAP_NET_RAW, not CAP_NET_ADMIN. Fix > pushed to git. Works now, thanks! Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface
* Simon Kelley > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=90d7c6b97dbae2c913e7bb7af9c6c0f874493092 > > should fix this, if I've understood it right. Hi Simon, Not quite. With this patch, Dnsmasq does refuse to start as non-root: $ src/dnsmasq dnsmasq: process is missing required capability NET_ADMIN However, when started as root, it still answers REFUSED: $ sudo src/dnsmasq & sleep 1; dig @127.0.0.1 -p 5353 fud.no A +vc +short [1] 14179 dnsmasq[14181]: started, version 2.80-73-g90d7c6b cachesize 150 dnsmasq[14181]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile dnsmasq[14181]: using nameserver 1.1.1.1#53(via wlp2s0) dnsmasq[14181]: cleared cache dnsmasq[14186]: query[A] fud.no from 127.0.0.1 dnsmasq[14186]: config error is REFUSED It is clearly related to privileges, because if I add «-d» to the Dnsmasq command line, it works: $ sudo src/dnsmasq -d & sleep 1; dig @127.0.0.1 -p 5353 fud.no A +vc +short [1] 15333 dnsmasq[15335]: started, version 2.80-73-g90d7c6b cachesize 150 dnsmasq[15335]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile dnsmasq[15335]: using nameserver 1.1.1.1#53(via wlp2s0) dnsmasq[15335]: cleared cache dnsmasq[15335]: query[A] fud.no from 127.0.0.1 dnsmasq[15335]: forwarded fud.no to 1.1.1.1 dnsmasq[15335]: reply fud.no is 87.238.59.19 87.238.59.19 /etc/dnsmasq.conf contains: keep-in-foreground log-facility=- log-queries no-hosts no-resolv port=5353 server=1.1.1.1@wlp2s0 Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries
* Geert Stappers >> Here are the corresponding log lines from Dnsmasq: >> >> nov. 29 07:15:53.964856 sloth.fud.no dnsmasq[48069]: query[A] >> l1-g9-osl2.n.bitbit.net from 127.0.0.1 >> nov. 29 07:15:53.965060 sloth.fud.no dnsmasq[48069]: forwarded >> l1-g9-osl2.n.bitbit.net to 87.238.33.1 >> nov. 29 07:15:53.965155 sloth.fud.no dnsmasq[48069]: query[] >> l1-g9-osl2.n.bitbit.net from 127.0.0.1 >> nov. 29 07:15:53.965273 sloth.fud.no dnsmasq[48069]: forwarded >> l1-g9-osl2.n.bitbit.net to 87.238.33.1 >> nov. 29 07:15:54.039407 sloth.fud.no dnsmasq[48069]: reply >> l1-g9-osl2.n.bitbit.net is >> nov. 29 07:15:54.039461 sloth.fud.no dnsmasq[48069]: reply >> eth0.l1-g9-osl2.n.bitbit.net is 10.20.120.102 >> nov. 29 07:15:54.039666 sloth.fud.no dnsmasq[48069]: reply >> l1-g9-osl2.n.bitbit.net is >> nov. 29 07:15:54.039700 sloth.fud.no dnsmasq[48069]: reply >> eth0.l1-g9-osl2.n.bitbit.net is NODATA-IPv6 >> nov. 29 07:15:54.964042 sloth.fud.no dnsmasq[48069]: query[type=44] >> l1-g9-osl2.n.bitbit.net from 127.0.0.1 >> (CPU starts spinning at this point, no further log lines appear) > > The pcap file says / shows > > 07:15:53.964639 IP localhost.58896 > localhost.domain: 26883+ [1au] A? > l1-g9-osl2.n.bitbit.net. (52) > 07:15:53.964696 IP localhost.58896 > localhost.domain: 9742+ [1au] ? > l1-g9-osl2.n.bitbit.net. (52) 1+2: A and queries from libc stub resolver to Dnsmasq > 07:15:53.964955 IP 100.66.5.6.46462 > dns.i.bitbit.net.domain: 45004+ > [1au] A? l1-g9-osl2.n.bitbit.net. (52) > 07:15:53.965208 IP 100.66.5.6.46462 > dns.i.bitbit.net.domain: 42294+ > [1au] ? l1-g9-osl2.n.bitbit.net. (52) 3+4: Dnsmasq forwarding the queries in packets 1+2 to upstream DNS server > 07:15:54.039175 IP dns.i.bitbit.net.domain > 100.66.5.6.46462: 45004* > 2/3/7 CNAME eth0.l1-g9-osl2.n.bitbit.net., A 10.20.120.102 (284) > 07:15:54.039273 IP dns.i.bitbit.net.domain > 100.66.5.6.46462: 42294* > 1/1/1 CNAME eth0.l1-g9-osl2.n.bitbit.net. (145) 5+6: Upstream DNS server answers Dnsmasq's queries in packets 3+4 > 07:15:54.039525 IP localhost.domain > localhost.58896: 26883* 2/3/7 > CNAME eth0.l1-g9-osl2.n.bitbit.net., A 10.20.120.102 (284) > 07:15:54.039735 IP localhost.domain > localhost.58896: 9742* 1/1/1 CNAME > eth0.l1-g9-osl2.n.bitbit.net. (145) 7+8: Answers to queries 1+2 from Dnsmasq to libc stub resolver (At this point, the SSH client proceeds to connect to the SSH server, and approx. 1 second later it has received a host key that wants to verify.) > 07:15:54.963758 IP localhost.49114 > localhost.domain: 35496+ [1au] > SSHFP? l1-g9-osl2.n.bitbit.net. (52) 9: SSHFP query from libc stub resolver to Dnsmasq (unanswered but logged). Dnsmasq breaks and starts spinning on the CPU. > 07:15:58.440050 IP localhost.60721 > localhost.domain: 17459+ [1au] A? > mattermost.redpill-linpro.com. (58) > 07:15:58.440064 IP localhost.60721 > localhost.domain: 44236+ [1au] > ? mattermost.redpill-linpro.com. (58) > 07:15:59.968059 IP localhost.49114 > localhost.domain: 35496+ [1au] > SSHFP? l1-g9-osl2.n.bitbit.net. (52) > 07:16:02.394821 IP localhost.56180 > localhost.domain: 61011+ ? > fedoraproject.org. (35) > 07:16:03.445058 IP localhost.60721 > localhost.domain: 17459+ [1au] A? > mattermost.redpill-linpro.com. (58) > 07:16:03.445071 IP localhost.60721 > localhost.domain: 44236+ [1au] > ? mattermost.redpill-linpro.com. (58) > 07:16:07.399014 IP localhost.56180 > localhost.domain: 61011+ ? > fedoraproject.org. (35) 10-16: Various queries from libc stub resolver to Dnsmasq (unanswered and not logged) > The 07:15:54.039273 packet is last where source host and destination > host differ. After that packet are the remaining packets only between > localhost and localhost. > > Looking closer reveals that the first two packets are also between > localhost. > > Strange, but probably not the problem. I am not sure how this is strange? To me, the packet capture annotated above is exactly what I'd expect, given the symptom of «SSHFP query makes Dnsmasq break». > | $ host l1-g9-osl2.n.bitbit.net > | l1-g9-osl2.n.bitbit.net is an alias for eth0.l1-g9-osl2.n.bitbit.net. > | eth0.l1-g9-osl2.n.bitbit.net has address 10.20.120.102 > | $ host -t unknowntype l1-g9-osl2.n.bitbit.net > | host: invalid type: unknowntype > | > | $ host -t sshfp l1-g9-osl2.n.bitbit.net > | l1-g9-osl2.n.bitbit.net is an alias for eth0.l1-g9-osl2.n.bitbit.net. > | $ dig -t sshfp l1-g9-osl2.n.bitbit.net > | > | ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -t sshfp l1-g9-osl2.n.bitbit.net > | ;; global options: +cmd > | ;; Got answer: > | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13365 > | ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > | > | ;; OPT PSEUDOSECTION: > | ; EDNS: version: 0, flags:; udp: 4096 > | ; COOKIE: 905e71c3631f8577e2d927615de0d63aaa0a6211eb0ec2e1 (good) > | ;; QUESTION SECTION: > | ;l1-g9-osl2.n.bitbit.net. IN SSHFP > | > | ;; ANSWER SECTION: > | l1-g9-osl2.n.bitbit.net. 86103
Re: [Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries
* Geert Stappers
> Could caching be involved? That we are seeing only when it fails,
> not seeing in the libpcap file what led to the fail?
I think you are right.
It is a cache miss - the bug occurs when SSH-ing to an FQDN for the first time
after Dnsmasq has started, so the SSHFP record is not found in cache.
Tracing it in GDB with breakpoints on answer_request() and cache_find_by_name():
Breakpoint 2, cache_find_by_name (crecp=crecp@entry=0x0,
name=name@entry=0x1fbfa50 "cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
810 {
(gdb) bt
#0 cache_find_by_name (crecp=crecp@entry=0x0, name=name@entry=0x1fbfa50
"cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
#1 0x0040d442 in answer_request (header=header@entry=0x1fc2220,
limit=0x1fc26d0 "", qlen=qlen@entry=50,
local_addr=..., local_addr@entry=..., local_netmask=...,
local_netmask@entry=..., now=now@entry=1575100445,
ad_reqd=1, do_bit=1, have_pseudoheader=1) at rfc1035.c:1367
#2 0x0041c8c6 in receive_query (listen=listen@entry=0x1fc07d0,
now=now@entry=1575100445) at forward.c:1563
#3 0x00420e19 in check_dns_listeners (now=now@entry=1575100445) at
dnsmasq.c:1760
#4 0x00406638 in main (argc=, argv=) at
dnsmasq.c:1192
(gdb) cont
Continuing.
Breakpoint 2, cache_find_by_name (crecp=crecp@entry=0x0,
name=name@entry=0x1fbfa50 "cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
810 {
(gdb) bt
#0 cache_find_by_name (crecp=crecp@entry=0x0, name=name@entry=0x1fbfa50
"cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
#1 0x0040d442 in answer_request (header=header@entry=0x1fc2220,
limit=0x1fc26d0 "", qlen=qlen@entry=50,
local_addr=..., local_addr@entry=..., local_netmask=...,
local_netmask@entry=..., now=now@entry=1575100445,
ad_reqd=1, do_bit=1, have_pseudoheader=1) at rfc1035.c:1367
#2 0x0041c8c6 in receive_query (listen=listen@entry=0x1fc07d0,
now=now@entry=1575100445) at forward.c:1563
#3 0x00420e19 in check_dns_listeners (now=now@entry=1575100445) at
dnsmasq.c:1760
#4 0x00406638 in main (argc=, argv=) at
dnsmasq.c:1192
(gdb) cont
Continuing.
Breakpoint 2, cache_find_by_name (crecp=crecp@entry=0x0,
name=name@entry=0x1fbfa50 "cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
810 {
(gdb) bt
#0 cache_find_by_name (crecp=crecp@entry=0x0, name=name@entry=0x1fbfa50
"cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
#1 0x0040d442 in answer_request (header=header@entry=0x1fc2220,
limit=0x1fc26d0 "", qlen=qlen@entry=50,
local_addr=..., local_addr@entry=..., local_netmask=...,
local_netmask@entry=..., now=now@entry=1575100445,
ad_reqd=1, do_bit=1, have_pseudoheader=1) at rfc1035.c:1367
#2 0x0041c8c6 in receive_query (listen=listen@entry=0x1fc07d0,
now=now@entry=1575100445) at forward.c:1563
#3 0x00420e19 in check_dns_listeners (now=now@entry=1575100445) at
dnsmasq.c:1760
#4 0x00406638 in main (argc=, argv=) at
dnsmasq.c:1192
(gdb) cont
Continuing.
Breakpoint 2, cache_find_by_name (crecp=crecp@entry=0x0,
name=name@entry=0x1fbfa50 "cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
810 {
(gdb) bt
#0 cache_find_by_name (crecp=crecp@entry=0x0, name=name@entry=0x1fbfa50
"cr1-osl4.n.bitbit.net",
now=now@entry=1575100445, prot=prot@entry=2048) at cache.c:810
#1 0x0040d442 in answer_request (header=header@entry=0x1fc2220,
limit=0x1fc26d0 "", qlen=qlen@entry=50,
local_addr=..., local_addr@entry=..., local_netmask=...,
local_netmask@entry=..., now=now@entry=1575100445,
ad_reqd=1, do_bit=1, have_pseudoheader=1) at rfc1035.c:1367
#2 0x0041c8c6 in receive_query (listen=listen@entry=0x1fc07d0,
now=now@entry=1575100445) at forward.c:1563
#3 0x00420e19 in check_dns_listeners (now=now@entry=1575100445) at
dnsmasq.c:1760
#4 0x00406638 in main (argc=, argv=) at
dnsmasq.c:1192
(gdb)
[]
I think that this while loop goes on forever:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc1035.c;h=502744bd1f847441e8a6dbf485fd9032f2a52e9f;hb=HEAD#l1367
Tore
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries
Hello, I've noticed that Dnsmasq on my system sometimes enters a defective state where it starts spinning on the CPU. When it has entered this state, I need to send it SIGKILL to get rid of it - SIGTERM is ignored. The version is current Git master (2.80-93-g6ebdc95). I've enabled query logging and grabbed the final log lines of a few incidents (slightly anonymised): Example 1: forwarded git.i.example.org to 192.168.33.1 reply git.i.example.org is reply git01-osl3.i.example.org is 10.22.3.196 reply git.i.example.org is reply git01-osl3.i.example.org is 2001:db8:400:c:18:59ff:fe7a:73c4 query[type=44] git.i.example.org from 127.0.0.1 (CPU spin begins) Example 2: query[A] s2-a8-osl3.n.example.org from 127.0.0.1 forwarded s2-a8-osl3.n.example.org to 192.168.33.1 query[] s2-a8-osl3.n.example.org from 127.0.0.1 forwarded s2-a8-osl3.n.example.org to 192.168.33.1 reply s2-a8-osl3.n.example.org is reply lo.s2-a8-osl3.n.example.org is 2001:db8:1::4:1 reply s2-a8-osl3.n.example.org is reply lo.s2-a8-osl3.n.example.org is 192.168.63.11 query[type=44] s2-a8-osl3.n.example.org from 127.0.0.1 (CPU spin begins) Example 3: query[A] s1-a8-osl3.n.example.org from 127.0.0.1 forwarded s1-a8-osl3.n.example.org to 192.168.33.1 query[] s1-a8-osl3.n.example.org from 127.0.0.1 forwarded s1-a8-osl3.n.example.org to 192.168.33.1 reply s1-a8-osl3.n.example.org is reply lo.s1-a8-osl3.n.example.org is 192.168.63.10 reply s1-a8-osl3.n.example.org is reply lo.s1-a8-osl3.n.example.org is 2001:db8:1::4:0 query[type=44] s1-a8-osl3.n.example.org from 127.0.0.1 (CPU spin begins) All of them ends with an incoming query for SSHFP records (type 44), which I find highly suspect. The SSHFP requests comes from the SSH client (due to VerifyHostKeyDNS being set in my ~/.ssh/config). None of the hostnames in question do have SSHFP records published, but that does not seem to matter, as the query does not seem to be forwarded upstream in the first place. When the bug does not occur, Dnsmasq does log that it forwards the query upstream, like so: query[type=44] l1-a9-osl3.n.example.org from 127.0.0.1 forwarded l1-a9-osl3.n.example.org to 192.168.33.1 Dnsmasq is invoked from NetworkManager, using the following command line: /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d Additional configuration in /etc/NetworkManager/dnsmasq.d/dnssec.conf: dnssec conf-file = /usr/share/dnsmasq/trust-anchors.conf log-queries Finally, my environment contains RES_OPTIONS=edns0 in case that is relevant (this is required for SSH's VerifyHostKeyDNS feature to work correctly). I cannot reliably reproduce the issue. It seems to happen regularly (several times a day) during normal usage - I use the SSH client quite frequently. I would be happy to provide additional debugging information, if given instructions on how to obtain it.' Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CPU spinning bug, possibly related to SSHFP queries
* Vladislav Grishenko > Can you try to capture dns exchange to dnsmasq (on lo interface) and from it > (on your nic interface) both at the same time? > $ tcpdump -i lo port 53 -w /path/to/dns-lo.pcap > $ tcpdump -i port 53 -w /path/to/dns-ext.pcap > Highly possible that trigger query (or reply) can't be logged in usual way, > but will be captured by tcpdump. > Next, I'd like to take a look at them, will there be something after/near the > last logged query before spinning starts. > > p.s. Caution, pcap files will contain all your dns traffic, sending it to > mail list might be not a really good idea. Hi, PCAP attached. I used «tcpdump -i any», so it's a single file with the internal and external traffic interleaved. It is apparent that the initial SSHFP query is not forwarded upstream, and that the subsequent queries from the stub resolver (a retransmission of the SSHFP query plus some other unrelated queries) are neither logged nor forwarded. Here are the corresponding log lines from Dnsmasq: nov. 29 07:15:53.964856 sloth.fud.no dnsmasq[48069]: query[A] l1-g9-osl2.n.bitbit.net from 127.0.0.1 nov. 29 07:15:53.965060 sloth.fud.no dnsmasq[48069]: forwarded l1-g9-osl2.n.bitbit.net to 87.238.33.1 nov. 29 07:15:53.965155 sloth.fud.no dnsmasq[48069]: query[] l1-g9-osl2.n.bitbit.net from 127.0.0.1 nov. 29 07:15:53.965273 sloth.fud.no dnsmasq[48069]: forwarded l1-g9-osl2.n.bitbit.net to 87.238.33.1 nov. 29 07:15:54.039407 sloth.fud.no dnsmasq[48069]: reply l1-g9-osl2.n.bitbit.net is nov. 29 07:15:54.039461 sloth.fud.no dnsmasq[48069]: reply eth0.l1-g9-osl2.n.bitbit.net is 10.20.120.102 nov. 29 07:15:54.039666 sloth.fud.no dnsmasq[48069]: reply l1-g9-osl2.n.bitbit.net is nov. 29 07:15:54.039700 sloth.fud.no dnsmasq[48069]: reply eth0.l1-g9-osl2.n.bitbit.net is NODATA-IPv6 nov. 29 07:15:54.964042 sloth.fud.no dnsmasq[48069]: query[type=44] l1-g9-osl2.n.bitbit.net from 127.0.0.1 (CPU starts spinning at this point, no further log lines appear) Tore cpu-spin.pcap.gz Description: application/gzip ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host
* Simon Kelley > I have an alternative suggestion for the syntax of dhcp-host. > It's less flexible, but simpler and easier to understand and to explain, > and uses existing semantics rather than adding new keywords. > > The idea is just to add a prefix-length to the address. That allows you > to define (eg) 1,2,4,8, or 16 addresses for use by a host simply and > easily in a way which makes it difficult to accidentally overlap address > ranges, and is fairly obvious to anyone who has done done any IPv6 > network configuration. > > for instance to reserve four addresses for each host we cold do: > > dhcp-host=00:11:22:33:44:55,[fd12:3456::aa00/62] > dhcp-host=00:11:22:33:44:56,[fd12:3456::aa04/62] > dhcp-host=00:11:22:33:44:57,[fd12:3456::aa08/62] > > As a sanity check, if the "host part" of the address isn't zero, > > ie [fd12:3456::aa01/62] > > that could be rejected with an error. I have done quite a bit of IPv6 networking, but the use of /62 here is anything but «fairly obvious» to me. It would have been much more intuitive to use /126, in my opinion. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
