Re: [Dnsmasq-discuss] [PATCH] Don't advertise a default v6 route with no routeable prefixes

[Lonnie Abelbeck]

> On Jan 14, 2023, at 8:44 AM, Buck Horn  wrote:
> 
> On 14.01.2023 12:40:18, Chris Webb wrote:
> 
>> If we are advertising local (ULA) prefixes but no globally-routeable
>> prefixes, we should similarly not configure clients with a default route.
>> Set the router lifetime to zero in this case too.
> 
> I disagree here.
> 
> While ULAs are not routable on the global Internet, they can be used within 
> private scopes, like a same-site network with multiple routers/segments, or 
> even spanning multiple geographically distributed networks within the same 
> organisation.
> This is one of the design goals of ULA, avoiding some of the drawbacks of the 
> previous attempt of IPv6 site-local addresses (deprecated fec0::/10).
> 
> Quoting from RFC4193 'Unique Local IPv6 Unicast Addresses':
> 
> >  This document defines an IPv6 unicast address format that is globally
> >  unique and is intended for local communications [IPV6]. These
> >  addresses are called Unique Local IPv6 Unicast Addresses and are
> >  abbreviated in this document as Local IPv6 addresses.  They are not
> >  expected to be routable on the global Internet.  They are routable
> >  inside of a more limited area such as a site.  They may also be
> >  routed between a limited set of sites.
> 
> and further down:
> 
> > In practice, applications may treat these addresses like global scoped 
> > addresses.
> 
> Wouldn't it thus seem more sensible to keep advertising a non-zero router 
> lifetime along with a ULA prefix for a dnsmasq instance running on a router?
> 
> Kind regards,
>Buck

Nicely described, Buck.

For years I have used only ULAs for local networks (and VPNs) and at the edge 
enable Network Prefix Translation (NPTv6) to assign static local routable IPv6 
subnets to have their prefix mapped 1:1 to Global Unicast Addresses (GUA) for 
global Internet access.

The GUA prefix can change and the NPTv6 adapts.

Works well for me.

Lonnie



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

Re: [Dnsmasq-discuss] [PATCH] Heap use after free in dhcp6_no_relay (CVE-2022-0934)

[Lonnie Abelbeck]

Hey Petr,

Your analysis is much appreciated!  Thank you.

Lonnie


> On Apr 2, 2022, at 10:01 AM, Petr Menšík  wrote:
> 
> Hi Lonnie,
> 
> I made just quick evaluation, but it does not seem possible. It happens
> during creating a reply to dhcp message. ra-only ranges should not
> create DHCP range, which would accept incoming message. It should log
> message "no address range available for DHCPv6 request" followed by some
> detail. If it does so, then it avoids function where only it may happen.
> 
> If no DHCP6 messages are involved, this vulnerability cannot be
> triggered. ra-only should only broadcast its prefix(es) to end stations
> without accepting messages from them. It should be safe.
> 
> Regards,
> Petr
> 
> On 4/1/22 16:37, Lonnie Abelbeck wrote:
>>> On Mar 31, 2022, at 2:04 PM, Petr Menšík  wrote:
>>> 
>>> Possible vulnerability were found in latest dnsmasq. It were found with 
>>> help of oss-fuzz Google project by me and short after that independently 
>>> also by Richard Johnson of Trellix Threat Labs.
>>> 
>>> It is affected only by DHCPv6 requests, which could be crafted to modify 
>>> already freed memory. Red Hat security assigned this vulnerability 
>>> CVE-2022-0934.
>> Are dnsmasq IPv6 configs *only* using "ra-only" (ex.):
>> --
>> dhcp-range=...,ra-only,64,24h
>> --
>> Immune from CVE-2022-0934 ?
>> 
>> Lonnie
>> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 
> 


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

Re: [Dnsmasq-discuss] [PATCH] Heap use after free in dhcp6_no_relay (CVE-2022-0934)

[Lonnie Abelbeck]

> On Mar 31, 2022, at 2:04 PM, Petr Menšík  wrote:
> 
> Possible vulnerability were found in latest dnsmasq. It were found with help 
> of oss-fuzz Google project by me and short after that independently also by 
> Richard Johnson of Trellix Threat Labs.
> 
> It is affected only by DHCPv6 requests, which could be crafted to modify 
> already freed memory. Red Hat security assigned this vulnerability 
> CVE-2022-0934.

Are dnsmasq IPv6 configs *only* using "ra-only" (ex.):
--
dhcp-range=...,ra-only,64,24h
--
Immune from CVE-2022-0934 ?

Lonnie


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

Re: [Dnsmasq-discuss] Feature request = block-conf

[Lonnie Abelbeck]

> On Feb 5, 2022, at 5:32 AM, Simon Kelley  wrote:
> 
> Let's try thinking out of the box here. Given the motivation to save storage, 
> I was wondering if there could be a way to use compression, gzip etc to save 
> more space.
> 
> Building a decompressor into dnsmasq seems ugly, but then I came up with the 
> option of --conf-script=/path/to/script.

The 'zcat' utility is ubiquitous, no command-line options required ... could be 
called by dnsmasq directly with a "block-conf" file suffix of .gz, .bz2 or .xz 
.  Also 'zcat' returns non-zero for "no gzip/bzip2/xz magic"

> Opinions, all?

Consider processing a "block-conf" file (no text other than one domain/line) 
and with the proper file suffix pre-processed using 'zcat'.

Lonnie


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

Re: [Dnsmasq-discuss] dnsmasq v2.86?

[Lonnie Abelbeck]

Hi Andre, et al.

> On Aug 11, 2021, at 1:36 AM, Andre Heider  wrote:
> 
> I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are 
> vague so far but ever since I've started DoT with stubby as upstream server, 
> dnsmasq every now and then gets into a mode where it stops responding to 
> request completely and just sits there using 100% cpu power on one core.
> I haven't found a way yet to trigger that reliably, but it feels like 
> timing/parallel requests.
> 
> Does that ring any bells?

Our project experienced a similar issue (pre-2021) when we used dnsmasq->stubby 
for DoT, at the time we were using dnsmasq 2.82 and getdns/stubby 1.5.2/0.2.6.

The issue was upstream DNS would randomly "stall", it could be a couple days, a 
week or a month before the "stall" reoccured.  The DoT provider also seemed to 
make a difference ... for example it stalled more often with Quad9 than with 
Cloudflare.

Keeping all things equal, we tested using unbound 1.13.0 (now 1.13.1) 
configured only as a DoT forwarder (forward-zone:) replacing getdns/stubby and 
the random stalls no longer occurred.  This dnsmasq->unbound(DoT) is now our 
production implementation for upstream DoT.

Side notes:
1) Our project used libunbound previously, so building the extra unbound daemon 
added about the same amount of code as the removed getdns/stubby code.

2) As of unbound 1.13.0, its DoT features are on par with stubby, ex. stream 
reuse and tcp fast open.

3) Our default DNS is provided by dnsmasq, only upstream DoT users start the 
unbound daemon.

4) Additionally, getdns/stubby dropping autotools (in favor of cmake) was a 
thorn in my paw.


I personally use dnsmasq->unbound(DoT) and no issues since dropping 
getdns/stubby at the end of 2020.

Lonnie


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

Re: [Dnsmasq-discuss] Is there a way to run dnsmasq in safe mode (no-fail)?

[Lonnie Abelbeck]

> On May 23, 2021, at 12:47 PM, Cyberfusion  wrote:
> 
>> Op 23 mei 2021 om 19:31 heeft Lonnie Abelbeck  
>> het volgende geschreven:
>> 
>>> On May 23, 2021, at 11:08 AM, Cyberfusion  wrote:
>>> 
>>> Maybe it’s better to always validate the config before you restart dnsmasq. 
>> 
>> # dnsmasq --test   
>> dnsmasq: syntax check OK.
> 
> Then the solution is to fix config validation, not add an option to ignore 
> errors.

I was just indicating dnsmasq had a validation test, builtin.

Best if the original reporter (Ercolino) could recreate the syntax error and 
see if --test flags it.


Lonnie





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

Re: [Dnsmasq-discuss] Is there a way to run dnsmasq in safe mode (no-fail)?

[Lonnie Abelbeck]

> On May 23, 2021, at 11:08 AM, Cyberfusion  wrote:
> 
> Maybe it’s better to always validate the config before you restart dnsmasq. 

# dnsmasq --test   
dnsmasq: syntax check OK.



Lonnie

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

Re: [Dnsmasq-discuss] Doing a split zone config

[Lonnie Abelbeck]

> On Mar 29, 2021, at 9:19 AM, Roland Giesler  wrote:
> 
> On Mon, 29 Mar 2021 at 08:52, Geert Stappers via Dnsmasq-discuss 
>  wrote:
> On Sun, Mar 28, 2021 at 10:11:01PM +0200, Roland Giesler wrote:
> > Is it possible to set up a split zone in dnsmasq?
> >

Yes, you can.

For split-horizon DNS, I define local IPv4 and IPv6 hosts in the /etc/hosts 
file.  dnsmasq can look at /etc/hosts first and will use it if found, else it 
will look upstream.

Lonnie



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

Re: [Dnsmasq-discuss] How to add AAAA record for host with dynamic prefix?

[Lonnie Abelbeck]

> On Feb 26, 2021, at 9:59 AM, Fred F  wrote:
> 
> Hi Matthias,
> 
> unfortunately I need the global addresses in DNS, as that's the only
> way for me to reference the hosts in firewall rules (FreeBSD's packet
> filter supports DNS aliases natively). So unfortunately ULA does not
> help in this situation. I need global IPv6 addresses (with dynamic
> prefixes) in DNS.
> 
> 
> Thanks and best regards,
> Frederik

Hi Fred,

I have a similar situation as you, and for years have implemented IPv6 NPTv6 
(Network Prefix Translation) at the edge ... the  NPTv6 mapping is 
automatically updated when my GUA Prefix changes.

All my internal IPv6 addresses, firewall rules, etc., are ULA.  This is 
particularly useful for supporting failover external interfaces, and VPNs.

The "con", (maybe a "pro") is most network stacks choose GUA-IPv6 over IPv4, 
but IPv4 over ULA-IPv6.

Lonnie


___
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.84

[Lonnie Abelbeck]

> On Jan 25, 2021, at 5:21 PM, Lonnie Abelbeck  
> wrote:
> 
> 
>> Get it here:
>> 
>> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.84.tar.gz
> 
> The version string generated is "2.84rc2"
> 
> $ cat dnsmasq-2.84/VERSION 
> (HEAD -> master, tag: v2.84rc2, tag: v2.84, origin/master, origin/HEAD)

This patch solves the problem:

--- dnsmasq-2.84/bld/get-version.orig   2021-01-25 17:35:04.882908877 -0600
+++ dnsmasq-2.84/bld/get-version2021-01-25 17:35:58.658467974 -0600
@@ -28,7 +28,7 @@
  vers=`cat $1/VERSION | sed 's/[(), ]/,/ g' | tr ',' '\n' | grep ^v[0-9]`
 
  if [ $? -eq 0 ]; then
- echo "${vers}" | sort -r | head -n 1 | sed 's/^v//'
+ echo "${vers}" | sort | head -n 1 | sed 's/^v//'
  else
  cat $1/VERSION
  fi



Lonnie


___
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.84

[Lonnie Abelbeck]

> Get it here:
> 
> http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.84.tar.gz

The version string generated is "2.84rc2"

$ cat dnsmasq-2.84/VERSION 
 (HEAD -> master, tag: v2.84rc2, tag: v2.84, origin/master, origin/HEAD)


Lonnie


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

Re: [Dnsmasq-discuss] v2.83 failed to send packet: Network is unreachable

[Lonnie Abelbeck]

> On Jan 22, 2021, at 4:33 PM, Simon Kelley  wrote:
> 
> Apolgies about your wasted time. Once more with 2.84test3 ?

Thanks Simon, 2.84test3 solves all "failed to send packet" logs in my testing 
...
--
Jan 22 18:44:22 gw-lan daemon.info dnsmasq[3297]: started, version 2.84test3 
cachesize 4096
Jan 22 18:44:22 gw-lan daemon.info dnsmasq[3297]: compile time options: IPv6 
GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack 
ipset auth no-nettlehash no-DNSSEC loop-detect inotify no-dumpfile
--

Thanks for the prompt fix!

Lonnie


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

Re: [Dnsmasq-discuss] v2.83 failed to send packet: Network is unreachable

[Lonnie Abelbeck]

I'm able to reproduce this 2.83 issue, with both errors:
--
Jan 22 09:00:06 gw-lan daemon.err dnsmasq[19230]: failed to send packet: 
Network is unreachable
Jan 22 09:00:06 gw-lan daemon.err dnsmasq[19230]: failed to send packet: 
Network is unreachable
Jan 22 09:00:19 gw-lan daemon.err dnsmasq[19230]: failed to send packet: 
Address family not supported by protocol
Jan 22 09:00:19 gw-lan daemon.err dnsmasq[19230]: failed to send packet: 
Address family not supported by protocol
--
Reverting back to 2.82, the error logs do not appear, no issue.

I normally use "dns-forward-max=512" but tested with "dns-forward-max=2048", no 
effect on the 2.83 issue.

My testing also showed this has nothing to do with proxy-forwarding on 
127.0.0.1#2853 vs. public DNS IPs, same 2.83 issue.


Test method to generate 2.83 issue:

Using an ethernet connected computer to the dnsmasq box, in a browser run Steve 
Gibson's "DNS Nameserver Spoofability Test"...

DNS Nameserver Spoofability Test
https://www.grc.com/dns/dns.htm
(scroll to bottom and click Initiate... button)

This always generates around 40 "failed to send packet" logs with 2.83 in my 
tests.

Interestingly, my WiFi connected MacBook Air over WireGuard does not generate 
any "failed to send packet" logs with the same test. So a direct ethernet 
connection with a non-wimpy computer is required.

Hopefully Simon (et al.) can reproduce this and provide a fix.

This log occurs in send_from() in src/forward.c . Many forward.c changes have 
occurred with 2.82 -> 2.83, but the function send_from() itself is unchanged.

Lonnie



> On Jan 21, 2021, at 8:14 PM, Steve Hirsch  wrote:
> 
> Hi Lonnie, 
>  
> I am also seeing an occasional “failed to send packet: Address family not 
> supported by protocol”.  However, it is mostly “Network Unreachable” and they 
> are pretty continuous (much more than the 10 you have).  Dnscrypt is 
> configured to use DoH to cloudflare servers.  On my side, doesn’t seem to be 
> related to activity level…low levels of activity also generates errors.
>  
> From: Lonnie Abelbeck
> Sent: Thursday, January 21, 2021 6:42 PM
> To: dnsmasq list
> Cc: Steve Hirsch
> Subject: Re: [Dnsmasq-discuss] v2.83 failed to send packet: Network is 
> unreachable
>  
> 
> 
> > On Jan 21, 2021, at 5:53 PM, Steve Hirsch  wrote:
> > 
> > After upgrading dnsmasq from version 2.82 to version 2.83 on Arch Linux 
> > (kernel 5.10.9), “failed to send packet: Network is unreachable” errors 
> > continually show up.  However, name resolution still appears to work with 
> > v2.83.  Downgrading back to v2.82, and the error messages go away.  Dnsmasq 
> > is configured to forward requests to dnscrypt-proxy via server=::1#53000 
> > and server=127.0.0.1#53000 lines in  dnsmasq.conf.  Turning on log-queries 
> > and log-dhcp did not show anything unusual in the log.
> >  
> > This configuration has been running fine for over a year now, so I don’t 
> > think it’s a configuration issue.  Dnscrypt-proxy is running version 2.0.45 
> > (updated was on 1/6/2021).
> 
> Hey Steve, I'm seeing something similar "failed to send packet" on my setup 
> that is new with 2.82 -> 2.83 .
> 
> Like you, I am proxying via 127.0.0.1#2853, but with unbound performing 
> DNS-over-TLS.
> 
> This box is my edge device with a fair amount of traffic, so the 10 errors 
> are not a lot in 24 hours, but would like to understand the change with 2.83 .
> 
> # grep dnsmasq /var/log/messages | grep -v dnsmasq-dhcp
> --
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: started, version 2.83 
> cachesize 4096
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: compile time options: IPv6 
> GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP 
> no-conntrack ipset auth no-nettlehash no-DNSSEC loop-detect inotify 
> no-dumpfile
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq-tftp[3300]: TFTP root is /tftpboot 
>  
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: using nameserver 
> 127.0.0.1#2853
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: using only locally-known 
> addresses for domain priv.abelbeck.com
> Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: read /etc/hosts - 65 
> addresses
> Jan 21 04:27:43 gw-lan daemon.err dnsmasq[3300]: failed to send packet: 
> Address family not supported by protocol
> Jan 21 13:14:00 gw-lan daemon.err dnsmasq[3300]: failed to send packet: 
> Address family not supported by protocol
> Jan 21 13:14:00 gw-lan daemon.err dnsmasq[3300]: failed to send packet: 
> Address family not supported by protocol
> Jan 21 13:14:01 gw-lan daemon.err dnsmasq[3300]: failed to send packet: 
> Address family not supported by protocol
> Jan 21 13:14:01 gw-lan daemon.err

Re: [Dnsmasq-discuss] v2.83 failed to send packet: Network is unreachable

[Lonnie Abelbeck]

> On Jan 21, 2021, at 5:53 PM, Steve Hirsch  wrote:
> 
> After upgrading dnsmasq from version 2.82 to version 2.83 on Arch Linux 
> (kernel 5.10.9), “failed to send packet: Network is unreachable” errors 
> continually show up.  However, name resolution still appears to work with 
> v2.83.  Downgrading back to v2.82, and the error messages go away.  Dnsmasq 
> is configured to forward requests to dnscrypt-proxy via server=::1#53000 and 
> server=127.0.0.1#53000 lines in  dnsmasq.conf.  Turning on log-queries and 
> log-dhcp did not show anything unusual in the log.
>  
> This configuration has been running fine for over a year now, so I don’t 
> think it’s a configuration issue.  Dnscrypt-proxy is running version 2.0.45 
> (updated was on 1/6/2021).

Hey Steve, I'm seeing something similar "failed to send packet" on my setup 
that is new with 2.82 -> 2.83 .

Like you, I am proxying via 127.0.0.1#2853, but with unbound performing 
DNS-over-TLS.

This box is my edge device with a fair amount of traffic, so the 10 errors are 
not a lot in 24 hours, but would like to understand the change with 2.83 .

# grep dnsmasq /var/log/messages | grep -v dnsmasq-dhcp
--
Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: started, version 2.83 
cachesize 4096
Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: compile time options: IPv6 
GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack 
ipset auth no-nettlehash no-DNSSEC loop-detect inotify no-dumpfile
Jan 20 15:52:41 gw-lan daemon.info dnsmasq-tftp[3300]: TFTP root is /tftpboot  
Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: using nameserver 
127.0.0.1#2853
Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: using only locally-known 
addresses for domain priv.abelbeck.com
Jan 20 15:52:41 gw-lan daemon.info dnsmasq[3300]: read /etc/hosts - 65 addresses
Jan 21 04:27:43 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:00 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:00 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:01 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:01 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:01 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 13:14:01 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 14:12:22 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 15:37:30 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
Jan 21 15:37:30 gw-lan daemon.err dnsmasq[3300]: failed to send packet: Address 
family not supported by protocol
--

In dnsmasq.conf I set:
--
dns-forward-max=512
--

So far, I'm not able to generate the "failed to send packet" manually by 
flooding DNS requests and such.

Lonnie



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

Re: [Dnsmasq-discuss] CVE-2020-25705 mitigation (SAD DNS)

[Lonnie Abelbeck]

> On Dec 9, 2020, at 4:38 AM, Petr Menšík  wrote:
> 
> I doubt limiting to 1221 can fix virtually anything. I doubt it would
> fix anything even on Windows. I am sure it would not prevent any attack
> on dnsmasq.
> 
> I think the best mitigation would be blocking any external IP addresses
> to dnsmasq, only those configured as forwarder in dnsmasq should be allowed.

Yes, or configure dnsmasq to use a DNS-over-TLS (DoT) proxy over untrusted 
networks. For example stubby.

Lonnie


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

Re: [Dnsmasq-discuss] Disabling IPv6 at compile time no longer workingno

[Lonnie Abelbeck]

The dnsmasq commit that removed HAVE_IPV6 means dnsmasq must be compiled on a 
system with IPv6 headers.

But at runtime, dnsmasq works on a IPv4-only (ipv6 module not loaded) Linux 
system.  Even without the ipv6 network stack (no protocol family 10 registered) 
dnsmasq will happily resolve  records and pass them on to clients over IPv4.

I would think build systems without IPv6 headers would be hard to come by in 
2020.

Lonnie


> On Oct 30, 2020, at 11:22 AM, Andrew Miskell  wrote:
> 
> Massimo,
> 
> Simon’s reasoning for removing support is stated in the git commit. It was 
> the source of a large number of ifdefs in the code, primarily for handling 
> old embedded libc versions.
> 
> Removing the flags allowed him to remove all the ifdefs and make the code 
> more maintainable overall. 
> 
> I’d actually probably also go as far as to assert that most of your arguments 
> listed aren’t really that valid in the grand scheme of things.
> 
>> On Oct 30, 2020, at 7:10 AM, SALA MASSIMO  wrote:
>> 
>> Hi Chris, Petr
>> 
>> I agree with Chris: I wish we could disable IPv6 support.
>> 
>> There are scenarios - like usage in intranet LANs,  IPv4 only - this feature 
>> is useless.
>> 
>> For best practice, unwanted features should be disabled:
>> 1) avoid any possibility of hitting bugs in code paths that implemet this 
>> functionality;
>> 2) reduce the surface of possible attacks;
>> 3) IMHO you cannot force the users to be unaware testers of unused features.
>> 
>> 
>> > It was intentionally removed in commit ee8750451b4[1], removed in 2.81 
>> > release.
>> 
>> I don't understand why this commit was approved.
>> Which are the benefits for the developers?
>> 
>> Best regards, Massimo Sala

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

Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address

[Lonnie Abelbeck]

> On Jul 27, 2020, at 1:12 PM, d...@lutean.com wrote:
> 
> Hi everyone,
> 
> The following proposed patch includes my attempt at a man page change. It 
> also includes Vladislav Grishenko's suggestion to tag LAA source addresses 
> independently from multicast addresses.
> 
> If these changes are acceptable, I propose the following commit message:
> 
> DHCP requests from ethernet MAC addresses that have either the Locally 
> Administered Address flag set or the multicast flag set automatically get 
> tagged with "laa" and "multicast" respectively before further processing.
> 
> Todd Sankey

Thanks!

Do I understand correctly, in order to ignore "laa-unicast" MACs, a user would 
define this ?

# Block unicast LAA-presenting devices
dhcp-ignore=tag:laa,tag:!multicast

Lonnie

BTW, here is a good article on this "Random MAC Address" topic:
https://community.cisco.com/t5/security-documents/random-mac-address-how-to-deal-with-it-using-ise/ta-p/4049321



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

Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address

[Lonnie Abelbeck]

Greetings,

So how would dnsmasq users go about not granting DHCP leases to LAA (anonymous) 
MAC addresses ?

I liken this to a PBX not accepting calls with anonymous/invalid caller-id 
entries.

Lonnie


> On Jul 26, 2020, at 10:04 AM, themiron...@gmail.com wrote:
> 
> Hi,
> 
> LAA stands for locally-administrated address itself, so from my opinion 
> "laa-address" is a bit tautologic.
> Let's use just "laa", also it ~fits already used one word tags:
>   "bootp"
>   "cpewan-id"
>   "dhcpv6"
>   "known"
>   "known-othernet"
>   
> --
> Best Regards, Vladislav Grishenko
> 
> -Original Message-
> From: Dnsmasq-discuss  On 
> Behalf Of Pali Rohar
> Sent: Sunday, July 26, 2020 7:20 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices 
> using a Locally Administered MAC address
> 
> On Sunday 26 July 2020 15:35:24 Geert Stappers wrote:
>> On Sun, Jul 26, 2020 at 06:07:52AM -0700, d...@lutean.com wrote:
> iOS 14
 
 CISCO provides an IOS, https://en.wikipedia.org/wiki/Cisco_IOS
 My second guess on IOS is an Apple Computer Inc product.
 
 
> will by default use randomized, private MAC addresses.
 
 Yeah right, let's sell a depleted MAC address pool as a privacy 
 improvement ...
 
>>> 
>>> It is an upcoming feature of Apple products that will be on by 
>>> default: https://support.apple.com/en-ca/HT211227
> 
> Ah :-( So Apple devices would be broken on lot of networks. Another reason 
> why to not buy them. I heard from lot of people that they are not supporting 
> Apple devices on networks anymore and I now I'm seeing reasons for such 
> decisions. Maintaining such crap must be really pain.
> 
>>> It is already available through the public beta.
>>> 
>>> So Apple devices as of October or sooner will be changing their MAC 
>>> addresses by default
>>> 
 
> In my testing these devices use a MAC address with the LAA bit 
> set (2nd least significant bit of the first byte of the MAC). It 
> restricts this to host addresses (least significant bit is set to 0).
 
 Speaks about two bits
 
 
> This patch detects MAC addresses with this bit set and tags the 
> request with the tag "laa-address". This would allow other rules 
> to decide what to do with these requests (such as ignoring them).
 
 Speaks about one bit
 
 
 
 Speaking about bits, see
>>> https://en.wikipedia.org/wiki/MAC_address#/media/File:MAC-48_Address
>>> .svg
 for the "exploded view"
 
>>> 
>>> https://en.wikipedia.org/wiki/MAC_address#Unicast_vs._multicast
>>> 
>>> The reason two bits are tested is because:
>>> - one bit is the UAA / LAA bit
>>> - one bit is the unicast / multicast bit
>>> 
>>> so this patch wouldn't tag LAA multicast MAC addresses should those 
>>> happen to be in use somewhere.
>>> 
>>> So specifically a device with an LAA unicast MAC address would get a 
>>> tag. This requires testing two bits.
>>> 
>> 
>> OK, thanks for elaborating
> 
> I think that big misunderstanding comes from commit message which says that 
> one bit (LAA) is tested, but in patch itself are tested two bits.
> 
> I guess that fixing commit message to properly describe that testing both 
> bits (and which) are needed should be enough.
> 
> Anyway, I'm not sure if 'laa-address' is correct name if it is not set for 
> every laa-address, but only for unicast laa-address.
> 
> --
> Pali Rohár
> pali.ro...@gmail.com
> 
> ___
> 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


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

Re: [Dnsmasq-discuss] How to pin IP rage two interface?

[Lonnie Abelbeck]

> On Nov 5, 2019, at 12:39 PM, bln 77  wrote:
> 
> Hi everyone,
> 
> I have a 10.1.0.0/16 network.
> I want to have clients in the same network because I want to be able to 
> receive IP-broadcast for autodiscovery.
> I configured two VLANs and the router has an interface/ip in both:
> lan1: 10.1.1.0 with subnet mask 255.255.0.0
> lan2: 10.1.2.0 with subnet mask 255.255.0.0
> 
> Both interfaces are bridged together and I filter/firewall the traffic with 
> etables rules.
> I have a filter that blocks DHCP traffic from being bridged/forwarded.
> 
> Now I want to configure dnsmasq to offer the following ranges on the 
> interfaces so I can easily recognise in which net the client belongs:
> 
> dhcp-range=set:lan1,10.1.1.50,10.1.2.199,255.255.0.0,12h
> dhcp-range=set:lan2,10.1.2.50,10.1.3.199,255.255.0.0,12h
> 
> Unfortunately the clients on the second interface also getting an offer from 
> the 10.1.1.x range.
> 
> I think both ranges are active on both interfaces?
> 
> Is there any way to pin a range to an interface?
> 
> Any help is appreciated.

Alternatively, use isolated subnets with 255.255.255.0 masks, no bridge, and 
enable "avahi-daemon" to share the broadcasts you need between subnets.

Everything is now simple ... except possibly configuring "avahi-daemon". :-)

Lonnie


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

Re: [Dnsmasq-discuss] DNS-over-TLS

[Lonnie Abelbeck]

> On Apr 16, 2018, at 4:02 PM, Lonnie Abelbeck <li...@lonnie.abelbeck.com> 
> wrote:
> 
> 
> On Oct 19, 2017, at 7:16 PM, Matt Taggart <tagg...@riseup.net> wrote:
> 
>> Hi,
>> 
>> Back in Sept 2015 I started a thread about DNS-over-TLS
>> 
>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q3/009833.html
>> 
>> Since then there is now RFC7858 ( https://tools.ietf.org/html/rfc7858 )
>> and port 853 (tcp) has been assigned for this use.
>> 
>> The following have support:
>> * unbound https://unbound.net/
>> * knot-resolver https://www.knot-resolver.cz/
>> * stubby https://dnsprivacy.org/wiki/display/DP/About+Stubby
>> 
>> Will dnsmasq get native support or will you recommend some sort of proxy 
>> solutio
>> n instead?
>> 
>> If you need servers to test against, there is a list at
>> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
>> 
>> Thanks,
>> 
>> -- 
>> Matt Taggart
>> tagg...@riseup.net
> 
> Our project (AstLinux) just added getdns/stubby as a DNS-TLS proxy in front 
> of dnsmasq, so far it is working great !
> 
> Personally, I have selected Quad9 as my provider, they seem to do DNS-TLS 
> quite well and support the 10 second idle connection timeout in my stubby 
> config reducing new TLS connections.
> 
> -- snippet /etc/dnsmasq.conf --
> no-resolv
> proxy-dnssec
> server=127.0.0.1#2853
> --
> 
> -- snippet /etc/stubby/stubby.yml  --
> listen_addresses:
>  - 127.0.0.1@2853
> --
> 
> I do not enable DNSSEC validation in either stubby or dnsmasq, Quad9 does the 
> DNSSEC validation with "proxy-dnssec" in dnsmasq passing it down.

Apologies for a following-up to my own post ...

DNSSEC question, is there any benefit to enable local DNSSEC resolution in 
stubby (DNSSEC disabled in dnsmasq) with "proxy-dnssec" and a DNSSEC provider 
like Quad9 or Cloudflare ?

The only difference I see are the signing algorithms 
https://rootcanary.org/test.html available.

Lonnie



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

Re: [Dnsmasq-discuss] DNS-over-TLS

[Lonnie Abelbeck]

On Oct 19, 2017, at 7:16 PM, Matt Taggart  wrote:

> Hi,
> 
> Back in Sept 2015 I started a thread about DNS-over-TLS
> 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q3/009833.html
> 
> Since then there is now RFC7858 ( https://tools.ietf.org/html/rfc7858 )
> and port 853 (tcp) has been assigned for this use.
> 
> The following have support:
> * unbound https://unbound.net/
> * knot-resolver https://www.knot-resolver.cz/
> * stubby https://dnsprivacy.org/wiki/display/DP/About+Stubby
> 
> Will dnsmasq get native support or will you recommend some sort of proxy 
> solutio
> n instead?
> 
> If you need servers to test against, there is a list at
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
> 
> Thanks,
> 
> -- 
> Matt Taggart
> tagg...@riseup.net

Our project (AstLinux) just added getdns/stubby as a DNS-TLS proxy in front of 
dnsmasq, so far it is working great !

Personally, I have selected Quad9 as my provider, they seem to do DNS-TLS quite 
well and support the 10 second idle connection timeout in my stubby config 
reducing new TLS connections.

-- snippet /etc/dnsmasq.conf --
no-resolv
proxy-dnssec
server=127.0.0.1#2853
--

-- snippet /etc/stubby/stubby.yml  --
listen_addresses:
  - 127.0.0.1@2853
--

I do not enable DNSSEC validation in either stubby or dnsmasq, Quad9 does the 
DNSSEC validation with "proxy-dnssec" in dnsmasq passing it down.

-- snippet /etc/stubby/stubby.yml  --
upstream_recursive_servers:
  - address_data: 9.9.9.9
tls_port: 853
tls_auth_name: "dns.quad9.net"
  - address_data: 149.112.112.112
tls_port: 853
tls_auth_name: "dns.quad9.net"
  - address_data: 2620:fe::fe
tls_port: 853
tls_auth_name: "dns.quad9.net"
--

So far this works very nicely in our development testing.

Lonnie


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

[Dnsmasq-discuss] FYI: netcalc 2.1.1

[Lonnie Abelbeck]

The netcalc project by Joachim Nilsson (@troglobit), is originally based on 
sipcalc, and the just released netcalc 2.1.1 has some new features dnsmasq 
configurations may be interested in.

https://github.com/troglobit/netcalc

For example, while a /24 network does not need fancy tools to calculate DHCP 
pool ranges, supporting arbitrary networks, pool ranges can get quite 
complicated.

host="192.168.101.1"
mask="255.255.255.0"

0 < $range_min < $range_max <= $max_hosts

range_min=100
range_max=200

max_hosts="$(netcalc "$host" "$mask" | sed -n -r -e 's/^Hosts\/Net *: 
*([0-9]+).*$/\1/p')"
# 254

ip_min="$(netcalc -R "$range_min:$range_max" "$host" "$mask" | sed -n -r -e 
's/^RangeMin *: *([0-9.]+).*$/\1/p')"
# 192.168.101.100

ip_max="$(netcalc -R "$range_min:$range_max" "$host" "$mask" | sed -n -r -e 
's/^RangeMax *: *([0-9.]+).*$/\1/p')"
# 192.168.101.200

dhcp-range= ... ,

So, for those of you that need to configure dnsmasq with arbitrary networks, 
the latest netcalc 2.1.1 may be a useful tool to take a look at.

# netcalc -R 100:400 10.10.10.1/23
--
Address  : 10.10.10.1   1010.1010.101 0.0001
Netmask  : 255.255.254.0 = 23   ..111 0.
Wildcard : 0.0.1.255..000 1.
=>
Network  : 10.0.0.0/23  1010..000 0.
HostMin  : 10.10.10.1   1010.1010.101 0.0001
HostMax  : 10.10.11.254 1010.1010.101 1.1110
Broadcast: 10.10.11.255 1010.1010.101 1.
Hosts/Net: 510   Class A, Private network (RFC1928)

[Range 100:400]
RangeMin : 10.10.10.100
RangeMax : 10.10.11.144
--

Lonnie


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

Re: [Dnsmasq-discuss] dnscrypt -dnssec problems

[Lonnie Abelbeck]

On May 25, 2016, at 4:08 PM, wkitt...@gmail.com wrote:

> On 05/25/2016 03:24 PM, Johnny Appleseed wrote:
>> dig +dnssec wikipedia.org
>> ;; Truncated, retrying in TCP mode.
>> 
>> ; <<>> DiG 9.8.3-P1 <<>> +dnssec wikipedia.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33183
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
> 
> why is this EDNS udp 4096 but
> 
> [...]
>>  dig +dnssec wikipedia.org
>> 
>> ; <<>> DiG 9.8.3-P1 <<>> +dnssec wikipedia.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13239
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 1280
> 
> this one is only 1280??

It would seem the "EDNS ... udp: 4096" query is using dnscrypt-proxy but the 
"EDNS ... udp: 1280" query is not.

Johnny, possibly you need "no-resolv" in your dnsmasq.conf ?

I assume you have something like:
--
server=127.0.0.1#2053
--
pointing to your dnscrypt-proxy instance.

You may also look into using "proxy-dnssec" if you trust your upstream server's 
DNSSEC since it traveling over a secure dnscrypt-proxy connection.

Lonnie


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

Re: [Dnsmasq-discuss] Hint needed: neither patched 'dnsmasq 2.75' nor '2.76test4' will compile

[Lonnie Abelbeck]

On Jan 6, 2016, at 12:04 PM, Simon Kelley  wrote:

> The do_script_run calls need to be removed from the compilation when
> DHCP is not included. Since the scripting system used to just about
> DHCP events, it was automatically removed from the compilation when
> DHCP was removed. Now the script system handles tftp and (in the
> latest code) ARP events, so it's no longer conditional on DHCP being
> included. This is fall-out from that change.
> 
> Conditional combination has a nasty combinatorial explosion. I should
> hack up a regression test to build all possible variants.
> 
> Fix pushed to git.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/dnsmasq.c;h=5cbfdbdf28cf1d03d95e50308107ee3225852c3b;hp=4ab56f1610750f16ef2afb86a369406f3aa906c3;hb=53a9173fc0b36d9427adb4ee9ac44df425717e84;hpb=d917275e481add809cd5c40650f339ae994ee35f

Simon, do_arp_script_run() does not have arguments, shouldn't ... ?

- while (do_arp_script_run(now));
+ while (do_arp_script_run());

Lonnie


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

Re: [Dnsmasq-discuss] Hint needed: neither patched 'dnsmasq 2.75' nor '2.76test4' will compile

[Lonnie Abelbeck]

On Jan 5, 2016, at 10:29 AM, Matthias Fischer <matthias.fisc...@ipfire.org> 
wrote:

> Hi,
> 
> On 05.01.2016 17:05, Lonnie Abelbeck wrote:
>> Hi Matthias,
>> 
>> It seems you have disabled HAVE_DHCP with enabled HAVE_SCRIPT.
>> 
>> Try disabling HAVE_SCRIPT in your build system...
>> --
>>  -e 's|#define HAVE_SCRIPT|//#define HAVE_SCRIPT|g' \
>> --
> 
> Thanks, but sorry, it seems that this worked only partially:

When you disable HAVE_DHCP then do_script_run() is no longer defined in lease.c 
.

So this section needs needs a #ifdef HAVE_DHCP ... #endif, either in whole or 
in pieces. As 2.75 (original) did.

-- dnsmasq.c [4ab56f1610750f16ef2afb86a369406f3aa906c3] --
 921 #ifdef HAVE_SCRIPT
 922   while (helper_buf_empty() && do_script_run(now)); 
 923   while (helper_buf_empty() && do_arp_script_run());
 924 
 925 #ifdef HAVE_TFTP
 926   while (helper_buf_empty() && do_tftp_script_run());
 927 #endif
 928 
 929   if (!helper_buf_empty())
 930 poll_listen(daemon->helperfd, POLLOUT);
 931 #else
 932   /* need this for other side-effects */
 933   while (do_script_run(now));
 934   while (do_arp_script_run(now));
 935 
 936 #ifdef HAVE_TFTP 
 937   while (do_tftp_script_run());
 938 #endif
 939 
 940 #endif
--
Also the do_arp_script_run() has inconstant args (ie. remove "now").

Also HAVE_DHCP possibly here ?...
--
1315 #if defined(HAVE_SCRIPT)
1316 /* handle pending lease transitions */
1317 if (daemon->helperfd != -1)
1318   {
1319 /* block in writes until all done */
1320 if ((i = fcntl(daemon->helperfd, F_GETFL)) != -1)
1321   fcntl(daemon->helperfd, F_SETFL, i & ~O_NONBLOCK); 
1322 do {
1323   helper_write();
1324 } while (!helper_buf_empty() || do_script_run(now));
1325 while (retry_send(close(daemon->helperfd)));
1326   }
1327 #endif
--

Simon knows best on how to fix this.

I suspect disabling HAVE_DHCP is somewhat unusual, hence you are hitting these 
issues.

Alternatively, you could build with HAVE_DHCP, disable HAVE_DHCP6 (leave 
HAVE_SCRIPT the default) and then disable (don't enable) dhcp at runtime via 
your /etc/dnsmasq.conf .

Lonnie



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

Re: [Dnsmasq-discuss] Hint needed: neither patched 'dnsmasq 2.75' nor '2.76test4' will compile

[Lonnie Abelbeck]

On Jan 4, 2016, at 7:13 PM, Matthias Fischer  
wrote:

> Hi,
> 
> sorry, this will be rather long...
> 
> I'm trying to compile 'dnsmasq 2.75' (for use with 'IPFire 2.17 (i586) - 
> core95') with
> all available patches but I'm always runnning into errors.
...
> cd /usr/src/dnsmasq-2.76test4 && sed -i src/config.h \
>   -e 's|/\* #define HAVE_IDN \*/|#define HAVE_IDN|g' \
>   -e 's|/\* #define HAVE_DNSSEC \*/|#define HAVE_DNSSEC|g' \
>   -e 's|#define HAVE_DHCP|//#define HAVE_DHCP|g' \
>   -e 's|#define HAVE_DHCP6|//#define HAVE_DHCP6|g' \
>   -e 's|#define HAVE_TFTP|//#define HAVE_TFTP|g'
> cd /usr/src/dnsmasq-2.76test4 && make CFLAGS="-O2 -pipe -Wall 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC -fstack-protector-all 
> --param=ssp-buffer-size=4 -march=i586 -mtune=generic -fomit-frame-pointer" 
> COPTS="-DHAVE_ISC_READER -DNO_INOTIFY" \
>   PREFIX=/usr all install
> make[1]: Entering directory '/usr/src/dnsmasq-2.76test4'
> ...
> dnsmasq.c 
> dnsmasq.c: In function 'main':
> dnsmasq.c:922:7: warning: implicit declaration of function 'do_script_run' 
> [-Wimplicit-function-declaration]
>   while (helper_buf_empty() && do_script_run(now));
>   ^

Hi Matthias,

It seems you have disabled HAVE_DHCP with enabled HAVE_SCRIPT.

Try disabling HAVE_SCRIPT in your build system...
--
-e 's|#define HAVE_SCRIPT|//#define HAVE_SCRIPT|g' \
--

Lonnie


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

Re: [Dnsmasq-discuss] strategies to mitigate DNS amplification attacks in ISP network

[Lonnie Abelbeck]

Doesn't DNSCrypt https://dnscrypt.org solve the same problem ?

Lonnie


On Dec 2, 2015, at 3:21 AM, Dave Taht  wrote:

> DNS cookies look kind of interesting...
> 
> 
> -- Forwarded message --
> From: Mark Andrews 
> Date: Wed, Dec 2, 2015 at 1:39 AM
> Subject: Re: strategies to mitigate DNS amplification attacks in ISP network
> To: Michael Hare 
> Cc: "na...@nanog.org" 
> 
> 
> 
> Deploy DNS COOKIES.  This allows legitimate UDP traffic to be
> identified and treated differently to spoofed traffic by providing
> the equivalent to a TCP handshake but over UDP.
> 
> This is currently in IETF last call but the code points are assigned
> and implementations are available.  Ask your nameserver vendor for
> this today.  Ask your OS vendor for support.
> 
> https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07
> 
> Mark
> 
> In message 
>  rod.outlook.com>, Michael Hare writes:
>> Martin-
>> 
>> I represent a statewide educational network running Juniper gear that is a qu
>> asi-enterprise.  I think efforts depend on size and type of network.  We are
>> testing an approach that involves;
>> 
>> 1) whitelisting known local resolvers, well behaved cloud DNS resolvers.
>> 2) on ingress, policing non-conforming traffic that matches UDP src port 53 d
>> st port unreserved bytes > 1400
>> 3) on ingress, queuing fragments to high packet loss priority [you better und
>> erstand how fragments are used in your network before doing this]
>> 4) If you have Juniper gear look into prefix-action
>> 5) RTBH if required
>> 
>> This obviously doesn't work on the core of the internet.
>> 
>> Other good tips:
>> * strengthen [anycast] your local DNS resolvers and consider a scheme that al
>> lows you to change their outgoing address on the fly.
>> * push [some] of your external authoritative DNS to the cloud.
>> 
>> -Michael
>> 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Martin T
 Sent: Tuesday, December 01, 2015 11:00 AM
 To: na...@nanog.org
 Subject: strategies to mitigate DNS amplification attacks in ISP network
 
 Hi,
 
 as around 40% of ASNs allow at least partial IPv4 address spoofing in
 their network(http://spoofer.csail.mit.edu/summary.php) and there are
 around 30 million open-resolvers(http://openresolverproject.org/) in
 the Internet, then DNS amplification traffic is daily occasion for
 ISPs. This in probably mainly because RPF checks and DNS
 RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Respons
>> e-
 Rate-Limiting.html)
 are not ubiquitously implemented, recursive requests without any ACLs
 in DNS servers are often allowed, it requires little effort from
 attackers point of view and is effective attack method. Unfortunately,
 there seems to be very limited number of countermeasures for ISPs. Few
 which I can think of:
 
 1) higher capacity backbone links - I'm not sure if this can be
 considered a mitigation method, but at least it can help to affect
 smaller amount of customers if traffic volumes are not very high
 
 
 2) rate-limit incoming DNS traffic flows on peering and uplink ports -
 here I mean something similar to iptables "recent"
 module(http://www.netfilter.org/documentation/HOWTO/netfilter-
>>> extensions-
 HOWTO-3.html#ss3.16)
 which allows certain number of certain type of packets in a configured
 time-slot per IP. However, such functionality is probably not common
 on edge or backbone routers.
 
 
 Tracking the packet state does definitely not work because state table
 should be synchronized between all the routers in the network and
 again, this requires Internet-routers to have stateful firewall
 functionality. In addition, one also needs to allow new DNS
 connections from Internet to its network.
 If one simply polices incoming DNS traffic on uplink and peering
 ports(for example if baseline DNS traffic is 5Mbps, then policer is
 set to 50Mbps), then legitimate customers DNS traffic is also affected
 in case of actual attack occurs and policer starts to drop DNS
 traffic, i.e. policer has no way to distinguish between the legitimate
 and non-legitimate incoming DNS traffic.
 
 
 Am I wrong in some points? What are the common practices to mitigate
 DNS amplification attacks in ISP network?
 
 
 thanks,
 Martin
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 

Re: [Dnsmasq-discuss] Clear prefix autonomous flag on router advertising

[Lonnie Abelbeck]

On Oct 13, 2015, at 2:03 PM, Carlos Carvalho  wrote:

> Shaun Lynch (em2s...@yahoo.com) wrote on Tue, Oct 13, 2015 at 01:16:35AM BRT:
>> I am building a IPv4-IPv6 dual-stack gateway device for a virtual sandbox in 
>> which to experiment with different system configurations. The current 
>> gateway uses Debian 8.2 as the host operating system along with radvd for 
>> router advertising that is configured as follows: 
>> 
>> interface eth1
>> {
>> AdvSendAdvert on;
>> AdvManagedFlag on;
>> AdvOtherConfigFlag on;
>> 
>> prefix ::/64
>> {
>> AdvAutonomous off;
>> };
>> };
>> 
>> My objective is to provide client computers with the address of the default 
>> gateway while using a separate DHCPv6 server to provide the host address and 
>> DNS information.
> 
>> So far I have been able to configure dnsmasq in a DHCPv6 stateful
>> configuration with the included DHCPv6 service; however, I cannot seem to
>> determine which options set the managed address (M) and other (O) flags and
>> clears the prefix autonomous (A) flag to disable generation of the stateless
>> address for stand-alone router advertising.
> 
> As stated in the manual, in the description of the enable-ra option, by 
> default
> M is set and A unset. You can change them with the mode atribute of the
> dhcp-range declaration.

Here is a useful table of the flags and dnsmasq options (Thanks to Igor)

DHCPv6 and RA with dnsmasq
https://weirdfellow.wordpress.com/2014/09/05/dhcpv6-and-ra-with-dnsmasq/

Lonnie

PS: Simon, possibly your docs could include a similar table ?


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

Re: [Dnsmasq-discuss] DNS-over-TLS

[Lonnie Abelbeck]

On Sep 7, 2015, at 2:04 PM, Matt Taggart  wrote:

> Hi,
> 
> Have you seen this draft for adding TLS to DNS?
> 
>  https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01
> 
> What would it take to implement in dnsmasq?
> Both as a server and as a client.

Take a look at DNSCrypt:
https://dnscrypt.org

We use dnscrypt-proxy as a DNS forwarder in front of dnsmasq (on the same box) 
and it works brilliantly.

Lonnie


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

Re: [Dnsmasq-discuss] Unseen cache limit?

[Lonnie Abelbeck]

Robert,

Looking at the code there is an upper limit of 1 for --cache-size

-- src/option.c --
case 'c':  /* --cache-size */
  {
int size;

if (!atoi_check(arg, size))
  ret_err(gen_err);
else
  {
/* zero is OK, and means no caching. */

if (size  0)
  size = 0;
else if (size  1)
  size = 1;

daemon-cachesize = size;
  }
break;
  }
--

I'm sure Simon has a good reason for that upper limit.  Possibly a cache-size 
of 50,000 is beyond the design goal of dnsmasq.

Lonnie



On Jun 1, 2015, at 6:21 PM, Robert Smith twopoin...@gmail.com wrote:

 Hi,
 
 I wonder if there is some sort of internal limit on caching?
 
 I set cache-size=5, restarted dnsmasq and the limit 
 according to the caching service is 1
 
 # kill -10 10150; tail -n5 /var/log/messages | egrep 'cache size'
 Jun  1 19:18:41 dnsmasq1 dnsmasq[10150]: cache size 1, 0/2660
 cache insertions re-used unexpired cache entries.
 
 Thanks for your attention to this matter,
 Robert
 
 
 ___
 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] Security warning for those at the bleeding edge.

[Lonnie Abelbeck]

On May 15, 2015, at 2:37 PM, Simon Kelley si...@thekelleys.org.uk wrote:

 Anyone running 2.67rc6 or 2.67rc7 should be aware that there's a
 remotely exploitable buffer overflow in those trees. I just tagged
 2.67rc8, which includes the fix.
 
 
 Cheers,
 
 Simon.

I think you meant to type 2.73rc6 ... 2.73rc7 ... 2.73rc8

Fix buffer overflow introduced in 2.73rc6.

Lonnie



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

[Dnsmasq-discuss] no-dhcp-interface and dhcp-range/ra-only

[Lonnie Abelbeck]

Hi,

I'm in the process of moving from radvd to dnsmasq for ra-only...

Everything works as before with radvd, except for one side case, if a user 
chooses for interface eth1...
--
no-dhcp-interface=eth1
dhcp-range=lan,2001:db8:1:2::,ra-only,64,24h
--
Then router advertisements seem to also be disabled.

Is this by design ?

I agree this is a rather odd special case, but is a theoretical change from 
using radvd.

Lonnie


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

Re: [Dnsmasq-discuss] Shellshock.

[Lonnie Abelbeck]

On Sep 27, 2014, at 7:01 AM, Matthias Andree matthias.and...@gmx.de wrote:

 Am 27.09.2014 um 12:01 schrieb Roy Marples:
 On Friday 26 Sep 2014 21:14:20 Simon Kelley wrote:
 This is just a heads-up that if you're using the --dhcp-script option in
 dnsmasq, and the script you're calling is being interpreted by bash,
 then you're affected by the shellshock bug.
 
 The bug allows execution of arbitrary code contained in the values of
 environment variables, and there are several variables in the
 environment inherited by the DHCP script whose values can be set
 directly by a DHCP client, so any DHCP client on your network (or
 elsewhere, if your firewall allows) can execute arbitrary shellcode,
 probably as root, with a simple DHCP request.
 
 The fix, of course, is to update bash.
 
 What's your reason for not sanitising the variables?
 
 This isn't dnsmasq's fault - what's bash's reason for parsing or
 executing environment variables as though they were functions?
 This is a stupid design decision.

Christos Zoulas from NetBSD has a simple patch to bash to disable importing 
functions by default:
http://www.openwall.com/lists/oss-security/2014/09/26/22

FreeBSD has done the same:
http://www.openwall.com/lists/oss-security/2014/09/26/33

It seems to me this is the only secure approach for the time being, and for 
many situations a long term solution.

Lonnie


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

Re: [Dnsmasq-discuss] Does DNSSEC require nettle and gmp, or nettle with gmp?

[Lonnie Abelbeck]

On Mar 25, 2014, at 4:52 PM, Simon Kelley wrote:

 On 25/03/14 21:25, Lonnie Abelbeck wrote:
 
 
 Is the decision to not support OpenSSL shared libraries a final decision, or 
 is there a chance you may reconsider ?
 
 
 The very early DNSSEC code used openSSL, so it's possible. The reason
 for the change (in no particular order) was 1) the API is much nicer. 2)
 licensing considerations.
 
 I evaluated several possible libraries before choosing Nettle.
 
 One of the worries was bloat, especially in openWRT and similar router
 distributions. The conclusion was that those typically don't include
 openSSL anyway, they use things like dropbear, which has it's own crypto.
 
 Note that whilst the a full shared installation of nettle and gmp is
 large, the dnsmasq build system allows static linking, which means that
 you get the small portion of the libraries which is needed by dnsmasq,
 not the whole thing. When I last checked, dnsmasq compiled with DNSSEC
 support and statically linked against Nettle and stripped was 200k or
 so. That needs no extra disk space for crypto libraries at all.  200k +
 libc gives you everything.
 
 
 Conclusions from this:
 
 1) It would be possible to use openSSL instead of Nettle.
 2) To do so, you'd have to convince me (and other copyright holders) to
 add an openSSL exception to the dnsmasq license. I have a built-in bias
 for GPL-licensed software.
 3) There are no real resource arguments for using openSSL instead of Nettle.
 
 Do you want openSSL instead of Nettle? If so, why?
 
 Cheers,
 
 Simon.

I would prefer OpenSSL support.

As a developer for a cross-compiled x86 open source project (AstLinux) building 
and maintaining additional libraries (particularly crypto) is not ideal when so 
many packages already require OpenSSL.

We also try to keep the bloat out as much as possible, our compressed images 
are around 40 MB in size.

Your excellent dnsmasq is one of our core packages, it would be our preference 
if it also supported the time tested OpenSSL shared libraries.

Obviously using Nettle is not a deal breaker, but I think OpenSSL vs. Nettle is 
a good discussion to have.

Thanks,
Lonnie


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

[Dnsmasq-discuss] DNSCrypt - the big picture

[Lonnie Abelbeck]

DNS Gurus,

With all the excellent work on DNSSEC, I'd like to get this list's thoughts on 
the merits of using DNSCrypt.
http://dnscrypt.org/

I cross-compiled dnscrypt-proxy 1.3.3 together with libsodium 0.4.5 from 
source, and it works splendidly with our beloved dnsmasq.

FYI, I started dnscrypt-proxy as:

$ dnscrypt-proxy -d --local-address 127.0.0.1:2053 -p 
/var/run/dnscrypt-proxy.pid

And configured dnsmasq as:
--
#resolv-file=...
no-resolv
server=127.0.0.1#2053
--

But, stepping back from the trees to the forest, is DNSCrypt a solution we all 
should consider using, or is it more of a security feel good measure ?

I admit is is nice to know that no-one is silently altering DNS 
queries/responses in transit to a trusted DNS server, but is that being overly 
paranoid ?

Appreciate any comments...

Lonnie


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

Re: [Dnsmasq-discuss] DNSCrypt - the big picture

[Lonnie Abelbeck]

On Feb 7, 2014, at 7:15 AM, Maciej Soltysiak wrote:

 On Fri, Feb 7, 2014 at 1:42 PM, Lonnie Abelbeck
 li...@lonnie.abelbeck.com wrote:
 I admit is is nice to know that no-one is silently altering DNS 
 queries/responses in transit to a trusted DNS server, but is that being 
 overly paranoid ?
 
 Appreciate any comments...
 I treat dnscrypt as a way to prevent query snooping by my ISP, not as
 means to prevent altering.

Thanks for your thoughts Maciej, but since the ISP routes (and logs stats) the 
network data anyway, there isn't much privacy to be gained by preventing DNS 
query snooping, is there ?

I'm thinking DNSCrypt's best feature is preventing man-in-the-middle attacks 
between the router and the trusted DNS server.

Lonnie


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

Re: [Dnsmasq-discuss] Reg: Info related to leases file

[Lonnie Abelbeck]

On Oct 3, 2013, at 8:05 AM, Nehal J Wani wrote:

 Yes. I just added contrib/mactable/macscript to the git repo, which is your
 previous script slightly less elegantly modified by me for this
 circumstance. I also put back the make new file then atomically rename
 behaviour since that means anything using this file doesn't risk a race
 condition leading to a half-written file.
 
 
 I gave a try to the --dhcp-script option of dnsmasq. Following are the 
 findings:
 
 Script used: (a little modified version of
 http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=contrib/mactable/macscript;hb=HEAD):
 
 #!/bin/bash
 
 STATUS_FILE=/var/lib/libvirt/
 dnsmasq/dnsmasq-ip-mac.status
 
 # Script for dnsmasq lease-change hook.
 # Maintains the above file with a IP address/MAC address pairs,
 # one lease per line. Works with IPv4 and IPv6 leases, file is
 # atomically updated, so no races for users of the data.
 
 action=$1
 mac=$2   # IPv4
 ip=$3
 
 expirytime=$DNSMASQ_LEASE_EXPIRES
 hostname=$DNSMASQ_SUPPLIED_HOSTNAME
 clientid=$DNSMASQ_CLIENT_ID
 
 # ensure it always exists.
 
 if [ ! -f $STATUS_FILE ]; then
  touch $STATUS_FILE
 fi
 
 if [  -n $DNSMASQ_IAID ]; then
mac=$DNSMASQ_MAC   # IPv6
clientid=$2
 fi
 
 # worry about an add or old action when the MAC address is not known:
 # leave any old one in place in that case.
 
 if [ $action = add -o $action = old -o $action = del ]; then
  if [ -n $mac -o $action = del ]; then
sed /^${ip//./\.} / d $STATUS_FILE  $STATUS_FILE.new
 
if [ $action = add -o $action = old ]; then
   echo $expirytime $mac $ip $hostname $clientid  $STATUS_FILE.new
fi
mv  $STATUS_FILE.new $STATUS_FILE # atomic update.
  fi
 fi

-- snip --
 -- 
 Nehal J Wani

Unrelated to your questions, you broke the script by not keeping the $ip as the 
first field in the status file.  The $ip is used as a unique index of sorts.

The simple fix would be to put $ip as the first output of your echo command, 
otherwise some regex work on the sed command is required to match $ip in the 
middle rather than at the beginning.

Lonnie


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

Re: [Dnsmasq-discuss] Reg: Info related to leases file

[Lonnie Abelbeck]

On Sep 27, 2013, at 6:51 AM, Simon Kelley wrote:
 
 There's one change which needs to be made to the script. When dnsmasq is 
 restarted, it won't know the MAC addresses for DHCPv6 (because they're not in 
 the leasefile). So at start-up it  will execute old script runs on each 
 lease without the DNSMASQ_MAC environment variable set. The script needs to 
 detect when called with old and no DNSMASQ_MAC and not delete the relevant 
 line from its file.

Hi Simon,

Does this do what you want ?

=
#!/bin/bash

action=$1
mac=$2   # IPv4
ip=$3

STATUS_FILE=/tmp/dnsmasq-ip-mac.status

if [ -n $DNSMASQ_IAID ]; then
  mac=$DNSMASQ_MAC   # IPv6
fi

if [ $action = add -o $action = old -o $action = del ]; then
  if [ -n $ip ]; then
if [ -n $mac -o $action = del ]; then
  if [ -f $STATUS_FILE ]; then
sed -i /^${ip//./\.} / d $STATUS_FILE
  fi
  if [ $action = add -o $action = old ]; then
echo $ip $mac  $STATUS_FILE
  fi
fi
  fi
fi
=

Lonnie


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

Re: [Dnsmasq-discuss] Decouple enable-tftp and no-dhcp-interface

[Lonnie Abelbeck]

On Jul 25, 2013, at 4:44 PM, Lonnie Abelbeck wrote:

 
 On Jul 25, 2013, at 4:06 PM, Simon Kelley wrote:
 
 On 23/06/13 20:34, Lonnie Abelbeck wrote:
 Hi,
 
 I'd like to suggest that enable-tftp and no-dhcp-interface should be
 decoupled.
 
 Not only is it confusing that no-dhcp-interface also disables
 enable-tftp for that interface, but it is sometimes desirable to
 allow DNS and TFTP on an interface without DHCP.
 
 Looking at src/tftp.c is seems there is no dependance on DHCP
 except to walk the no-dhcp-interface args when HAVE_DHCP is defined.
 
 Ideally, IMHO, enable-tftp should be independent from HAVE_DHCP and
 add a new no-tftp-interface config that would be tested for
 interface exceptions instead of no-dhcp-interface.
 
 Reasonable ?
 
 The rationale for the current state-of-the-world is that the TFTP server in 
 dnsmasq is provided for the express purpose of doing netbooting, so it makes 
 sense to do TFTP on the same interfaces/addresses as DHCP.
 
 I'd like to keep that as-is, for backwards compatibility if no other reason, 
 so I suggest that we could add new option --tftp-interface that would have a 
 higher priority than no-dhcp-interface. SO, to do TFTP but NOT DHCP on eth0 
 you'd do
 
 no-dhcp-interface=eth0
 tftp-interface=eth0
 
 No existing configs would change meaning, and the common case wouldn't need 
 to use the new option.
 
 Comments?
 
 Simon.
 
 To be clear, if in the above example eth1 had DHCP enabled, then TFTP would 
 be served on both eth0 and eth1 ?
 
 If so, would this be more clear ?
 --
 tftp-no-dhcp-interface=eth0
 --
 which would be a synonym for no-dhcp-interface but would mark that 
 interface to allow TFTP.
 
 I agree no change to existing configs is best.
 
 Lonnie

Replying to myself, another idea...

Allow enable-tftp to work the same as currently, but then add enable-tftp= 
with options:

# Limit TFTP server to a list of interfaces
--enable-tftp=eth1,eth2
# Allow TFTP server for all interfaces
--enable-tftp=*

Then enable-tftp and enable-tftp= can't both be specified.

Lonnie



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

Re: [Dnsmasq-discuss] Decouple enable-tftp and no-dhcp-interface

[Lonnie Abelbeck]

On Jul 25, 2013, at 4:06 PM, Simon Kelley wrote:

 On 23/06/13 20:34, Lonnie Abelbeck wrote:
 Hi,
 
 I'd like to suggest that enable-tftp and no-dhcp-interface should be
 decoupled.
 
 Not only is it confusing that no-dhcp-interface also disables
 enable-tftp for that interface, but it is sometimes desirable to
 allow DNS and TFTP on an interface without DHCP.
 
 Looking at src/tftp.c is seems there is no dependance on DHCP
 except to walk the no-dhcp-interface args when HAVE_DHCP is defined.
 
 Ideally, IMHO, enable-tftp should be independent from HAVE_DHCP and
 add a new no-tftp-interface config that would be tested for
 interface exceptions instead of no-dhcp-interface.
 
 Reasonable ?
 
 The rationale for the current state-of-the-world is that the TFTP server in 
 dnsmasq is provided for the express purpose of doing netbooting, so it makes 
 sense to do TFTP on the same interfaces/addresses as DHCP.
 
 I'd like to keep that as-is, for backwards compatibility if no other reason, 
 so I suggest that we could add new option --tftp-interface that would have a 
 higher priority than no-dhcp-interface. SO, to do TFTP but NOT DHCP on eth0 
 you'd do
 
 no-dhcp-interface=eth0
 tftp-interface=eth0
 
 No existing configs would change meaning, and the common case wouldn't need 
 to use the new option.
 
 Comments?
 
 Simon.

To be clear, if in the above example eth1 had DHCP enabled, then TFTP would be 
served on both eth0 and eth1 ?

If so, would this be more clear ?
--
tftp-no-dhcp-interface=eth0
--
which would be a synonym for no-dhcp-interface but would mark that interface 
to allow TFTP.

I agree no change to existing configs is best.

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

[Dnsmasq-discuss] Decouple enable-tftp and no-dhcp-interface

[Lonnie Abelbeck]

Hi,

I'd like to suggest that enable-tftp and no-dhcp-interface should be decoupled.

Not only is it confusing that no-dhcp-interface also disables enable-tftp for 
that interface, but it is sometimes desirable to allow DNS and TFTP on an 
interface without DHCP.

Looking at src/tftp.c is seems there is no dependance on DHCP except to walk 
the no-dhcp-interface args when HAVE_DHCP is defined.

Ideally, IMHO, enable-tftp should be independent from HAVE_DHCP and add a new 
no-tftp-interface config that would be tested for interface exceptions 
instead of no-dhcp-interface.

Reasonable ?

This hack patch makes enable-tftp no longer dependent on no-dhcp-interface 
and enabled for all interfaces, but adding a new no-tftp-interface config 
would be more complete.
=
--- dnsmasq-2.66/src/tftp.c.orig2013-06-23 14:09:53.0 -0500
+++ dnsmasq-2.66/src/tftp.c 2013-06-23 14:10:19.0 -0500
@@ -16,6 +16,8 @@
 
 #include dnsmasq.h
 
+#undef HAVE_DHCP
+
 #ifdef HAVE_TFTP
 
 static struct tftp_file *check_tftp_fileperm(ssize_t *len, char *prefix);
=

Lonnie

Related:
This thread prompted Simon to change the docs related to no-dhcp-interface:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q3/004342.html

Unfortunately the solution to the above (2010) thread was to use 
enable-tftp=interface,interface which was removed in version 2.63.


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