Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69

2014-04-12 Thread Brad Smith

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

2014-04-11 Thread Stéphane Guedon
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 of full-time work to get it to a workable state.
 
 Add --rev-server. Thanks to Dave Taht for 

[Dnsmasq-discuss] Announce: dnsmasq-2.69

2014-04-09 Thread Simon Kelley
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 

Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69

2014-04-09 Thread Simon Kelley
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


Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69

2014-04-09 Thread Dave Reisner
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