Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69
On 11/04/14 5:42 AM, Stéphane Guedon wrote: Good ! But anyway, we still need a resolver. Why not considering making dnsmasq acting as resolver itself too ? It is outside of the scope of what dnsmasq is for. Thanks for your work (didn't tried the release, but you deserve some congrats...)! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69
Le mercredi 9 avril 2014, 21:13:33 Simon Kelley a écrit : > Dnsmasq-2.69 is here. > > http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz > > and (new) a signature > > http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz.sign > > > Many thanks to all who've contributed this major milestone. Most are > mentioned in the CHANGELOG, but it's also necessary to thank Evan > Hunt, Dave Taht, Giovanni Bajo and Comcast. > > Release notes below. > > Cheers, > > Simon. > > > -- > > version 2.69 > Implement dynamic interface discovery on *BSD. This > allows the contructor: syntax to be used in dhcp-range for DHCPv6 > on the BSD platform. Thanks to Matthias Andree for valuable > research on how to implement this. > > Fix infinite loop associated with some --bogus-nxdomain > configs. Thanks fogobogo for the bug report. > > Fix missing RA RDNS option with configuration like > --dhcp-option=option6:23,[::] Thanks to Tsachi > Kimeldorfer for spotting the problem. > > Add [fd00::] and [fe80::] as special addresses in DHCPv6 > options, analogous to [::]. [fd00::] is replaced with the actual > ULA of the interface on the machine running dnsmasq, [fe80::] with > the link-local address. Thanks to Tsachi Kimeldorfer for > championing this. > > DNSSEC validation and caching. Dnsmasq needs to be > compiled with this enabled, with > > make dnsmasq COPTS=-DHAVE_DNSSEC > > this add dependencies on the nettle crypto library and > the gmp maths library. It's possible to have these linked > statically with > > make dnsmasq COPTS='-DHAVE_DNSSEC -DHAVE_DNSSEC_STATIC' > > which bloats the dnsmasq binary, but saves the size of > the shared libraries which are much bigger. > > To enable, DNSSEC, you will need a set of > trust-anchors. Now that the TLDs are signed, this can be > the keys for the root zone, and for convenience they are included > in trust-anchors.conf in the dnsmasq > distribution. You should of course check that these are > legitimate and up-to-date. So, adding > > conf-file=/path/to/trust-anchors.conf > dnssec > > to your config is all thats needed to get things > working. The upstream nameservers have to be > DNSSEC-capable too, of course. Many ISP nameservers aren't, but the > Google public nameservers (8.8.8.8 and 8.8.4.4) are. When DNSSEC is > configured, dnsmasq validates any queries for domains which are > signed. Query results which are bogus are replaced with SERVFAIL > replies, and results which are correctly signed have the AD bit > set. In addition, and just as importantly, dnsmasq supplies correct > DNSSEC information to clients which are doing their own validation, > and caches DNSKEY, DS and RRSIG records, which significantly > improve the performance of downstream validators. Setting > --log-queries will show DNSSEC in action. > > If a domain is returned from an upstream nameserver > without DNSSEC signature, dnsmasq by default trusts this. This > means that for unsigned zone (still the majority) there is > effectively no cost for having DNSSEC enabled. Of course this > allows an attacker to replace a signed record with a false unsigned > record. This is addressed by the --dnssec-check-unsigned flag, > which instructs dnsmasq to prove that an unsigned record is > legitimate, by finding a secure proof that the zone containing the > record is not signed. Doing this has costs (typically one or two > extra upstream queries). It also has a nasty failure mode if > dnsmasq's upstream nameservers are not DNSSEC capable. Without > --dnssec-check-unsigned using such an upstream server will simply > result in not queries being validated; with --dnssec-check-unsigned > enabled and a > DNSSEC-ignorant upstream server, _all_ queries will > fail. > > Note that DNSSEC requires that the local time is valid > and accurate, if not then DNSSEC validation will fail. NTP should > be running. This presents a problem for routers without a > battery-backed clock. To set the time needs NTP to do DNS lookups, > but lookups will fail until NTP has run. To address this, there's a > flag, --dnssec-no-timecheck which disables the time checks (only) > in DNSSEC. When dnsmasq is started and the clock is not synced, > this flag should be used. As soon as the clock is synced, SIGHUP > dnsmasq. The SIGHUP clears the cache of partially- validated data > and resets the no-timecheck flag, so that all DNSSEC checks > henceforward will be complete. > > The development of DNSSEC in dnsmasq was started by > Giovanni Bajo, to whom huge thanks are owed. It has been > supported by Comcast, whose techfund grant has allowed for an > invaluable period
Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69
On Wed, Apr 09, 2014 at 09:36:08PM +0100, Simon Kelley wrote: > On 09/04/14 21:32, Dave Reisner wrote: > > On Wed, Apr 09, 2014 at 09:13:33PM +0100, Simon Kelley wrote: > >> Dnsmasq-2.69 is here. > >> > >> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz > >> > >> and (new) a signature > >> > >> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz.sign > >> > > > > Hi Simon, > > > > Thanks for providing GPG signatures for the source tarballs. Could I ask > > why you've chosen this particular extension? > > Ignorance, plain and simple. I'm new to this stuff, and not familiar > with the conventions. > > > GPG normally expects .asc > > (ascii armored) or .sig (raw binary) extensions so this is somewhat > > unexpexcted. Verification still works, but it's not documented anywhere > > in gpg's manpage as an expected extension. To complicate matters > > somewhat more, kernel.org uses .sign as an extension but treats the > > situation differently -- they provide a single .sign file but multiple > > compression formats for the source tarballs. The signature validates > > against the decompressed tarball. This doesn't seem to be the case here, > > as the .sign validates against the gzip tarball. > > > > I humbly ask that you use .asc for the signature. > > > Sounds sensible, I'll change it now, before any dependencies form on my > initial setup. Great! Thanks for the quick turnaround! > > > Cheers, > > > Simon. > > > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69
On 09/04/14 21:32, Dave Reisner wrote: > On Wed, Apr 09, 2014 at 09:13:33PM +0100, Simon Kelley wrote: >> Dnsmasq-2.69 is here. >> >> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz >> >> and (new) a signature >> >> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz.sign >> > > Hi Simon, > > Thanks for providing GPG signatures for the source tarballs. Could I ask > why you've chosen this particular extension? Ignorance, plain and simple. I'm new to this stuff, and not familiar with the conventions. > GPG normally expects .asc > (ascii armored) or .sig (raw binary) extensions so this is somewhat > unexpexcted. Verification still works, but it's not documented anywhere > in gpg's manpage as an expected extension. To complicate matters > somewhat more, kernel.org uses .sign as an extension but treats the > situation differently -- they provide a single .sign file but multiple > compression formats for the source tarballs. The signature validates > against the decompressed tarball. This doesn't seem to be the case here, > as the .sign validates against the gzip tarball. > > I humbly ask that you use .asc for the signature. > Sounds sensible, I'll change it now, before any dependencies form on my initial setup. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Announce: dnsmasq-2.69
Dnsmasq-2.69 is here. http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz and (new) a signature http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.69.tar.gz.sign Many thanks to all who've contributed this major milestone. Most are mentioned in the CHANGELOG, but it's also necessary to thank Evan Hunt, Dave Taht, Giovanni Bajo and Comcast. Release notes below. Cheers, Simon. -- version 2.69 Implement dynamic interface discovery on *BSD. This allows the contructor: syntax to be used in dhcp-range for DHCPv6 on the BSD platform. Thanks to Matthias Andree for valuable research on how to implement this. Fix infinite loop associated with some --bogus-nxdomain configs. Thanks fogobogo for the bug report. Fix missing RA RDNS option with configuration like --dhcp-option=option6:23,[::] Thanks to Tsachi Kimeldorfer for spotting the problem. Add [fd00::] and [fe80::] as special addresses in DHCPv6 options, analogous to [::]. [fd00::] is replaced with the actual ULA of the interface on the machine running dnsmasq, [fe80::] with the link-local address. Thanks to Tsachi Kimeldorfer for championing this. DNSSEC validation and caching. Dnsmasq needs to be compiled with this enabled, with make dnsmasq COPTS=-DHAVE_DNSSEC this add dependencies on the nettle crypto library and the gmp maths library. It's possible to have these linked statically with make dnsmasq COPTS='-DHAVE_DNSSEC -DHAVE_DNSSEC_STATIC' which bloats the dnsmasq binary, but saves the size of the shared libraries which are much bigger. To enable, DNSSEC, you will need a set of trust-anchors. Now that the TLDs are signed, this can be the keys for the root zone, and for convenience they are included in trust-anchors.conf in the dnsmasq distribution. You should of course check that these are legitimate and up-to-date. So, adding conf-file=/path/to/trust-anchors.conf dnssec to your config is all thats needed to get things working. The upstream nameservers have to be DNSSEC-capable too, of course. Many ISP nameservers aren't, but the Google public nameservers (8.8.8.8 and 8.8.4.4) are. When DNSSEC is configured, dnsmasq validates any queries for domains which are signed. Query results which are bogus are replaced with SERVFAIL replies, and results which are correctly signed have the AD bit set. In addition, and just as importantly, dnsmasq supplies correct DNSSEC information to clients which are doing their own validation, and caches DNSKEY, DS and RRSIG records, which significantly improve the performance of downstream validators. Setting --log-queries will show DNSSEC in action. If a domain is returned from an upstream nameserver without DNSSEC signature, dnsmasq by default trusts this. This means that for unsigned zone (still the majority) there is effectively no cost for having DNSSEC enabled. Of course this allows an attacker to replace a signed record with a false unsigned record. This is addressed by the --dnssec-check-unsigned flag, which instructs dnsmasq to prove that an unsigned record is legitimate, by finding a secure proof that the zone containing the record is not signed. Doing this has costs (typically one or two extra upstream queries). It also has a nasty failure mode if dnsmasq's upstream nameservers are not DNSSEC capable. Without --dnssec-check-unsigned using such an upstream server will simply result in not queries being validated; with --dnssec-check-unsigned enabled and a DNSSEC-ignorant upstream server, _all_ queries will fail. Note that DNSSEC requires that the local time is valid and accurate, if not then DNSSEC validation will fail. NTP should be running. This presents a problem for routers without a battery-backed clock. To set the time needs NTP to do DNS lookups, but lookups will fail until NTP has run. To address this, there's a flag, --dnssec-no-timecheck which disables the time checks (only) in DNSSEC. When dnsmasq is started and the clock is not synced, this flag should be used. As soon as the clock is synced, SIGHUP dnsmasq. The SIGHUP clears the cache of partially- validated data and reset
