Re: [Dnsmasq-discuss] Integration with iptables?
Just learned about the dnsmasq ipset option. That is really cool. Thanks, Joachim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Integration with iptables?
Hi. A use case for my router would be: Block every outgoing traffic except for that going to the domain whatsapp.net. Note: No way to do this by port, whatsapp is using http(s). Since there is no way to list the hosts in a domain this would require a way for dnsmasq to talk to iptables. Any suggestions on how to do that? tail -f dnsmasq-query.log | add_iptables_rules.sh could do that, but maybe this is worth implementing a way to talk to iptables. Can iptables tag ip addresses? There are lots of similar use cases, e.g.: Block everything from my tv except for 1. the request to test network connectivity and 2. all traffic going to netflix. In general, control over the outgoing traffic needs cooperation from dns. Sincerely, Joachim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Integration with iptables?
A way to maintain ipsets via dnsmasq would for example do what I need. Sincerely, Joachim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9
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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Integration with iptables?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/06/15 08:17, Joachim Zobel wrote: A way to maintain ipsets via dnsmasq would for example do what I need. It's there already. Are you using the latest release? Look for --ipset in the man page. Simon. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVepdtAAoJEBXN2mrhkTWiQW8P/2BTLs+YIUa5b26acnw4mX0I 3+eXY2QJMtlBkC1hNPeoeoxauHx1a6UJnsS1HBloKUYUYh1lfSL7jA6jEi0nmGtw nuJ7CdZxEwDKUAT76m6ECj20poGcayOgkWcKNFuhrbck5oG3xjfuB2qFACdbEXYu T7nIhCOiKzs8zfdihUp1YgNxKfuScnQfSnJweFLL5LfCl3b12bvZ9VH2HFs0MFHd ALmyrCXo+U6ZwOpV4gmckdKfKYeLuMHMIgaw62JgkSarGURpB5t1sQeEMNSjTxQB 58pJUaQGvk3rgVXf3+jyAQWP7JG6hoGc4ixM6Kx0mNjUgQmkrWN5DUSlxhaF6JXq b1G52zQ0wYtEEFSlyxwWs9Y3lZY2fOZqU4KpQHbRCRLtx9EFwnkXoD7GeEeWhrBo zZ7Hs3vUQh8dqW2rhxhoeWx85NaPlpF1RaiwjSmDHXuaOo++vrIWeyLf2fbIcnu0 XqIYioLmJj16Ng8SV4CTAxeb7o4+p5x1eol1kX6RXSNlJEJfczuQ4pBWTYW6e/sD rPtvHcyPER9dh4ATF/CuhBZkFjUSymfpIqlCwdang6u4OXseRn7Gwq7fC5Rhhtfa T5HlPZMqe93rPhKOHsFCcfT7gzHLI79BgF3HJ0+WC/qzImDkwYOt1iXtFNmX0eaY 1pI0ZbXUt2SSKd3c0gAG =UBMT -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Serving DHCP requests from a subnet not matching the interface
Hi Johannes, Sorry, I've only just noticed this... On 03/06/15 06:52, Johannes Martin wrote: Hi, I have the following network setup: - eth0: 192.168.1.254/24 - br0: 192.168.10.254/24 bridging virtual interfaces eth0.10 and wlan0.10 (plain virtual interfaces, no vlan tagging) I have a dynamic dhcp range defined on the 192.168.1.0 subnet and a static dhcp range with static host entries (by mac address) defined on the 192.168.10.0 subnet. When a device connects through the wlan0 interface, dnsmasq properly serves the defined static addresses. However, when the devices connects through the eth0 interface, dnsmasq serves an address from the dynamic range even when a static address is defined for the device. So, dnsmasq does not realize that eth0 and eth0.10 are the same physical interface and that it is fine to serve an address that is valid only for eth0.10 on that physical interface. I wonder if --bridge-interface=br0,eth0 would do what you want? Except that I don't understand when you would actually _want_ a dynamic allocation from 192.168.1/24. I think that using --bridge-interface would mean that you'd _never_ get an allocation from 192.168.1/24. Regards, Neil ___ 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
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? 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 ___ 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
Thanks Toke, finding these failure cases and fixing them, one at a time, is very necessary, but somewhat gruelling. In this case, database.srku.dk. is a CNAME for database.studenterraad.dk. and that's a CNAME for web21.sd.eurovps.com. 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 A query for the DS records of .dk and .srku.dk give DS records, database.srku.dk. gives ;; QUESTION SECTION: ;database.srku.dk. IN DS ;; ANSWER SECTION: database.srku.dk. 21599 IN CNAME database.studenterraad.dk. database.srku.dk. 21599 IN RRSIG CNAME 5 3 43200 20150706020221 20150606020221 37065 srku.dk. edqGhVL0fNgBerYXlo8X2dV00DJ5c7cw31IT5zhAx0SMK7VXUw9/WwMg ltYJnn0Xbo8uLr73KB1758PBpMQ0Jg== database.studenterraad.dk. 21599 IN CNAME web21.sd.eurovps.com. database.studenterraad.dk. 21599 IN RRSIG CNAME 5 3 43200 20150711144201 20150611144201 36045 studenterraad.dk. czsVXeiOz5ZzMe830RUeMc6lT+ZsFDn6HzttyxvR2IXxeD3W4965JzA2 aTYWuW/Y3/W/7AHfC9vd6L0yi4HlBw== ;; AUTHORITY SECTION: eurovps.com.59 IN SOA ns2.eurovps.com. supervisor.eurovps.com. 2015060400 14400 7200 604800 1800 So, signed proof that the DS should be in eurovps.com. Finally, a query for DS eurovps.com. gives ;; QUESTION SECTION: ;eurovps.com. IN DS ;; AUTHORITY SECTION: CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 21599 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 21599 IN RRSIG NSEC3 8 2 86400 20150617050222 20150610035222 33878 com. BmRR63rU6MqGAP9OAIhSPYjyM6iA1luC5NmUC3+GVlu2al8QbB2e5qAj cVZnVsV3+GmRY0XPm1p2dEwW1tlMai2zU0Z+bo8EnMK7l95riZ/CRrQz /btectiRyve7gL1jYgUrprivGuA5lHHCaHDufqcphbqOBQc2vGgf5b0Q msM= com.899 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1434140903 1800 900 604800 86400 com.899 IN RRSIG SOA 8 1 900 20150619202823 20150612191823 33878 com. MkHrPzyePiZPSJ+L6ikL6mgyJIncZCj2J6I6iP3MPU2K1u6L3zaERQjM WYMD3mozBp23MsWJ6B4Y2MAAFa48Cox744ZaL/tu/Gi07FeDNEV5qlIJ VS3bgocZ3ZBRQyIY+NkxsmXBuzLB3dnbDKKewTkW8uOqcVlcePxuoeJ6 UdU= 1KHVDCFLLCJPF012Q9NBF47HKCHQJ9O3.com. 21599 IN NSEC3 1 1 0 - 1KI1CILTVQVH1Q1MTU3R9OCHA1FLB28R NS DS RRSIG 1KHVDCFLLCJPF012Q9NBF47HKCHQJ9O3.com. 21599 IN RRSIG NSEC3 8 2 86400 20150618042727 20150611031727 33878 com. q8FFRw2b/pE/6n2S1GwetYD+NXzOA7BS0LeKDblxlgOwx7G6yl9u0euE FH93Q0aw36nUjGp9YRRu6ZjriJHQR6a5wawYvOBe74IZQhJ8XBwkhQ76 GbEDQB8Tv6p43seg8nnbhmJp61/OLa5CM0t1pQ9yUvhkquaPXv8vvIs+ e7M= Proof that there's no DS, so the original, unvalidatable answer can stand. 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. Cheers, Simon. dnsmasq: query[A] database.srku.dk from 127.0.0.1 dnsmasq: forwarded database.srku.dk to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] srku.dk to 8.8.8.8 dnsmasq: dnssec-query[DS] srku.dk to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] dk to 8.8.8.8 dnsmasq: dnssec-query[DS] dk to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] . to 8.8.8.8 dnsmasq: reply . is DNSKEY keytag 48613 dnsmasq: reply . is DNSKEY keytag 19036 dnsmasq: reply dk is DS keytag 61294 dnsmasq: reply dk is DNSKEY keytag 40794 dnsmasq: reply dk is DNSKEY keytag 61294 dnsmasq: reply dk is DNSKEY keytag 1804 dnsmasq: reply dk is DNSKEY keytag 52689 dnsmasq: reply srku.dk is DS keytag 2083 dnsmasq: reply srku.dk is DNSKEY keytag 37065 dnsmasq: reply srku.dk is DNSKEY keytag 2083 dnsmasq: dnssec-query[DNSKEY] studenterraad.dk to 8.8.8.8 dnsmasq: dnssec-query[DS] studenterraad.dk to 8.8.8.8 dnsmasq: reply studenterraad.dk is DS keytag 12253 dnsmasq: reply studenterraad.dk is DNSKEY keytag 36045 dnsmasq: reply studenterraad.dk is DNSKEY keytag 12253 dnsmasq: dnssec-query[DS] database.studenterraad.dk to 8.8.8.8 dnsmasq: dnssec-query[DS] com to 8.8.8.8 dnsmasq: reply com is DS keytag 30909 dnsmasq: dnssec-query[DS] eurovps.com to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] com to 8.8.8.8 dnsmasq: reply com is DNSKEY keytag 33878 dnsmasq: reply com is DNSKEY keytag 30909 dnsmasq: reply eurovps.com is no DS dnsmasq: validation result is INSECURE dnsmasq: reply database.srku.dk is CNAME dnsmasq: reply database.studenterraad.dk is CNAME dnsmasq: reply web21.sd.eurovps.com is 77.235.54.116 On 11/06/15 17:03, Toke Høiland-Jørgensen wrote: So I'm getting getting DNSSEC failures when trying to lookup the domain 'database.srku.dk'. 'dnssec' and 'dnssec-check-unsigned' are both enabled in the dnsmasq config. The relevant dnsmasq log with log-queries enabled: Jun 11 17:56:35 gauss dnsmasq[29455]: query[A] database.srku.dk from 10.42.8.5 Jun 11 17:56:35 gauss dnsmasq[29455]: forwarded database.srku.dk to ::1 Jun 11 17:56:35 gauss dnsmasq[29455]:
Re: [Dnsmasq-discuss] local-service feature doesn't detect new/changed interfaces/networks
Current versions of dnsmasq have an alternative to --bind-interfaces, called --bind-dynamic, which should solve this problem, I think. --bind-dynamic Enable a network mode which is a hybrid between --bind-interfaces and the default. Dnsmasq binds the address of individual interfaces, allowing multiple dnsmasq instances, but if new interfaces or addresses appear, it auto‐ matically listens on those (subject to any access-control configuration). This makes dynamically created inter‐ faces work in the same way as the default. Implementing this option requires non-standard networking APIs and it is only available under Linux. On other platforms it falls-back to --bind-interfaces mode. Cheers, Simon. On 11/06/15 10:24, Timothy White wrote: Hi Simon I'm not sure if this will be related to the issue Tong had earlier this year. I have a piece of software (the Grase Hotspot project) the relies on dnsmasq to serve the local clients. In theory, the local-service feature shouldn't hurt this. However, dnsmasq is starting before the Coova Chilli software has finished bring up it's tun interface, which is where the client network IP is. Because the interface comes up after dnsmasq, it doesn't do anything to bind to it, (if bind-interfaces is on), and also doesn't add the network on the interface to the local networks list. Ideally, dnsmasq would detect a new interface, or a network change, and rebuild it's local networks list, for clients it'll answer queries for. Alternatively, being able to specify a list of local networks in the config file (forgive me if this exists, I couldn't find it in the man page), that it'll always answer queries on, regardless of the local-service argument, would also solve this. We know at the time that dnsmasq is started what the network IP will be, as we already drop a config file in /etc/dnsmasq.d/ that contains settings from the Hotspot. If I could force a network range to be considered local in the config files, I can easily have it in that file. So, after a reboot, dnsmasq starts before tun0 has it's ip. DNS requests from clients on the tun0 network result in no reply, and Ignoring query from non-local network being logged in syslog. A restart of dnsmasq after tun0 has it's ip results in clients successfully being able to use dnsmasq. I'm hoping to be able to avoid the need to manually send a signal to dnsmasq, and that it can detect the network changes itself. Otherwise, I'll have to work out some hack to either delay dnsmasq long enough for tun0 to come up, or hope I can hook into another part of the code that should be run after tun0 is up. Regards Tim ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ 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
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. 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? 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. dnsmasq: query[A] using.dnscrypt.pl from 127.0.0.1 dnsmasq: forwarded using.dnscrypt.pl to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] dnscrypt.pl to 8.8.8.8 dnsmasq: dnssec-query[DS] dnscrypt.pl to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] pl to 8.8.8.8 dnsmasq: dnssec-query[DS] pl to 8.8.8.8 dnsmasq: dnssec-query[DNSKEY] . to 8.8.8.8 dnsmasq: reply . is DNSKEY keytag 48613 dnsmasq: reply . is DNSKEY keytag 19036 dnsmasq: reply pl is DS keytag 52250 dnsmasq: reply pl is DS keytag 52250 dnsmasq: reply pl is DNSKEY keytag 61416 dnsmasq: reply pl is DNSKEY keytag 6418 dnsmasq: reply pl is DNSKEY keytag 14899 dnsmasq: reply pl is DNSKEY keytag 52250 dnsmasq: reply dnscrypt.pl is DS keytag 65416 dnsmasq: reply dnscrypt.pl is DS keytag 65416 dnsmasq: reply dnscrypt.pl is DNSKEY keytag 65416 dnsmasq: reply dnscrypt.pl is DNSKEY keytag 3668 dnsmasq: reply dnscrypt.pl is DNSKEY keytag 43164 dnsmasq: reply dnscrypt.pl is DNSKEY keytag 64611 dnsmasq: validation result is SECURE dnsmasq: reply using.dnscrypt.pl is CNAME dnsmasq: reply not-using.dnscrypt.pl is 188.226.192.48 Cheers, Simon. 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.48using.dnscrypt.pl 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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
