[Dnsmasq-discuss] [PATCH] fix typo

[Martin Schiller]

it was introduced by commit 08933475abd0580cff747e3d1e0db3865207a200

Signed-off-by: Martin Schiller 
---
 src/dnsmasq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index aa29bbf..7fd33af 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -242,7 +242,7 @@ int main (int argc, char **argv)
 
   /* Create a serial at startup if not configured. */
 #ifdef HAVE_BROKEN_RTC
-  if (daemon_>soa_sn == 0)
+  if (daemon->soa_sn == 0)
die(_("zone serial must be configured in --auth-soa"), NULL, 
EC_BADCONF);
 #else
   if (daemon->soa_sn == 0)
-- 
2.11.0


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Ready for dnssec key signing key rollover on Oct 11?

[Uwe Schindler]

Hi,

 

by default in the Debian/Ubuntu package it looks like this:

 

root@sirius:~# dpkg -l | fgrep dnsmasq

ii  dnsmasq   2.79-1all 
 Small caching DNS proxy and DHCP/TFTP server

ii  dnsmasq-base  2.79-1
amd64Small caching DNS proxy and DHCP/TFTP server

ii  dnsmasq-utils 2.79-1
amd64Utilities for manipulating DHCP leases

 

The new anchor was included long ago:

 

root@sirius:~# cat /usr/share/dnsmasq-base/trust-anchors.conf

# The root DNSSEC trust anchor, valid as at 10/02/2017

 

# Note that this is a DS record (ie a hash of the root Zone Signing Key)

# If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml

 

trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

 

(this is shipped with the above mentioned “dnsmasq-base” package).

 

In the default config file of dnsmasq, there is this line:

 

root@sirius:/etc# cat dnsmasq.conf.dpkg-dist  | fgrep trust

#conf-file=%%PREFIX%%/share/dnsmasq/trust-anchors.conf

 

So everything is there to configure it correctly. By default DNSSEC is not 
enabled anyways, but a user who wants to enable it can easily do it by 
uncommenting and fixing the above path. IMHO, it could be improved in the 
debian package to have the correct path in the default file (instead of 
%%PREFIX%%). This looks like a bug in the debian package installer.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Dnsmasq-discuss  On 
Behalf Of Neil Jerram
Sent: Monday, October 8, 2018 12:19 PM
To: logana...@gmail.com
Cc: dnsmasq-discuss 
Subject: Re: [Dnsmasq-discuss] Ready for dnssec key signing key rollover on Oct 
11?

 

On Sun, Oct 7, 2018 at 12:05 PM Loganaden Velvindron mailto:logana...@gmail.com> > wrote:

On Sun, Oct 7, 2018 at 2:13 PM Rick Thomas mailto:rbtho...@pobox.com> > wrote:
>
> What do I need to do to be ready for the DNSSEC Root KSK (key signing key) 
> rollover on October 11, 2018?
>

Well, dnsmasq already commited a patch for the new trust anchor :

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=05da782f8f45933915af0ef3cc1ba35e31d20c59

 

I was also looking into this last week, and would appreciate if anyone wanted 
to review and confirm or correct my observations.

 

If I've understood correctly:

 

- An installation of dnsmasq can only possibly be impacted by the KSK rollover 
if it

  - was built with HAVE_DNSSEC enabled; AND

  - is configured (--dnssec) to use DNSSEC at runtime; AND

  - is actually used as a DNS server / forwarder.

 

- There is no cross-dependency between DNSSEC and dnsmasq's DHCP and RA 
function.  So if you're mainly using dnsmasq for DHCP and RA, as OpenStack 
does, that function can't be degraded by not having installed or configured the 
new DNSSEC KSK. 

 

- While it is true that the dnsmasq repo has included the new KSK fingerprint 
since February 2017 (as in the commit cited above), I couldn't see anything 
hardcoded in the dnsmasq code to read and use the content of 
trust-anchors.conf.  So, even if you have that file in your dnsmasq install, 
and it includes the new KSK fingerprint, I _think_ you still need to configure 
dnsmasq somehow to read that file and trust the fingerprints in it (presumably 
at the same time as you'd configure --dnssec).

 

Any comments much appreciated.

 

 Neil

 

 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Duplicate IP detection with fixed IP

[Bernard CLABOTS]

 Hi Simon,   I am definitely not a DHCP expert and I don't want either to 
become a pain. Yet...   I can read that not only the behavior is not inline 
with RFC, but it even contradicts the RFC:
"3.2 Client-server interaction - reusing a previously allocated network address 
  If a client remembers and wishes to reuse a previously allocated
   network address, a client may choose to omit some of the steps
   described in the previous section.  The timeline diagram in figure 4
   shows the timing relationships in a typical client-server interaction
   for a client reusing a previously allocated network address."

=> So My iPhone is legit.

"Servers with knowledge of the client's configuration parameters
  respond with a DHCPACK message to the client.  Servers SHOULD NOT
  check that the client's network address is already in use; the
  client may respond to ICMP Echo Request messages at this point."
=> Invalidates the fix you did in 2017:"
| commit 5ce3e76fbf89e942e8c54ef3e3389facf0d9067a |
| Author: Simon Kelley  |
| Date:   Fri Apr 28 22:14:20 2017 +0100 |
|   |
|     DHCPv4: do ICMP-ping check in all cases other that current lease. |

"=> This is a real Bug affecting the current behavior. I would really 
appreciate that you unlink the authoritative link to always breaking this 
statement:"Servers SHOULD NOT respond if their information is not  
_guaranteed_ to be accurate.  For example, a server that identifies a
  request for an expired binding that is owned by another server SHOULD
  NOT respond with a DHCPNAK unless the servers are using an explicit
  mechanism to maintain coherency among the servers."

I agree that the example exposes a philosophy similar to what you implemented, 
in the sense that being an authoritative server somehow fulfils the second part 
of the example, but the example is just an example. IMHO not having a trace of 
the lease in combination with being authoritative should/could be interpreted 
as a potential Rogue client attempting a MIM attack which is actually an 
accurate info to be used to NAK the request, or arguably not answer at all. 
Could you at least make this behavior configurable? Thanks a lot!!!

I am not sure I understand what the implications might be that you fear in 
NAK-ing the request.

Thanks a lot!

Regards,
Bernard

   

   
   ___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Ready for dnssec key signing key rollover on Oct 11?

[Neil Jerram]

On Sun, Oct 7, 2018 at 12:05 PM Loganaden Velvindron 
wrote:

> On Sun, Oct 7, 2018 at 2:13 PM Rick Thomas  wrote:
> >
> > What do I need to do to be ready for the DNSSEC Root KSK (key signing
> key) rollover on October 11, 2018?
> >
>
> Well, dnsmasq already commited a patch for the new trust anchor :
>
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=05da782f8f45933915af0ef3cc1ba35e31d20c59


I was also looking into this last week, and would appreciate if anyone
wanted to review and confirm or correct my observations.

If I've understood correctly:

- An installation of dnsmasq can only possibly be impacted by the KSK
rollover if it
  - was built with HAVE_DNSSEC enabled; AND
  - is configured (--dnssec) to use DNSSEC at runtime; AND
  - is actually used as a DNS server / forwarder.

- There is no cross-dependency between DNSSEC and dnsmasq's DHCP and RA
function.  So if you're mainly using dnsmasq for DHCP and RA, as OpenStack
does, that function can't be degraded by not having installed or configured
the new DNSSEC KSK.

- While it is true that the dnsmasq repo has included the new KSK
fingerprint since February 2017 (as in the commit cited above), I couldn't
see anything hardcoded in the dnsmasq code to read and use the content of
trust-anchors.conf.  So, even if you have that file in your dnsmasq
install, and it includes the new KSK fingerprint, I _think_ you still need
to configure dnsmasq somehow to read that file and trust the fingerprints
in it (presumably at the same time as you'd configure --dnssec).

Any comments much appreciated.

 Neil
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CVE-2017-14495 PoC causes high CPU usage and denial of service against dnsmasq v2.79

[Kevin Darbyshire-Bryant]

> On 8 Oct 2018, at 02:58, Mouath Ibrahim  wrote:
> 
> Hello,
> 
> I ran the PoC supplied by Google research team found here: https://github.com/
> google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/
> CVE-2017-14495.py
> 
> and noticed immediately that dnsmasq process uses up 100% CPU usage and stops 
> responding to queries short after based on the original CVE the effect was 
> high memory usage but in this cause it was not.
> 
> note dnsmasq didn't have any of these options set "--add-mac, --add-cpe-id or 
> --add-subnet".
> 
> Regards,
> Mouath Ibrahim

I am unable to reproduce.  Against which version/s of dnsmasq did you try?


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss