Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9
Le vendredi 12 juin 2015, 13:16:09 Maciej Soltysiak a écrit : I think I have discovered what the problem is and it's unlikely to be dnsmasq. What I do is that I have a setup which is basically a split horizon: - users who are not on the service get A record for using.dnscrypt from a DNSSEC signed zone - users who are on the service get *a different* A record for using.dnscrypt.pl from unbound, without sigs! A user on my service, who has dnssec-check-unsigned enabled gets an unsigned response from a signed zone and the intended reaction of dnsmasq kicks in. Not a bug then. Is my understanding correct? As far as I understand, I have the same issue (except that dnsmasq itself is serving the non signed zone and unbound the signed) ! To solve that, I propose to make the unsigned zone on another domain or zone than the signed one. server.domain.org is signed and the public face of your server. server.intern.domain.org is unsigned. Your users can then use this address, and the dns can still have different answer depending where they are. Do you understand me ? Do you think it is a good idea ? (I am thinking of using it for my case). Best regards, Maciej On Fri, Jun 12, 2015 at 10:19 AM, Maciej Soltysiak mac...@soltysiak.com wrote: Hi, One of my users raised an issue that using.dnscrypt.pl does not resolve when dnssec-check-unsigned is turned on. I replicated the issue with most recent openwrt Chaos Calmer package: dnsmasq-full. When dnssec and trust anhcor are set and dnssec-check-unsigned is as well, dnsmasq says BOGUS DS: Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A] using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS] using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is BOGUS DS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation using.dnscrypt.pl is BOGUS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is 178.62.233.48 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A] using.dnscrypt.pl from 192.168.1.206 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A] using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS] using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS] using.dnscrypt.pl to 127.0.0.1 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is BOGUS DS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation using.dnscrypt.pl is BOGUS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is 178.62.233.48 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is BOGUS DS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation using.dnscrypt.pl is BOGUS Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl is 178.62.233.48 Verisign dnssec check are ok: http://dnssec-debugger.verisignlabs.com/using.dnscrypt.pl Oddly, dnscrypt.pl resolves fine. It also works fine if dnssec-check-unsigned is turned off. Not sure if rc10 fixes it, it's not in openwrt repo yet. Any ideas? Best regards, Maciej Soltysiak DNSCrypt Poland https://dnscrypt.pl -- Ce fichier signature.asc ? C'est une signature GPG. Si vous voulez savoir pourquoi j'utilise GPG et pourquoi vous le devriez aussi, vous pouvez lire mon article : http://www.22decembre.eu/2015/03/21/introduction-fr/ signature.asc Description: This is a digitally signed message part. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC failure with v2.73rc10
Simon Kelley si...@thekelleys.org.uk writes: Thanks Toke, finding these failure cases and fixing them, one at a time, is very necessary, but somewhat gruelling. Yup, mapping out the DNS tree one corner case at a time. Appreciate the effort, and glad I can help in a small way! :) The two CNAME domains are signed, but the eurovps.com isnt. Hence the result of the A query is not validatable, and check-unsigned has to prove that's OK, by showing that there's a secure denial of a DS record covering the query Figured it probably had something to do with the transition from a signed to an unsigned domain. The code got lost somewhere in the CNAMES when trying to prove non-existence of the DS. I've just checked in a fix, and it behaves now. Cool, thanks a bunch! -Toke ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9
Hi, On Sun, Jun 14, 2015 at 9:06 AM, Stéphane Guedon steph...@22decembre.eu wrote: Le vendredi 12 juin 2015, 13:16:09 Maciej Soltysiak a écrit : A user on my service, who has dnssec-check-unsigned enabled gets an unsigned response from a signed zone and the intended reaction of dnsmasq kicks in. Not a bug then. Is my understanding correct? As far as I understand, I have the same issue (except that dnsmasq itself is serving the non signed zone and unbound the signed) ! To solve that, I propose to make the unsigned zone on another domain or zone than the signed one. server.domain.org is signed and the public face of your server. server.intern.domain.org is unsigned. Your users can then use this address, and the dns can still have different answer depending where they are. Do you understand me ? Do you think it is a good idea ? (I am thinking of using it for my case). Yes, I understand, I think it would work and it's a clever workaround for the issue, however in my case it does not help to maintain the end goal which was to provide authenticated response to that domain so that it is always trustworthy. That actually is becoming a DNSSEC question. Is there a way to provide split-horizon answers on signed zones? Can one name have 2 different valid answers and RRSIGs? perhaps if the signature could be for a name/ttl pair, not just the name and have different ttls on those names? Dunno. Perhaps me trying to use dns records to test whether the responses are coming over dnscrypt or not is flawed in nature. Thanks anyway, Maciej ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Announce: dnsmasq-2.73
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 After many delays and tribulations, I've just released dnsmasq-2.73 Get it here: http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.73.tar.gz Release notes are below. Cheers, Simon. - - version 2.73 Fix crash at startup when an empty suffix is supplied to --conf-dir, also trivial memory leak. Thanks to Tomas Hozza for spotting this. Remove floor of 4096 on advertised EDNS0 packet size when DNSSEC in use, the original rationale for this has long gone. Thanks to Anders Kaseorg for spotting this. Use inotify for checking on updates to /etc/resolv.conf and friends under Linux. This fixes race conditions when the files are updated rapidly and saves CPU by not polling. To build a binary that runs on old Linux kernels without inotify, use make COPTS=-DNO_INOTIFY Fix breakage of --domain=domain,subnet,local - only reverse queries were intercepted. THis appears to have been broken since 2.69. Thanks to Josh Stone for finding the bug. Eliminate IPv6 privacy addresses and deprecated addresses from the answers given by --interface-name. Note that reverse queries (ie looking for names, given addresses) are not affected. Thanks to Michael Gorbach for the suggestion. Fix crash in DNSSEC code with long RRs. Thanks to Marco Davids for the bug report. Add --ignore-address option. Ignore replies to A-record queries which include the specified address. No error is generated, dnsmasq simply continues to listen for another reply. This is useful to defeat blocking strategies which rely on quickly supplying a forged answer to a DNS request for certain domains, before the correct answer can arrive. Thanks to Glen Huang for the patch. Revisit the part of DNSSEC validation which determines if an unsigned answer is legit, or is in some part of the DNS tree which should be signed. Dnsmasq now works from the DNS root downward looking for the limit of signed delegations, rather than working bottom up. This is both more correct, and less likely to trip over broken nameservers in the unsigned parts of the DNS tree which don't respond well to DNSSEC queries. Add --log-queries=extra option, which makes logs easier to search automatically. Add --min-cache-ttl option. I've resisted this for a long time, on the grounds that disbelieving TTLs is never a good idea, but I've been persuaded that there are sometimes reasons to do it. (Step forward, GFW). To avoid misuse, there's a hard limit on the TTL floor of one hour. Thansk to RinSatsuki for the patch. Cope with multiple interfaces with the same link-local address. (IPv6 addresses are scoped, so this is allowed.) Thanks to Cory Benfield for help with this. Add --dhcp-hostsdir. This allows addition of new host configurations to a running dnsmasq instance much more cheaply than having dnsmasq re-read all its existing configuration each time. Don't reply to DHCPv6 SOLICIT messages if we're not configured to do stateful DHCPv6. Thanks to Win King Wan for the patch. Fix broken DNSSEC validation of ECDSA signatures. Add --dnssec-timestamp option, which provides an automatic way to detect when the system time becomes valid after boot on systems without an RTC, whilst allowing DNS queries before the clock is valid so that NTP can run. Thanks to Kevin Darbyshire-Bryant for developing this idea. Add --tftp-no-fail option. Thanks to Stefan Tomanek for the patch. Fix crash caused by looking up servers.bind, CHAOS text record, when more than about five --servers= lines are in the dnsmasq config. This causes memory corruption which causes a crash later. Thanks to Matt Coddington for sterling work chasing this down. Fix crash on receipt of certain malformed DNS requests. Thanks to Nick Sampanis for spotting the problem. Note that this is could allow the dnsmasq process's memory to be read by an attacker under certain circumstances, so it has a CVE, CVE-2015-3294 Fix crash in authoritative DNS code, if a .arpa zone is declared as authoritative, and then a PTR query
Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9
On Fri, Jun 12, 2015 at 10:18 PM, Simon Kelley si...@thekelleys.org.uk wrote: On 12/06/15 12:16, Maciej Soltysiak wrote: I think I have discovered what the problem is and it's unlikely to be dnsmasq. Without doing an exhaustive analysis (I've done too many DNSSEC post-mortems recently) that seems to a reasonable explanation. Certainly, using.dnscrypt.pl validates fine here. Right, and thanks for checking. It must be the weird thing I'm doing... Simon. Maciej ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
