Re: [Dnsmasq-discuss] Feature Request: DNS over TLS or HTTPS

[Simon Kelley]

If you were to implement this in dnsmasq, by far the best way would be 
to put proxy in front of dnsmasq.


The existing dnsmasq concurrency model just doesn't support the 
implementation. If relies on most queries happening over UDP, and the 
context for such queries being very minimal. Anything that happens over 
TCP (like TLS or HTTPs) is the opposite extreme, with a new dnsmasq 
process being spawned for each request. That's not scalable when you're 
going to run everything upstream over TCP.


Given that the preferred architecture is a proxy in front of dnsmasq, 
the next question is, do we have to implement that, or does it already 
exist?  A quick Google reveals several potential candidates and the one 
that I've most heard people are using is dnscrypt-proxy.


I have no personal experience with dnscrypt-proxy  or any of the other 
options, but before thinking about writing  another one, I'd like to be 
sure that none of the existing options are suitable, and that I couldn't 
persuade someone else to do the work rather than making it part of the 
dnsmasq effort.



Simon.



On 27/02/2023 18:06, Curzon Dax via Dnsmasq-discuss wrote:

Greetings,

I checked through the last 1-2 years of the mailing list, and I hadn't 
seen anything regarding DoT/DoH. If this has come up before and I missed 
it, apologies in advance.


Thought I'd add a feature request for DNS over TLS or DNS over HTTPS 
when dnsmasq is used as a DNS forwarder.


BIND is about to implement this in the next version, and I believe 
Windows DNS is the last to the party among the other major DNS 
recursors/forwarders.


I realize that this could add considerable size, scope, and complexity 
to something which is inherently light weight and used on a lot of 
embedded devices with very minimal storage. Perhaps something optional 
at build time to avoid bundling large libraries/dependencies. embed-TLS 
could be something to look at to ensure this feature could be built on 
very-low-storage, embedded devices.


I know that many embedded devices (modems/routers) have some form of an 
SSL library already, as many offer admin control over https://.


If there is interest by the developers/maintainers, perhaps we could 
make a call for financial support from the major recursive providers 
(Google, Quad9, Cloudflare, etc). I know a few of the DNS folks at these 
organizations, and while I'm not making any promises or claims, it's 
something I'd be happy to reach out to them about.


Thanks in advance.
-Curzon

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


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

[Dnsmasq-discuss] Feature Request: DNS over TLS or HTTPS

[Curzon Dax via Dnsmasq-discuss]

Greetings,

I checked through the last 1-2 years of the mailing list, and I hadn't seen 
anything regarding DoT/DoH. If this has come up before and I missed it, 
apologies in advance.

Thought I'd add a feature request for DNS over TLS or DNS over HTTPS when 
dnsmasq is used as a DNS forwarder.

BIND is about to implement this in the next version, and I believe Windows DNS 
is the last to the party among the other major DNS recursors/forwarders.

I realize that this could add considerable size, scope, and complexity to 
something which is inherently light weight and used on a lot of embedded 
devices with very minimal storage. Perhaps something optional at build time to 
avoid bundling large libraries/dependencies. embed-TLS could be something to 
look at to ensure this feature could be built on very-low-storage, embedded 
devices.

I know that many embedded devices (modems/routers) have some form of an SSL 
library already, as many offer admin control over https://.

If there is interest by the developers/maintainers, perhaps we could make a 
call for financial support from the major recursive providers (Google, Quad9, 
Cloudflare, etc). I know a few of the DNS folks at these organizations, and 
while I'm not making any promises or claims, it's something I'd be happy to 
reach out to them about.

Thanks in advance.
-Curzon___
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: DHCP options 100 and 101

[Simon Kelley]

On 29/11/2022 23:11, Joe Pfeiffer wrote:

Thanks -- the particular phrase in the man page that confused me (I
actually had read it) was

 The set of option-names known by dnsmasq can be discovered by
 running "dnsmasq --help dhcp". For example, to set the default
 route option to 192.168.4.4, do
 --dhcp-option=3,192.168.4.4 or --dhcp-option = option:router, 192.168.4.4
 and to set the time-server address to 192.168.0.4, do
 --dhcp-option = 42,192.168.0.4 or --dhcp-option = option:ntp-server, 
192.168.0.4

It wasn't clear (to me, anyway) that it supports options by number
that are not known by name.



The options are supported by name (as posix-timezone and tzdb-timezone) 
in the 2.86 and later releases of dnsmasq.




Cheers,

Simon.


Donald Muller writes:

All options are supported. Just specify the number.


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




___
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: DHCP options 100 and 101

[Simon Kelley]

On 29/11/2022 23:11, Joe Pfeiffer wrote:

Thanks -- the particular phrase in the man page that confused me (I
actually had read it) was

 The set of option-names known by dnsmasq can be discovered by
 running "dnsmasq --help dhcp". For example, to set the default
 route option to 192.168.4.4, do
 --dhcp-option=3,192.168.4.4 or --dhcp-option = option:router, 192.168.4.4
 and to set the time-server address to 192.168.0.4, do
 --dhcp-option = 42,192.168.0.4 or --dhcp-option = option:ntp-server, 
192.168.0.4

It wasn't clear (to me, anyway) that it supports options by number
that are not known by name.



The options are supported by name (as posix-timezone and tzdb-timezone) 
in the 2.86 and later releases of dnsmasq.




Cheers,

Simon.


Donald Muller writes:

All options are supported. Just specify the number.


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




___
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: DHCP options 100 and 101

[Joe Pfeiffer]

Thanks -- the particular phrase in the man page that confused me (I
actually had read it) was

The set of option-names known by dnsmasq can be discovered by
running "dnsmasq --help dhcp". For example, to set the default
route option to 192.168.4.4, do
--dhcp-option=3,192.168.4.4 or --dhcp-option = option:router, 192.168.4.4
and to set the time-server address to 192.168.0.4, do
--dhcp-option = 42,192.168.0.4 or --dhcp-option = option:ntp-server, 
192.168.0.4

It wasn't clear (to me, anyway) that it supports options by number
that are not known by name.

Donald Muller writes:
>All options are supported. Just specify the number. 

___
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: DHCP options 100 and 101

[Geert Stappers via Dnsmasq-discuss]

On Tue, Nov 29, 2022 at 08:10:18PM +, Donald Muller wrote:
> From: Dnsmasq-discuss, on behalf of Joe Pfeiffer, Sent: Tuesday, November 29, 
> 2022 2:25:59 PM
> > 
> > At present, dnsmasq supports DHCP option 2 (time-offset), but does
> > not support options 100 (TZ-POSIX string) or 101 (TZ-Database
> > String).
> > 
> > It would be very helpful if options 100 and 101 could be supported, as
> > they are more human readable and enable daylight savings time
> > support.  Also, option 2 is deprecated (per
> > https://www.rfc-editor.org/rfc/rfc4833)
> > 
> > 
> All options are supported. Just specify the number.
> 
> --dhcp-option=[tag:,[tag:,]][encap:,][vi-encap:,][vendor:[],][|option:|option6:|option6:],[[,]]
> Specify different or extra options to DHCP clients. By default,
> dnsmasq sends some standard options to DHCP clients, the netmask and
> broadcast address are set to the same as the host running dnsmasq, and
> the DNS server and default route are set to the address of the machine
> running dnsmasq. (Equivalent rules apply for IPv6.) If the domain name
> option has been set, that is sent. This configuration allows these
> defaults to be overridden, or other options specified. The option, to
> be sent may be given as a decimal number or as "option:"
> The option numbers are specified in RFC2132 and subsequent RFCs. The
> set of option-names known by dnsmasq can be discovered by running
> "dnsmasq --help dhcp". For example, to set the default route option
> to 192.168.4.4, do --dhcp-option=3,192.168.4.4 or --dhcp-option =
> option:router, 192.168.4.4 and to set the time-server address to
> 192.168.0.4, do --dhcp-option = 42,192.168.0.4 or --dhcp-option =
> option:ntp-server, 192.168.0.4 The special address 0.0.0.0 is taken
> to mean "the address of the machine running dnsmasq".
> 
> Data types allowed are comma separated dotted-quad IPv4 addresses,
> []-wrapped IPv6 addresses, a decimal number, colon-separated hex digits
> and a text string. If the optional tags are given then this option is
> only sent when all the tags are matched.
> 
> Special processing is done on a text argument for option 119, to
> conform with RFC 3397. Text or dotted-quad IP addresses as arguments
> to option 120 are handled as per RFC 3361. Dotted-quad IP addresses
> which are followed by a slash and then a netmask size are encoded as
> described in RFC 3442.
> 
> IPv6 options are specified using the option6: keyword,
> followed by the option number or option name. The IPv6 option
> name space is disjoint from the IPv4 option name space. IPv6
> addresses in options must be bracketed with square brackets,
> eg. --dhcp-option=option6:ntp-server,[1234::56] For IPv6, [::] means
> "the global address of the machine running dnsmasq", whilst [fd00::]
> is replaced with the ULA, if it exists, and [fe80::] with the link-local
> address.
> 
> Be careful: no checking is done that the correct type of data for the
> option number is sent, it is quite possible to persuade dnsmasq to
> generate illegal DHCP packets with injudicious use of this flag. When
> the value is a decimal number, dnsmasq must determine how large the data
> item is. It does this by examining the option number and/or the value,
> but can be overridden by appending a single letter flag as follows:
> b = one byte, s = two bytes, i = four bytes. This is mainly useful
> with encapsulated vendor class options (see below) where dnsmasq
> cannot determine data size from the option number. Option data which
> consists solely of periods and digits will be interpreted by dnsmasq
> as an IP address, and inserted into an option as such. To force a
> literal string, use quotes. For instance when using option 66 to
> send a literal IP address as TFTP server name, it is necessary to do
> --dhcp-option=66,"1.2.3.4"
> 
> Encapsulated Vendor-class options may also be
> specified (IPv4 only) using --dhcp-option: for instance
> --dhcp-option=vendor:PXEClient,1,0.0.0.0 sends the encapsulated
> vendor class-specific option "mftp-address=0.0.0.0" to any client
> whose vendor-class matches "PXEClient". The vendor-class matching
> is substring based (see --dhcp-vendorclass for details). If a
> vendor-class option (number 60) is sent by dnsmasq, then that is
> used for selecting encapsulated options in preference to any sent
> by the client. It is possible to omit the vendorclass completely;
> --dhcp-option=vendor:,1,0.0.0.0 in which case the encapsulated option
> is always sent.
> 
> Options may be encapsulated (IPv4 only) within other options: for
> instance --dhcp-option=encap:175, 190, iscsi-client0 will send option
> 175, within which is the option 190. If multiple options are given
> which are encapsulated with the same option number then they will be
> correctly combined into one encapsulated option. encap: and vendor:
> are may not both be set in the same --dhcp-option.
> 
> The final variant on encapsulated options is "Vendor-Identifying
> Vendor Options" as specified by RFC3925. 

Re: [Dnsmasq-discuss] Feature request: DHCP options 100 and 101

[Donald Muller]

> -Original Message-
> From: Geert Stappers 
> Sent: Tuesday, November 29, 2022 4:14 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Cc: Joe Pfeiffer ; Donald Muller
> 
> Subject: Re: [Dnsmasq-discuss] Feature request: DHCP options 100 and 101
> 
> On Tue, Nov 29, 2022 at 08:10:18PM +, Donald Muller wrote:
> > From: Dnsmasq-discuss, on behalf of Joe Pfeiffer, Sent: Tuesday,
> November 29, 2022 2:25:59 PM
> > >
> > > At present, dnsmasq supports DHCP option 2 (time-offset), but does
> > > not support options 100 (TZ-POSIX string) or 101 (TZ-Database
> > > String).
> > >
> > > It would be very helpful if options 100 and 101 could be supported, as
> > > they are more human readable and enable daylight savings time
> > > support.  Also, option 2 is deprecated (per
> > > https://www.rfc-editor.org/rfc/rfc4833)
> > >
> > >
> > All options are supported. Just specify the number.
> >
> > --dhcp-option=[tag:,[tag:,]][encap:,][vi-
> encap:,][vendor:[],][|option: name>|option6:|option6:],[[,]]
> > Specify different or extra options to DHCP clients. By default,
> > dnsmasq sends some standard options to DHCP clients, the netmask and
> > broadcast address are set to the same as the host running dnsmasq, and
> > the DNS server and default route are set to the address of the machine
> > running dnsmasq. (Equivalent rules apply for IPv6.) If the domain name
> > option has been set, that is sent. This configuration allows these
> > defaults to be overridden, or other options specified. The option, to
> > be sent may be given as a decimal number or as "option:"
> > The option numbers are specified in RFC2132 and subsequent RFCs. The
> > set of option-names known by dnsmasq can be discovered by running
> > "dnsmasq --help dhcp". For example, to set the default route option
> > to 192.168.4.4, do --dhcp-option=3,192.168.4.4 or --dhcp-option =
> > option:router, 192.168.4.4 and to set the time-server address to
> > 192.168.0.4, do --dhcp-option = 42,192.168.0.4 or --dhcp-option =
> > option:ntp-server, 192.168.0.4 The special address 0.0.0.0 is taken
> > to mean "the address of the machine running dnsmasq".
> >
> > Data types allowed are comma separated dotted-quad IPv4 addresses,
> > []-wrapped IPv6 addresses, a decimal number, colon-separated hex digits
> > and a text string. If the optional tags are given then this option is
> > only sent when all the tags are matched.
> >
> > Special processing is done on a text argument for option 119, to
> > conform with RFC 3397. Text or dotted-quad IP addresses as arguments
> > to option 120 are handled as per RFC 3361. Dotted-quad IP addresses
> > which are followed by a slash and then a netmask size are encoded as
> > described in RFC 3442.
> >
> > IPv6 options are specified using the option6: keyword,
> > followed by the option number or option name. The IPv6 option
> > name space is disjoint from the IPv4 option name space. IPv6
> > addresses in options must be bracketed with square brackets,
> > eg. --dhcp-option=option6:ntp-server,[1234::56] For IPv6, [::] means
> > "the global address of the machine running dnsmasq", whilst [fd00::]
> > is replaced with the ULA, if it exists, and [fe80::] with the link-local
> > address.
> >
> > Be careful: no checking is done that the correct type of data for the
> > option number is sent, it is quite possible to persuade dnsmasq to
> > generate illegal DHCP packets with injudicious use of this flag. When
> > the value is a decimal number, dnsmasq must determine how large the
> data
> > item is. It does this by examining the option number and/or the value,
> > but can be overridden by appending a single letter flag as follows:
> > b = one byte, s = two bytes, i = four bytes. This is mainly useful
> > with encapsulated vendor class options (see below) where dnsmasq
> > cannot determine data size from the option number. Option data which
> > consists solely of periods and digits will be interpreted by dnsmasq
> > as an IP address, and inserted into an option as such. To force a
> > literal string, use quotes. For instance when using option 66 to
> > send a literal IP address as TFTP server name, it is necessary to do
> > --dhcp-option=66,"1.2.3.4"
> >
> > Encapsulated Vendor-class options may also be
> > specified (IPv4 only) using --dhcp-option: for instance
> > --dhcp-option=vendor:PXEClient,1,0.0.0.0 sends the encapsulated
> > vendor class-specific option "mftp-address=0.0.0.0&q

Re: [Dnsmasq-discuss] Feature request: DHCP options 100 and 101

[Donald Muller]

All options are supported. Just specify the number.

O, 
--dhcp-option=[tag:,[tag:,]][encap:,][vi-encap:,][vendor:[],][|option:|option6:|option6:],[[,]]
Specify different or extra options to DHCP clients. By default, dnsmasq sends 
some standard options to DHCP clients, the netmask and broadcast address are 
set to the same as the host running dnsmasq, and the DNS server and default 
route are set to the address of the machine running dnsmasq. (Equivalent rules 
apply for IPv6.) If the domain name option has been set, that is sent. This 
configuration allows these defaults to be overridden, or other options 
specified. The option, to be sent may be given as a decimal number or as 
"option:" The option numbers are specified in RFC2132 and 
subsequent RFCs. The set of option-names known by dnsmasq can be discovered by 
running "dnsmasq --help dhcp". For example, to set the default route option to 
192.168.4.4, do --dhcp-option=3,192.168.4.4 or --dhcp-option = option:router, 
192.168.4.4 and to set the time-server address to 192.168.0.4, do --dhcp-option 
= 42,192.168.0.4 or --dhcp-option = option:ntp-server, 192.168.0.4 The special 
address 0.0.0.0 is taken to mean "the address of the machine running dnsmasq".

Data types allowed are comma separated dotted-quad IPv4 addresses, []-wrapped 
IPv6 addresses, a decimal number, colon-separated hex digits and a text string. 
If the optional tags are given then this option is only sent when all the tags 
are matched.

Special processing is done on a text argument for option 119, to conform with 
RFC 3397. Text or dotted-quad IP addresses as arguments to option 120 are 
handled as per RFC 3361. Dotted-quad IP addresses which are followed by a slash 
and then a netmask size are encoded as described in RFC 3442.

IPv6 options are specified using the option6: keyword, followed by the option 
number or option name. The IPv6 option name space is disjoint from the IPv4 
option name space. IPv6 addresses in options must be bracketed with square 
brackets, eg. --dhcp-option=option6:ntp-server,[1234::56] For IPv6, [::] means 
"the global address of the machine running dnsmasq", whilst [fd00::] is 
replaced with the ULA, if it exists, and [fe80::] with the link-local address.

Be careful: no checking is done that the correct type of data for the option 
number is sent, it is quite possible to persuade dnsmasq to generate illegal 
DHCP packets with injudicious use of this flag. When the value is a decimal 
number, dnsmasq must determine how large the data item is. It does this by 
examining the option number and/or the value, but can be overridden by 
appending a single letter flag as follows: b = one byte, s = two bytes, i = 
four bytes. This is mainly useful with encapsulated vendor class options (see 
below) where dnsmasq cannot determine data size from the option number. Option 
data which consists solely of periods and digits will be interpreted by dnsmasq 
as an IP address, and inserted into an option as such. To force a literal 
string, use quotes. For instance when using option 66 to send a literal IP 
address as TFTP server name, it is necessary to do --dhcp-option=66,"1.2.3.4"

Encapsulated Vendor-class options may also be specified (IPv4 only) using 
--dhcp-option: for instance --dhcp-option=vendor:PXEClient,1,0.0.0.0 sends the 
encapsulated vendor class-specific option "mftp-address=0.0.0.0" to any client 
whose vendor-class matches "PXEClient". The vendor-class matching is substring 
based (see --dhcp-vendorclass for details). If a vendor-class option (number 
60) is sent by dnsmasq, then that is used for selecting encapsulated options in 
preference to any sent by the client. It is possible to omit the vendorclass 
completely; --dhcp-option=vendor:,1,0.0.0.0 in which case the encapsulated 
option is always sent.

Options may be encapsulated (IPv4 only) within other options: for instance 
--dhcp-option=encap:175, 190, iscsi-client0 will send option 175, within which 
is the option 190. If multiple options are given which are encapsulated with 
the same option number then they will be correctly combined into one 
encapsulated option. encap: and vendor: are may not both be set in the same 
--dhcp-option.

The final variant on encapsulated options is "Vendor-Identifying Vendor 
Options" as specified by RFC3925. These are denoted like this: 
--dhcp-option=vi-encap:2, 10, textThe number in the vi-encap: section is the 
IANA enterprise number used to identify this option. This form of encapsulation 
is supported in IPv6.
  The address 0.0.0.0 is not treated specially in encapsulated options.




From: Dnsmasq-discuss  on 
behalf of Joe Pfeiffer 
Sent: Tuesday, November 29, 2022 2:25:59 PM
To: dnsmasq-discuss@lists.thekelleys.org.uk 

Subject: [Dnsmasq-discuss] Feature request: DHCP options 100 and 101

At present, dnsmasq supports DHCP option 2 (time-offset

[Dnsmasq-discuss] Feature request: DHCP options 100 and 101

[Joe Pfeiffer]

At present, dnsmasq supports DHCP option 2 (time-offset), but does
not support options 100 (TZ-POSIX string) or 101 (TZ-Database
String).

It would be very helpful if options 100 and 101 could be supported, as
they are more human readable and enable daylight savings time
support.  Also, option 2 is deprecated (per
https://www.rfc-editor.org/rfc/rfc4833)

___
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

[Ercolino de Spiacico]

> OK, but as you rightly pointed out a couple of messages ago, all these
> operations are performed before the service dnsmasq restart.
>
> Because of this I have performed an additional test to complete the
> picture:
>
> my usual 650K list of domains is now unzipped and I have simply scripted
> the usual formatting with address=/domain/. So no compression involved
> this time. e.g.
>
> /bin/cat /mnt/USB/adblock/adblock.domains | /bin/sed -e "s:^:address=/:"
> -e "s:$:/:"
>
>
> The service dnsmasq restart went from 15.something sec of the script+zip
> version to 14.4 sec of this script only version.
> root at sparrow:/tmp/mnt/USB/adblock# time service dnsmasq restart
> 


> Done.
> real0m 14.43s
> user0m 0.00s
> sys 0m 0.00s
>
> What I was trying to say is that feeding pre-formatted config (as per
> prev message posted here) takes 4.2 sec on the very same file.
>
> And you're right the aim here is to minimize storage hence RAM demand,
> but the dnsmasq restart time must also stay within acceptable levels as
> nobody wants the DNS resolution to be down for too long.
>
> So to summarize: Because the conf-script option works great on RAM
> reduction but takes a big hit on the restart time, I was suggesting if a
> different approach could/should be considered. Since we learnt from this
> last test that the zip operation add only 1-2 sec of delay on the restart
>
> root at sparrow:/mnt/USB/adblock# time gzip -d 
adblock.domains.unloaded.gz

> real0m 1.76s
> user0m 0.67s
> sys 0m 0.18s
>
> perhaps allowing the conf-file to process zipped content (internal zcat
> or something) would suffice to achieve the desired result to minimize
> storage demand and retain restart time within acceptable levels.
> Allowing something like conf-block and import domain only is indeed
> nice-to-have but secondary in my opinion compared to support for
> compressed config:
>
> root at sparrow:/mnt/USB/adblock# ls -lh adblock.domains.unloaded
> -rwxrwxrwx1 root root   14.3M Mar 31 18:42
> root at sparrow:/mnt/USB/adblock# gzip adblock.domains.unloaded
> root at sparrow:/mnt/USB/adblock# ls -lh adblock.domains.unloaded.gz
> -rwxrwxrwx1 root root4.2M Mar 31 18:42


Simon, it is not my intention to put pressure or else but I just wanted 
to give a final feedback on this topic. The conf-script is not usable on 
a router for large lists/config. It simply takes dnsmasq far too long to 
restart. There are a series of event that restart dnsmasq from a simple 
Save Config from the GUI to an automatic event e.g. a multiWAN swap due 
to external factors and anything in between. on a 1M record blocklist it 
takes dnsmasq almost 30 before before it can resolve domains again.


On one side I'm grateful this was considered by the dnsmasq team, on the 
other side I still believe (as per message above) that allowing dnsmasq 
to read natively a conf-file in .gz would actually be the simplest and 
possibly most effective of the solutions to resolve the large list 
issue. On plain config (conf-file) even a huge file takes dnsmasq 5-6 
seconds to restart. The gzip operation on such file are about 1 sec on 
top which is totally an acceptable compromise. Finally the size of a 1M 
records conf-file compresses down from 40M to 8Mb.

A win win.

I'm not sure if you still have interest in tackling this topic but I 
felt a feedback is expected as a minimum given all the work done so far. 
It would be good to know either ways if you don't mind.


Thanks!

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

[Dnsmasq-discuss] [Feature-Request] Make HighLoad constant value configurable from config.h

[Серж ИвановЪ]

I am talking about this part of code in src/dhcp.c
```
struct ping_result *do_icmp_ping(time_t now, struct in_addr addr, unsigned
int h
{
static struct ping_result dummy;
struct ping_result *r, *victim = NULL;
int count, max = (int)(0.6 * (((float)PING_CACHE_TIME)/
   ((float)PING_WAIT)));
```

0.6 should be configurable via compile-time constants, not hard-coded
___
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

[Ercolino de Spiacico]

My understanding is that the script-conf feature was to be used to 
reduce filesystem storage usage, ie instead of a conf-file full of lines 
like


address=/domain1.com/
address=/domain2.com/

Juts the list of domains could be stored, in compressed form, and then 
they would be decompressed and decorated with the address=/./ stuff 
on the fly before being fed into the dnsmasq configuration parser.


The  scripts you posted earlier seemed to

1) Download the block list.
2) compress it
3) feed it to dnsmasq which decompresses it

Which is the worst of all possible worlds, since it uses more storage 
for the compressed AND uncompressed versions, and more CPU to the 
compression and decompression. It also make the down-time depend on how 
fast the block list downloads.



OK, but as you rightly pointed out a couple of messages ago, all these 
operations are performed before the service dnsmasq restart.


Because of this I have performed an additional test to complete the 
picture:


my usual 650K list of domains is now unzipped and I have simply scripted 
the usual formatting with address=/domain/. So no compression involved 
this time. e.g.


/bin/cat /mnt/USB/adblock/adblock.domains | /bin/sed -e "s:^:address=/:" 
-e "s:$:/:"



The service dnsmasq restart went from 15.something sec of the script+zip 
version to 14.4 sec of this script only version.

root@sparrow:/tmp/mnt/USB/adblock# time service dnsmasq restart

Done.
real0m 14.43s
user0m 0.00s
sys 0m 0.00s

What I was trying to say is that feeding pre-formatted config (as per 
prev message posted here) takes 4.2 sec on the very same file.


And you're right the aim here is to minimize storage hence RAM demand, 
but the dnsmasq restart time must also stay within acceptable levels as 
nobody wants the DNS resolution to be down for too long.


So to summarize: Because the conf-script option works great on RAM 
reduction but takes a big hit on the restart time, I was suggesting if a 
different approach could/should be considered. Since we learnt from this 
last test that the zip operation add only 1-2 sec of delay on the restart


root@sparrow:/mnt/USB/adblock# time gzip -d adblock.domains.unloaded.gz
real0m 1.76s
user0m 0.67s
sys 0m 0.18s

perhaps allowing the conf-file to process zipped content (internal zcat 
or something) would suffice to achieve the desired result to minimize 
storage demand and retain restart time within acceptable levels. 
Allowing something like conf-block and import domain only is indeed 
nice-to-have but secondary in my opinion compared to support for 
compressed config:


root@sparrow:/mnt/USB/adblock# ls -lh adblock.domains.unloaded
-rwxrwxrwx1 root root   14.3M Mar 31 18:42
root@sparrow:/mnt/USB/adblock# gzip adblock.domains.unloaded
root@sparrow:/mnt/USB/adblock# ls -lh adblock.domains.unloaded.gz
-rwxrwxrwx1 root root4.2M Mar 31 18:42


My 2 cents

___
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

[Simon Kelley]

On 30/03/2022 12:13, Ercolino de Spiacico wrote:
It looks like your script which downloads the blocked domains file and 
compresses it takes 15s, then dnsmasq takes 15s to uncompress the list 
and load it into memory and sort.


The first delay can be solved by doing the download before stopping 
the old dnsmasq process. The second is amenable the new option to 
SIGTERM the old dnsmasq _after_ parsing the new config.


I run some additional test to verify the impact. I got the very same 
list (650K records) unzipped and pre-formatted (address=/$domain/) to be 
used by the standard conf-file directive. As we used to do before the 
conf-script was introduced. Here the result:


root@sparrow:/tmp/mnt/USB/adblock# time service dnsmasq restart
..
Done.
real    0m 4.21s
user    0m 0.00s
sys 0m 0.01s

The amazing part is that there's no measurable delay in the change of 
ownership from root to nobody. So 4.2 seconds and that's it which is 
completely acceptable for this list size. But then we're back to square 
1 before this conversation ever happened. So I'm starting to conclude 
that the scripting part (script-conf) and it's interpretation 
internally, despite being flexible in terms of wanted output, it doesn't 
scale well on large block-files. Fair enough admittedly this has never 
been the reason why dnsmasq was originally created.


This also make me think further about two (potentially even overlapping) 
ways to progress:


A- Going back to my original idea to have a new conf-block (or 
block-conf whichever) directive where any domain defined in the target 
file will be blocked (only domains without formatting) dnsmasq would do 
an internal interpretation of this list of domains based on the 
directive. So smaller list size and no extra processing needed. This 
perhaps could be an option to have the cake and eat it?


B- Allow the conf-block= and/or the existing conf-file= to read a zipped 
source e.g.

conf-block=z,/bla/bla/file.gz
conf-file=z,/bla/bla/file.gz
Again no scripting/manipulation but taking advantage of the on-the-fly 
decompression





My understanding is that the script-conf feature was to be used to 
reduce filesystem storage usage, ie instead of a conf-file full of lines 
like


address=/domain1.com/
address=/domain2.com/

Juts the list of domains could be stored, in compressed form, and then 
they would be decompressed and decorated with the address=/./ stuff 
on the fly before being fed into the dnsmasq configuration parser.


The  scripts you posted earlier seemed to

1) Download the block list.
2) compress it
3) feed it to dnsmasq which decompresses it

Which is the worst of all possible worlds, since it uses more storage 
for the compressed AND uncompressed versions, and more CPU to the 
compression and decompression. It also make the down-time depend on how 
fast the block list downloads.


Simon.


___
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

[Ercolino de Spiacico]

It looks like your script which downloads the blocked domains file and 
compresses it takes 15s, then dnsmasq takes 15s to uncompress the list 
and load it into memory and sort.


The first delay can be solved by doing the download before stopping the 
old dnsmasq process. The second is amenable the new option to SIGTERM 
the old dnsmasq _after_ parsing the new config.


I run some additional test to verify the impact. I got the very same 
list (650K records) unzipped and pre-formatted (address=/$domain/) to be 
used by the standard conf-file directive. As we used to do before the 
conf-script was introduced. Here the result:


root@sparrow:/tmp/mnt/USB/adblock# time service dnsmasq restart
..
Done.
real0m 4.21s
user0m 0.00s
sys 0m 0.01s

The amazing part is that there's no measurable delay in the change of 
ownership from root to nobody. So 4.2 seconds and that's it which is 
completely acceptable for this list size. But then we're back to square 
1 before this conversation ever happened. So I'm starting to conclude 
that the scripting part (script-conf) and it's interpretation 
internally, despite being flexible in terms of wanted output, it doesn't 
scale well on large block-files. Fair enough admittedly this has never 
been the reason why dnsmasq was originally created.


This also make me think further about two (potentially even overlapping) 
ways to progress:


A- Going back to my original idea to have a new conf-block (or 
block-conf whichever) directive where any domain defined in the target 
file will be blocked (only domains without formatting) dnsmasq would do 
an internal interpretation of this list of domains based on the 
directive. So smaller list size and no extra processing needed. This 
perhaps could be an option to have the cake and eat it?


B- Allow the conf-block= and/or the existing conf-file= to read a zipped 
source e.g.

conf-block=z,/bla/bla/file.gz
conf-file=z,/bla/bla/file.gz
Again no scripting/manipulation but taking advantage of the on-the-fly 
decompression



thanks

___
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

[Simon Kelley]

On 28/03/2022 11:49, Ercolino de Spiacico wrote:


This Internet list above (https://hosts.oisd.nl) is 40MB 
uncompressed, the regex extracts domains-only so shrinking it to 60% 
of its original size and the gzip compression shrinks much further. 
Decompressing and scripting it up of course takes time.



All of that looks like stuff which can be done before stopping 
dnsmasq, right. SO how long it takes makes no difference to how long 
DNS and DHCP service is interrupted for?




I just reported what's done to potentially try to replicate that's all. 
So going straight to the point:


root@sparrow:/# zcat /mnt/USB/adblock/adblock.domains.gz | wc -l
658839

root@sparrow:/# time service dnsmasq restart
. 


Done.
real    0m 15.76s
user    0m 0.01s
sys 0m 0.00s

But please note, at this point the process is still owned by root

root@sparrow:/# ps | grep [d]nsmasq
31137 root 13264 S    dnsmasq -c 4096 --log-async

Until this is delegated to nobody (15 more seconds I'd say) name 
resolution is not performed. So 30sec in total? And this is with a list 
of 650K records, well below the maximum we managed to push on the same 
router with unscripted config which accounted for 1.8M.


It looks like your script which downloads the blocked domains file and 
compresses it takes 15s, then dnsmasq takes 15s to uncompress the list 
and load it into memory and sort.


The first delay can be solved by doing the download before stopping the 
old dnsmasq process. The second is amenable the new option to SIGTERM 
the old dnsmasq _after_ parsing the new config.





Right! Could you please share more details on this idea? It could be 
a smart workaround indeed.





When dnsmasq starts up, it does roughly the following things:

1) Read config files (including execute script-conf
2) organise the data from the config into in-memory data structures
3) Open listening sockets on DNS and DHCP ports.
4) Enter the event loop.

1) and 2) are likely to take an appreciaable amount of time with big 
block lists. 3) and 4) never do.


A restart of dnsmasq  consists of

1) send SIGTERM to existing dnsmasq process to cause it to halt.
2) Run new dnsmasq instance, which goes through the four steps above.

If reading the congfig takes time, that causes service interruption. 
Note that you can't do those two steps in the opposite order, since 
the old dnsmasq process will still be listening on the DNS and DHCP 
ports, and the new one will fail to start up.


If we add an option to dnsmasq which takes a process-ID and sends a 
SIGTERM to that process-ID as step 2.5, the old dnsmasq process can 
continue to run during the parsing of the options, then the it gets 
toen down before opening listening sockets.


The restart now just runs the new dnsmasq instance, passing the PID of 
the old dnsmasq instance if it exists.


Ok understood. Interesting it raises 3 questions on my side:

1- say the old process is already handling 1M blocked domains, I suppose 
this means that for the time of the restarting the RAM demand will be 
pushed to the equivalent of 2M domains (1M old + 1M new), right?


Right.


2- this will certainly help the restart but there's nothing that can 
save us from the first ever start after a device reboot I suppose


No.


3- Is there any option to hand over the existing resolution cache 
between the "leaver" and "joiner" process? Like a memory mapping swap or 
something?


It could be done, but it's a huge rewrite.

Simon.



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



___
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

[Ercolino de Spiacico]

This Internet list above (https://hosts.oisd.nl) is 40MB uncompressed, 
the regex extracts domains-only so shrinking it to 60% of its original 
size and the gzip compression shrinks much further. Decompressing and 
scripting it up of course takes time.



All of that looks like stuff which can be done before stopping dnsmasq, 
right. SO how long it takes makes no difference to how long DNS and DHCP 
service is interrupted for?




I just reported what's done to potentially try to replicate that's all. 
So going straight to the point:


root@sparrow:/# zcat /mnt/USB/adblock/adblock.domains.gz | wc -l
658839

root@sparrow:/# time service dnsmasq restart
.
Done.
real0m 15.76s
user0m 0.01s
sys 0m 0.00s

But please note, at this point the process is still owned by root

root@sparrow:/# ps | grep [d]nsmasq
31137 root 13264 Sdnsmasq -c 4096 --log-async

Until this is delegated to nobody (15 more seconds I'd say) name 
resolution is not performed. So 30sec in total? And this is with a list 
of 650K records, well below the maximum we managed to push on the same 
router with unscripted config which accounted for 1.8M.





Right! Could you please share more details on this idea? It could be a 
smart workaround indeed.





When dnsmasq starts up, it does roughly the following things:

1) Read config files (including execute script-conf
2) organise the data from the config into in-memory data structures
3) Open listening sockets on DNS and DHCP ports.
4) Enter the event loop.

1) and 2) are likely to take an appreciaable amount of time with big 
block lists. 3) and 4) never do.


A restart of dnsmasq  consists of

1) send SIGTERM to existing dnsmasq process to cause it to halt.
2) Run new dnsmasq instance, which goes through the four steps above.

If reading the congfig takes time, that causes service interruption. 
Note that you can't do those two steps in the opposite order, since the 
old dnsmasq process will still be listening on the DNS and DHCP ports, 
and the new one will fail to start up.


If we add an option to dnsmasq which takes a process-ID and sends a 
SIGTERM to that process-ID as step 2.5, the old dnsmasq process can 
continue to run during the parsing of the options, then the it gets toen 
down before opening listening sockets.


The restart now just runs the new dnsmasq instance, passing the PID of 
the old dnsmasq instance if it exists.


Ok understood. Interesting it raises 3 questions on my side:

1- say the old process is already handling 1M blocked domains, I suppose 
this means that for the time of the restarting the RAM demand will be 
pushed to the equivalent of 2M domains (1M old + 1M new), right?


2- this will certainly help the restart but there's nothing that can 
save us from the first ever start after a device reboot I suppose


3- Is there any option to hand over the existing resolution cache 
between the "leaver" and "joiner" process? Like a memory mapping swap or 
something?


___
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

[Simon Kelley]

On 27/03/2022 08:52, Ercolino de Spiacico wrote:

 >> [ -f list.of.domain ] && { create the formatted configuration }
 >>
 >> would always fail at dnsmasq level if the list.of.domains doesn't exist
 >> despite the file existence condition defined. I'm not sure this is 
meant

 >> to be and/or if there's a smart workaround that can be used.
 >
 > I don't understand this, could you give more details.


Ok I have progressed on this point since. Basically I worked out the 
dnsmasq is checking the script exit code. as I had something like this 
in the script:


[ -f list.of.domain ] && { create the formatted configuration }

I just had to "force" the exit 0 to the command so:

[ -f list.of.domain ] && { create the formatted configuration } || { 
exit 0; }


This makes the script returning exit 0 regardless and have --test 
ignoring (rightly) any issue with that part of the script. Wanted so 
good enough for me.






 > Note that having loaded the config, dnsmasq has to sort all the domains,
 > which will be part of the time taken. Doing that once makes the lookups
 > much faster.


As part of the adblock.domain formatting I feed it to dnsmasq after a 
sort -u so somehow it's already sorted, Could this internal sorting be 
optionally skipped?





Not safely. If it's not sorted or sorted wrong, dnsmasq will break.





 > How long are you without DNS service?
 >


It's proportional to the number of records in the adblock file. For 
large lists, on a fast router it can easy go into the 15+ seconds. This 
happens relatively frequently on a router where external conditions 
restart dnsmasq "just in case". So answering your question in detail, 
given a relatively basic scripting config:


###
DOMAINS="/tmp/adblock.domains"

/usr/bin/wget --no-check-certificate -T 15 -q -U "Mozilla/5.0 (X11; 
Linux x86_64; rv:10.0) Gecko/20100101 Firefox/98.0.1" -O- 
https://hosts.oisd.nl | grep -Ev 
'^#.*|^!.*|^::|^\s*?$|^([a-f0-9:]+:+)+[a-f0-9]+' | grep -Eo 
'((([a-zA-Z]{1,2})|([0-9]{1,2})|([a-zA-Z0-9]{1,2})|([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]))\.)+[a-zA-Z]{2,6}' 
| sort -u > $DOMAINS


gzip /tmp/adblock.domains

echo "script-conf=/tmp/script.sh" >> /etc/dnsmasq.conf

echo -e "#!/bin/sh\nset -e\n[ -f ${DOMAINS} ] && /bin/zcat ${DOMAINS}.gz 
| /bin/sed -e \"s:^:address=/:\" -e \"s:$:/:\" || exit 0" > /tmp/script.sh


chmod 777 /tmp/script.sh
###

At this point restarting should give you a magnitude of time. Of course 
on a fast PC/VM this might not be that much, on a router where in the 
best of the cases you have 2x 800/1000MHz the delay is surely noticeable.


This Internet list above (https://hosts.oisd.nl) is 40MB uncompressed, 
the regex extracts domains-only so shrinking it to 60% of its original 
size and the gzip compression shrinks much further. Decompressing and 
scripting it up of course takes time.



All of that looks like stuff which can be done before stopping dnsmasq, 
right. SO how long it takes makes no difference to how long DNS and DHCP 
service is interrupted for?




 > One possible solution is to add an option to dnsmasq which causes it to
 > send SIGTERM is a process-id _after_ reading config and _before_ opening
 > network sockets. That would delay stopping the old dnsmasq process until
 > the new one is almost ready to go. Would require some clever scripting
 > in the init system or systemd to make it work.


Right! Could you please share more details on this idea? It could be a 
smart workaround indeed.





When dnsmasq starts up, it does roughly the following things:

1) Read config files (including execute script-conf
2) organise the data from the config into in-memory data structures
3) Open listening sockets on DNS and DHCP ports.
4) Enter the event loop.

1) and 2) are likely to take an appreciaable amount of time with big 
block lists. 3) and 4) never do.


A restart of dnsmasq  consists of

1) send SIGTERM to existing dnsmasq process to cause it to halt.
2) Run new dnsmasq instance, which goes through the four steps above.

If reading the congfig takes time, that causes service interruption. 
Note that you can't do those two steps in the opposite order, since the 
old dnsmasq process will still be listening on the DNS and DHCP ports, 
and the new one will fail to start up.


If we add an option to dnsmasq which takes a process-ID and sends a 
SIGTERM to that process-ID as step 2.5, the old dnsmasq process can 
continue to run during the parsing of the options, then the it gets toen 
down before opening listening sockets.


The restart now just runs the new dnsmasq instance, passing the PID of 
the old dnsmasq instance if it exists.



Cheers,

Simon.


Thanks

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



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk

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

[Ercolino de Spiacico]

>> [ -f list.of.domain ] && { create the formatted configuration }
>>
>> would always fail at dnsmasq level if the list.of.domains doesn't exist
>> despite the file existence condition defined. I'm not sure this is 
meant

>> to be and/or if there's a smart workaround that can be used.
>
> I don't understand this, could you give more details.


Ok I have progressed on this point since. Basically I worked out the 
dnsmasq is checking the script exit code. as I had something like this 
in the script:


[ -f list.of.domain ] && { create the formatted configuration }

I just had to "force" the exit 0 to the command so:

[ -f list.of.domain ] && { create the formatted configuration } || { 
exit 0; }


This makes the script returning exit 0 regardless and have --test 
ignoring (rightly) any issue with that part of the script. Wanted so 
good enough for me.






> Note that having loaded the config, dnsmasq has to sort all the domains,
> which will be part of the time taken. Doing that once makes the lookups
> much faster.


As part of the adblock.domain formatting I feed it to dnsmasq after a 
sort -u so somehow it's already sorted, Could this internal sorting be 
optionally skipped?






> How long are you without DNS service?
>


It's proportional to the number of records in the adblock file. For 
large lists, on a fast router it can easy go into the 15+ seconds. This 
happens relatively frequently on a router where external conditions 
restart dnsmasq "just in case". So answering your question in detail, 
given a relatively basic scripting config:


###
DOMAINS="/tmp/adblock.domains"

/usr/bin/wget --no-check-certificate -T 15 -q -U "Mozilla/5.0 (X11; 
Linux x86_64; rv:10.0) Gecko/20100101 Firefox/98.0.1" -O- 
https://hosts.oisd.nl | grep -Ev 
'^#.*|^!.*|^::|^\s*?$|^([a-f0-9:]+:+)+[a-f0-9]+' | grep -Eo 
'((([a-zA-Z]{1,2})|([0-9]{1,2})|([a-zA-Z0-9]{1,2})|([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]))\.)+[a-zA-Z]{2,6}' 
| sort -u > $DOMAINS


gzip /tmp/adblock.domains

echo "script-conf=/tmp/script.sh" >> /etc/dnsmasq.conf

echo -e "#!/bin/sh\nset -e\n[ -f ${DOMAINS} ] && /bin/zcat ${DOMAINS}.gz 
| /bin/sed -e \"s:^:address=/:\" -e \"s:$:/:\" || exit 0" > /tmp/script.sh


chmod 777 /tmp/script.sh
###

At this point restarting should give you a magnitude of time. Of course 
on a fast PC/VM this might not be that much, on a router where in the 
best of the cases you have 2x 800/1000MHz the delay is surely noticeable.


This Internet list above (https://hosts.oisd.nl) is 40MB uncompressed, 
the regex extracts domains-only so shrinking it to 60% of its original 
size and the gzip compression shrinks much further. Decompressing and 
scripting it up of course takes time.






> One possible solution is to add an option to dnsmasq which causes it to
> send SIGTERM is a process-id _after_ reading config and _before_ opening
> network sockets. That would delay stopping the old dnsmasq process until
> the new one is almost ready to go. Would require some clever scripting
> in the init system or systemd to make it work.


Right! Could you please share more details on this idea? It could be a 
smart workaround indeed.


Thanks

___
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

[Simon Kelley]

On 24/03/2022 09:28, Ercolino de Spiacico wrote:


I've just added it to 2.87test8

Please test and report back.



Ok after a first implementation on my test environment this is my feedback:

A- Great feature! the scripting + gzip + zcat is a godsend. Yes it 
pushed the CPU up a bit, yes the the script takes longer to execute 
(although this is once/day in the early morning so not important), but 
most importantly the RAM demand decreased drastically.


B- Since conf-file and conf-script make dnsmasq fail if they are defined 
but the target file doesn't exist I have found a simple workaround to 
just touch the all the target files at the top of my adblock script and 
that does the job nicely.



Now the potential further points of improvements I could identify are:

1- Within the conf-script target file I map the list of domains as 
discussed e.g.:


address=/ + $domain + /

For some reason a condition like this:

[ -f list.of.domain ] && { create the formatted configuration }

would always fail at dnsmasq level if the list.of.domains doesn't exist 
despite the file existence condition defined. I'm not sure this is meant 
to be and/or if there's a smart workaround that can be used.


I don't understand this, could you give more details.


2- I have tried to push this into the million of records and I can 
confirm it still perform very well. There one down side though, the time 
needed to restart dnsmasq increased visibly. Somehow it takes too long. 
I guess the conf-script is run at every restart or relevant SIGHUP 


It will run during restart,, but not at SIGHUP.

given. Suppose I'm aware the scripting part is not modified is it worthy 
allowing an extra parameter to the conf-script to retain this specific 
part of the config? e.g.


script-conf=0,populate-config.sh # do not recreate as part of dnsmasq 
restart


script-conf=1,populate-config.sh # (or "1," not defined) always recreate 
as part of restart


Not really practical. The config only exists in the the memory of the 
old dnsmasq process which is discarded as part of the restart.


This somehow also introduced a new minor feature request like allowing 
to detach the conf-script directive (creation of) from any SIGHUP and 
allow them to fully run in async. So that we could reload the dnsmasq 
config without necessarily run the script or all the way around 
regenerate the script manually simply asking dnsmasq to reload the 
(pre-generated) scripted config.


I'm not so much concerned about the adblock script as this ideally will 
run once/day; but I'm rather concerned about external factors triggering 
a dnsmasq restart multiple times/day. This potentially can be very 
disruptive. If this point 2) of mine is a possibility I see that as a 
perfect solution as there's full control on what to trigger and when 
without noticeable dnsmasq downtime.




Note that having loaded the config, dnsmasq has to sort all the domains, 
which will be part of the time taken. Doing that once makes the lookups 
much faster.



How long are you without DNS service?

One possible solution is to add an option to dnsmasq which causes it to 
send SIGTERM is a process-id _after_ reading config and _before_ opening 
network sockets. That would delay stopping the old dnsmasq process until 
the new one is almost ready to go. Would require some clever scripting 
in the init system or systemd to make it work.


Simon.



Thanks

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



___
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

[Ercolino de Spiacico]

I've just added it to 2.87test8

Please test and report back.



Ok after a first implementation on my test environment this is my feedback:

A- Great feature! the scripting + gzip + zcat is a godsend. Yes it 
pushed the CPU up a bit, yes the the script takes longer to execute 
(although this is once/day in the early morning so not important), but 
most importantly the RAM demand decreased drastically.


B- Since conf-file and conf-script make dnsmasq fail if they are defined 
but the target file doesn't exist I have found a simple workaround to 
just touch the all the target files at the top of my adblock script and 
that does the job nicely.



Now the potential further points of improvements I could identify are:

1- Within the conf-script target file I map the list of domains as 
discussed e.g.:


address=/ + $domain + /

For some reason a condition like this:

[ -f list.of.domain ] && { create the formatted configuration }

would always fail at dnsmasq level if the list.of.domains doesn't exist 
despite the file existence condition defined. I'm not sure this is meant 
to be and/or if there's a smart workaround that can be used.


2- I have tried to push this into the million of records and I can 
confirm it still perform very well. There one down side though, the time 
needed to restart dnsmasq increased visibly. Somehow it takes too long. 
I guess the conf-script is run at every restart or relevant SIGHUP 
given. Suppose I'm aware the scripting part is not modified is it worthy 
allowing an extra parameter to the conf-script to retain this specific 
part of the config? e.g.


script-conf=0,populate-config.sh # do not recreate as part of dnsmasq 
restart


script-conf=1,populate-config.sh # (or "1," not defined) always recreate 
as part of restart


This somehow also introduced a new minor feature request like allowing 
to detach the conf-script directive (creation of) from any SIGHUP and 
allow them to fully run in async. So that we could reload the dnsmasq 
config without necessarily run the script or all the way around 
regenerate the script manually simply asking dnsmasq to reload the 
(pre-generated) scripted config.


I'm not so much concerned about the adblock script as this ideally will 
run once/day; but I'm rather concerned about external factors triggering 
a dnsmasq restart multiple times/day. This potentially can be very 
disruptive. If this point 2) of mine is a possibility I see that as a 
perfect solution as there's full control on what to trigger and when 
without noticeable dnsmasq downtime.



Thanks

___
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

[Rance Hall via Dnsmasq-discuss]

Ercolino:I can't speak for Simon and the rest of the Dnsmasq team (mostly because I'm not on it) but I 
appreciate your discussion and explanation of your need.  I would have responded sooner, but I've had a 
medical emergency with my wife and was off the net for a few days being with family in the hospital.Now your 
comparison to the state of TFTP in my judgement isn't of the same caliber.  If the TFTP root is not present 
then the only issue is that a handful of netbooting clients wont work at all, and you'll get immediate 
feedback (on an impacted system) that you broke something, AND anything that booted on its own will be 
fine.If the supplemental config script were to not be present and skipped, you wouldnt get the immediate 
feedback that something wasn't working, AND you couldn't guarantee a safe state for the server instance.It 
seems to me that you have a legitimate issue, but there are other ways to implement what you need to happen 
that don't require changing Dnsmasq at all.1) manipulating the boot order such that Dnsmasq starts AFTER the 
USB subsystem is loaded and the supplemental file system is mounted.2) The file system on the embedded device 
shouldn't be read-only and you should be able to copy the supplemental config script from the USB key to the 
root filesystem of the device and then it would be available when the system booted and your mount sequencing 
issue would go away.RanceOn Mar 4, 2022, at 2:52 PM, Ercolino de Spiacico  
wrote:>How does dnsmasq behave if there is a configuration error in the config >file elsewhere?  If the 
syntax is broken then it fails hard. Don't see >why this wouldn't be true of a suplemental config script 
being referred >to in the main one.And as to --fail-safe:  I don't see how this is >reasonable, as it 
will lead to undesirable operation and possibly even >broken clients if the mistake includes part of the 
dhcp >configuration.Its annoying, but probably better for services not to >start if they can't 
interpret/understand their starting statI appreciate the reason why this was originally designed to be the 
default behavior however please allow me: this conf-script might be is another beast.I'm on a router 
developing this, the dnsmasq config is read at boot from the content of a nvram variable. By the time dnsmasq 
starts I must already have this conf-script target created, the USB mounting comes way after everything else 
and the script booting process is screwed; NTP doesn't sync, clients don't get an IP... you name it. Also if 
the device has no USB this needs to be referenced and created in /tmp (RAM) at boot, this is via the init 
script that again is coming in a bit too late in the SoE. Until this file is created dnsmasq fails. Moreover 
there's an additional risk here, part of the config content is coming from Internet so outside the 
administrative domain. A typo by the list maintainer might cause havoc, most importantly, this is not 
necessary when the device is initially set up, it can come after months and affect a large number of devices 
at one.I really don't want to sound insistent but let me put it this way, long time ago I brought up this 
very topic in the context of TFTP. If the destination folder of TFTP didn't exist it used to fail dnsmasq 
(big time on a router). Then fortunately the tftp-no-fail directive was introduced.This conf-script is pretty 
much the same case but in a different context. If this extra info here above is still not enough I'll drop 
the ball, but I'm just making a final effort because I see value in it, that's 
all.Regards___Dnsmasq-discuss mailing 
listdnsmasq-disc...@lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss___
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

[Simon Kelley]

On 04/03/2022 20:12, Ercolino de Spiacico wrote:
 >How does dnsmasq behave if there is a configuration error in the 
config >file elsewhere?  If the syntax is broken then it fails hard. 
Don't see >why this wouldn't be true of a suplemental config script 
being referred >to in the main one.And as to --fail-safe:  I don't see 
how this is >reasonable, as it will lead to undesirable operation and 
possibly even >broken clients if the mistake includes part of the dhcp 
 >configuration.Its annoying, but probably better for services not to 
 >start if they can't interpret/understand their starting stat


I appreciate the reason why this was originally designed to be the 
default behavior however please allow me: this conf-script might be is 
another beast.


I'm on a router developing this, the dnsmasq config is read at boot from 
the content of a nvram variable. By the time dnsmasq starts I must 
already have this conf-script target created, the USB mounting comes way 
after everything else and the script booting process is screwed; NTP 
doesn't sync, clients don't get an IP... you name it. Also if the device 
has no USB this needs to be referenced and created in /tmp (RAM) at 
boot, this is via the init script that again is coming in a bit too late 
in the SoE. Until this file is created dnsmasq fails. Moreover there's 
an additional risk here, part of the config content is coming from 
Internet so outside the administrative domain. A typo by the list 
maintainer might cause havoc, most importantly, this is not necessary 
when the device is initially set up, it can come after months and affect 
a large number of devices at one.


I really don't want to sound insistent but let me put it this way, long 
time ago I brought up this very topic in the context of TFTP. If the 
destination folder of TFTP didn't exist it used to fail dnsmasq (big 
time on a router). Then fortunately the tftp-no-fail directive was 
introduced.


This conf-script is pretty much the same case but in a different 
context. If this extra info here above is still not enough I'll drop the 
ball, but I'm just making a final effort because I see value in it, 
that's all.


If the conf-script fails in a non-fatal manner, it has the option to 
return a zero exit code.


It must be the case that a conf-script should be able to cause an abort 
on start up, but it has contrl over that.


Another option would be to use the --test flag in the startup script.

if dnsmasq --test --conf-script=. fails, then start up dnsmasq 
without the --conf-script option, maybe?




Simon.


Regards

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



___
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

[Ercolino de Spiacico]

>How does dnsmasq behave if there is a configuration error in the 
config >file elsewhere?  If the syntax is broken then it fails hard. 
Don't see >why this wouldn't be true of a suplemental config script 
being referred >to in the main one.And as to --fail-safe:  I don't see 
how this is >reasonable, as it will lead to undesirable operation and 
possibly even >broken clients if the mistake includes part of the dhcp 
>configuration.Its annoying, but probably better for services not to 
>start if they can't interpret/understand their starting stat


I appreciate the reason why this was originally designed to be the 
default behavior however please allow me: this conf-script might be is 
another beast.


I'm on a router developing this, the dnsmasq config is read at boot from 
the content of a nvram variable. By the time dnsmasq starts I must 
already have this conf-script target created, the USB mounting comes way 
after everything else and the script booting process is screwed; NTP 
doesn't sync, clients don't get an IP... you name it. Also if the device 
has no USB this needs to be referenced and created in /tmp (RAM) at 
boot, this is via the init script that again is coming in a bit too late 
in the SoE. Until this file is created dnsmasq fails. Moreover there's 
an additional risk here, part of the config content is coming from 
Internet so outside the administrative domain. A typo by the list 
maintainer might cause havoc, most importantly, this is not necessary 
when the device is initially set up, it can come after months and affect 
a large number of devices at one.


I really don't want to sound insistent but let me put it this way, long 
time ago I brought up this very topic in the context of TFTP. If the 
destination folder of TFTP didn't exist it used to fail dnsmasq (big 
time on a router). Then fortunately the tftp-no-fail directive was 
introduced.


This conf-script is pretty much the same case but in a different 
context. If this extra info here above is still not enough I'll drop the 
ball, but I'm just making a final effort because I see value in it, 
that's all.


Regards

___
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

[Rance Hall via Dnsmasq-discuss]

You are most welcome.

Sent from my iPhone

> On Mar 4, 2022, at 12:19 PM, Simon Kelley  wrote:
> 
> Thanks Rance, you saved me from writing the same answer.
> 
> Simon.
> 
> 
>> On 04/03/2022 17:00, Rance Hall via Dnsmasq-discuss wrote:
>> How does dnsmasq behave if there is a configuration error in the config file 
>> elsewhere?  If the syntax is broken then it fails hard.  Don't see why this 
>> wouldn't be true of a suplemental config script being referred to in the 
>> main one.
>> And as to --fail-safe:  I don't see how this is reasonable, as it will lead 
>> to undesirable operation and possibly even broken clients if the mistake 
>> includes part of the dhcp configuration.
>> Its annoying, but probably better for services not to start if they can't 
>> interpret/understand their starting state.
>> Rance
 On Mar 4, 2022, at 4:16 AM, Ercolino de Spiacico  
 wrote:
>>> 
>>> 
>>> > I've just added it to 2.87test8
>>> 
>>> > Please test and report back.
>>> 
>>> 
>>> 
>>> I'm finally managed to find a way to build from sources. One initial
>>> feedback:
>>> 
>>> I cross referenceed the conf script e.g.
>>> 
>>> conf-scrip=/tmp/adblock-expander.sh
>>> 
>>> If the file doesn't exists or has a broken syntax it will make the whole
>>> dnsmasq process failing with a message like "/tmp/adblock-expander.sh
>>> returns a non 0 exit code something"
>>> 
>>> This is perhaps a wider topic and goes a bit out of scope for this
>>> feature request, but perhaps we should:
>>> 
>>> 1) remove this error control for conf-script and simply log+skip errors
>>> rather than crash land the whole dnsmasq.
>>> 
>>> 2) perhaps introducing a new "--fail-safe" option for dnsmasq to extend
>>> point 1) to any broken directive in the configuration
>>> 
>>> 
>>> Thanks!
>>> 
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

___
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

[Simon Kelley]

Thanks Rance, you saved me from writing the same answer.

Simon.


On 04/03/2022 17:00, Rance Hall via Dnsmasq-discuss wrote:
How does dnsmasq behave if there is a configuration error in the config 
file elsewhere?  If the syntax is broken then it fails hard.  Don't see 
why this wouldn't be true of a suplemental config script being referred 
to in the main one.


And as to --fail-safe:  I don't see how this is reasonable, as it will 
lead to undesirable operation and possibly even broken clients if the 
mistake includes part of the dhcp configuration.


Its annoying, but probably better for services not to start if they 
can't interpret/understand their starting state.


Rance

On Mar 4, 2022, at 4:16 AM, Ercolino de Spiacico 
 wrote:



> I've just added it to 2.87test8

> Please test and report back.



I'm finally managed to find a way to build from sources. One initial
feedback:

I cross referenceed the conf script e.g.

conf-scrip=/tmp/adblock-expander.sh

If the file doesn't exists or has a broken syntax it will make the whole
dnsmasq process failing with a message like "/tmp/adblock-expander.sh
returns a non 0 exit code something"

This is perhaps a wider topic and goes a bit out of scope for this
feature request, but perhaps we should:

1) remove this error control for conf-script and simply log+skip errors
rather than crash land the whole dnsmasq.

2) perhaps introducing a new "--fail-safe" option for dnsmasq to extend
point 1) to any broken directive in the configuration


Thanks!

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




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


___
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

[Rance Hall via Dnsmasq-discuss]

How does dnsmasq behave if there is a configuration error in the config file elsewhere?  If the syntax is 
broken then it fails hard.  Don't see why this wouldn't be true of a suplemental config script being referred 
to in the main one.And as to --fail-safe:  I don't see how this is reasonable, as it will lead to undesirable 
operation and possibly even broken clients if the mistake includes part of the dhcp configuration.Its annoying, 
but probably better for services not to start if they can't interpret/understand their starting state.RanceOn 
Mar 4, 2022, at 4:16 AM, Ercolino de Spiacico  wrote:> I've just added it to 
2.87test8> Please test and report back.I'm finally managed to find a way to build from sources. One initial 
feedback:I cross referenceed the conf script e.g.conf-scrip=/tmp/adblock-expander.shIf the file doesn't exists 
or has a broken syntax it will make the whole dnsmasq process failing with a message like 
"/tmp/adblock-expander.sh returns a non 0 exit code something"This is perhaps a wider topic and goes 
a bit out of scope for this feature request, but perhaps we should:1) remove this error control for conf-script 
and simply log+skip errors rather than crash land the whole dnsmasq.2) perhaps introducing a new 
"--fail-safe" option for dnsmasq to extend point 1) to any broken directive in the 
configurationThanks!___Dnsmasq-discuss mailing 
listdnsmasq-disc...@lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss___
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

[Ercolino de Spiacico]

> I've just added it to 2.87test8

> Please test and report back.



I'm finally managed to find a way to build from sources. One initial 
feedback:


I cross referenceed the conf script e.g.

conf-scrip=/tmp/adblock-expander.sh

If the file doesn't exists or has a broken syntax it will make the whole 
dnsmasq process failing with a message like "/tmp/adblock-expander.sh 
returns a non 0 exit code something"


This is perhaps a wider topic and goes a bit out of scope for this 
feature request, but perhaps we should:


1) remove this error control for conf-script and simply log+skip errors 
rather than crash land the whole dnsmasq.


2) perhaps introducing a new "--fail-safe" option for dnsmasq to extend 
point 1) to any broken directive in the configuration



Thanks!

___
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

[Ercolino de Spiacico]

> I've just added it to 2.87test8

> Please test and report back.


I unfortunately don't have a build environment, so I hope someone else 
here can help with the testing...


Looking forward to the outcome.

___
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

[Andrew Miskell via Dnsmasq-discuss]

> On Feb 6, 2022, at 15:55, Ercolino de Spiacico  
> wrote:
> 
> From what version is this --conf-script made available?
> 
> root@router:/tmp# dnsmasq -v
> Dnsmasq version 2.86  Copyright (c) 2000-2021 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN 
> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper auth cryptohash 
> DNSSEC no-ID loop-detect inotify no-dumpfile
> 
> This software comes with ABSOLUTELY NO WARRANTY.
> Dnsmasq is free software, and you are welcome to redistribute it
> under the terms of the GNU General Public License, version 2 or 3.
> root@router:/tmp# dnsmasq --help | grep conf-script
> root@router:/tmp#
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

I don’t think it is actually available. I believe they were discussing the idea 
of such a feature.  
___
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

[Ercolino de Spiacico]

From what version is this --conf-script made available?

root@router:/tmp# dnsmasq -v
Dnsmasq version 2.86  Copyright (c) 2000-2021 Simon Kelley
Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n 
no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper auth 
cryptohash DNSSEC no-ID loop-detect inotify no-dumpfile


This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.
root@router:/tmp# dnsmasq --help | grep conf-script
root@router:/tmp#

___
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

[Simon Kelley]

On 06/02/2022 05:54, Ercolino de Spiacico wrote:

 > Opinions, all?

The scripting solution would indeed solve the original feature request 
in my view. But there's a new point that is now coming into scope.


Just to give the magnitude here I came across lists with 1.2M domains, 
40MB uncompressed pre 'address=//' formatting. Loading such a list 
consumes about 100MB of RAM.


For the sake of ads/domain blocking I have identified two metrics:
a) storage
b) RAM

We normally have two common scenarios:
1) routers without mass storage
2) routers with mass storage available (e.g. USB)

for case 1) the script solution would help both a) and partially b) as 
storage is essentially RAM on those devices.

for case 2) though only a) is affected and somehow not that important here.

Using the script solution I have the feeling that we are still going to 
get the full syntax 'address=/domain.com/' in RAM. But if it was dnsmasq 
to give a different interpretation to the cached data though, so that 
only domains or perhaps a very shorten syntax (e.g. -domain.com) can be 
used, I would expect this to result into a demand reduction on b).


No. The RAM usage once the rule is parsed is always the same. (And you 
really need to be using 2.86 or later, which optimised both RAM and CPU 
for large lists.)


Simon.



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



___
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

[Ercolino de Spiacico]

> Opinions, all?

The scripting solution would indeed solve the original feature request 
in my view. But there's a new point that is now coming into scope.


Just to give the magnitude here I came across lists with 1.2M domains, 
40MB uncompressed pre 'address=//' formatting. Loading such a list 
consumes about 100MB of RAM.


For the sake of ads/domain blocking I have identified two metrics:
a) storage
b) RAM

We normally have two common scenarios:
1) routers without mass storage
2) routers with mass storage available (e.g. USB)

for case 1) the script solution would help both a) and partially b) as 
storage is essentially RAM on those devices.

for case 2) though only a) is affected and somehow not that important here.

Using the script solution I have the feeling that we are still going to 
get the full syntax 'address=/domain.com/' in RAM. But if it was dnsmasq 
to give a different interpretation to the cached data though, so that 
only domains or perhaps a very shorten syntax (e.g. -domain.com) can be 
used, I would expect this to result into a demand reduction on b).


___
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] Feature request = block-conf

[Geert Stappers via Dnsmasq-discuss]

On Sat, Feb 05, 2022 at 11:32:44AM +, Simon Kelley wrote:
> On 04/02/2022 09:46, Ercolino de Spiacico wrote:
> > I have a feature request.
> > 
> > Since dnsmasq is extremely popular on embedded devices with limited
> > resources (e.g. router) it would be a huge improvement to have a new
> > directive to block a list of domains.
> > 
> >   
> > 
> > Could we please have a new directive e.g. block-file
> > 
> > block-conf=/etc/dnsmasq.adblock
> > 
> > where only domains are needed in the mapped file?
> > 
> > baddomain.com
> > baddomain2.com
> > 
> > 
> > This would reduce drastically the demand on storage (so memory). Some of
> > the public adblock lists are huge hence having the adblock file
> > literally 1/2 of the original size would be amazing.
> > 
> 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.
> 
> Analogous to --conf-file, except that the standard output of the script is
> used as the configuration.
> 
> 
> So you could just have a script which consisted of
> 
> #!/bin/sh
> set -e
> 
> gunzip block-domains.gz | sed -e "s:^:address=/:" -e "s:$:/#:"
> 
> 
> The sed stuff might not be necessary: a decent compression algo should hide
> the repeated information pretty successfully itself.
> 
> 
> That solves you problem, and is more generally useful: It's also pretty
> trivial to implement.
> 
> Opinions, all?
> 

Another effect of `--conf-script` is that the script could be

```
#!/bin/sh
set -e
curl http://server.lan:4242/config/magic
```



Groeten
Geert Stappers
-- 
Silence is hard to parse

___
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

[Simon Kelley]

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.


Analogous to --conf-file, except that the standard output of the script 
is used as the configuration.



So you could just have a script which consisted of

#!/bin/sh
set -e

gunzip block-domains.gz | sed -e "s:^:address=/:" -e "s:$:/#:"


The sed stuff might not be necessary: a decent compression algo should 
hide the repeated information pretty successfully itself.



That solves you problem, and is more generally useful: It's also pretty 
trivial to implement.


Opinions, all?


Simon.




On 04/02/2022 09:46, Ercolino de Spiacico wrote:

I have a feature request.

Since dnsmasq is extremely popular on embedded devices with limited 
resources (e.g. router) it would be a huge improvement to have a new 
directive to block a list of domains.


Practical example:
We currently need to add an external file to the main config (preferred) 
e.g.:


conf-file=/etc/dnsmasq.adblock

and define the syntax in a relatively long way

address=/baddomain.com/#
address=/baddomain2.com/#


Suggestion -

Could we please have a new directive e.g. block-file

block-conf=/etc/dnsmasq.adblock

where only domains are needed in the mapped file?

baddomain.com
baddomain2.com


This would reduce drastically the demand on storage (so memory). Some of 
the public adblock lists are huge hence having the adblock file 
literally 1/2 of the original size would be amazing.


Thanks

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



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

[Dnsmasq-discuss] Feature request = block-conf

[Ercolino de Spiacico]

I have a feature request.

Since dnsmasq is extremely popular on embedded devices with limited 
resources (e.g. router) it would be a huge improvement to have a new 
directive to block a list of domains.


Practical example:
We currently need to add an external file to the main config (preferred) 
e.g.:


conf-file=/etc/dnsmasq.adblock

and define the syntax in a relatively long way

address=/baddomain.com/#
address=/baddomain2.com/#


Suggestion -

Could we please have a new directive e.g. block-file

block-conf=/etc/dnsmasq.adblock

where only domains are needed in the mapped file?

baddomain.com
baddomain2.com


This would reduce drastically the demand on storage (so memory). Some of 
the public adblock lists are huge hence having the adblock file 
literally 1/2 of the original size would be amazing.


Thanks

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

[Dnsmasq-discuss] Feature request: delay negative upstream answers

[Basin Ilya]

Hi.
There's a number of internal DNS records in our corporate network and I also 
use a VPN connection through wich the other set of internal DNS records is 
available.
>From each network I dynamically receive a search suffix and a pair of DNS 
>server addresses and add them to /etc/resolv.conf:

nameserver 127.0.0.1
search domain1.com domain2.com
nameserver 10.14.33.139
nameserver 10.14.33.140
nameserver 192.168.149.11
nameserver 192.168.110.11

There are three problems with that:

Not all possible internal search suffixes are received via DHCP. It means that 
I cannot configure dnsmasq to use a specific upstream server for certain 
unknown suffixes. And I have to enable in dnsmasq.conf:

# To use all 4 servers
all-servers

After receiving NXDOMAIN from one of the servers Dnsmasq immediately returns 
this reply to the client without waiting for other servers to reply.

Even if I drop incoming NXDOMAIN packets with an iptables rule there's a 
problem when a client program tries to resolve an unqualified domain name from 
the second network.
Libc tries the first search suffix from the list and due to the fact that for 
net2-host.domain1.com all four upstream servers return NXDOMAIN (that gets 
dropped) the library waits until it times out and never tries 
net1-host.domain1.com

I found that delaying NXDOMAIN packets with iproute2 solves the 3 problems 
above: https://serverfault.com/a/1067189/149828

However, it seems to me that waiting a little bit more for a positive answer 
should be part of Dnsmasq.

___
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 : NXDOMAIN all domains on network

[dnsmasqlist2021]

On Fri, 19 Mar 2021, James Feeney wrote:


On 3/17/21 7:19 PM, dnsmasqlist2...@rscubed.com wrote:

I would like to use it with the spamhaus DROP list (A list of bad
network blocks) to make all domains (known and currently unknown) on
those networks disappear.


Hmm - how do you actually configure this?  Do you dynamically generate 
/etc/dnsmasq.conf, derived using the spamhaus DROP list?

Could --ignore-address= and --bogus-nxdomain= be made to accept a file name or 
file names of a file or files containing a list of CIDR network ip addresses? 
Perhaps --ignore-address-file= and --bogus-nxdomain-file= ?


James

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




I am just going to do it dynamically with a script once a day...

Something like :

links -source https://www.spamhaus.org/drop/drop.txt |
  grep -v '^;' |
  grep -Eo '^[0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}[/][0-9]{1,2}' |
  awk '{print "bogus-nxdomain="$0}' > /etc/dnsmasq.d/SpamhausDROP.conf

I personally like the bogus-nxdomain better as it seems to return immediately 
and ignore-address seems to timeout.


Matt

___
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 : NXDOMAIN all domains on network

[James Feeney]

On 3/17/21 7:19 PM, dnsmasqlist2...@rscubed.com wrote:
>>> I would like to use it with the spamhaus DROP list (A list of bad
>>> network blocks) to make all domains (known and currently unknown) on
>>> those networks disappear.

Hmm - how do you actually configure this?  Do you dynamically generate 
/etc/dnsmasq.conf, derived using the spamhaus DROP list?

Could --ignore-address= and --bogus-nxdomain= be made to accept a file name or 
file names of a file or files containing a list of CIDR network ip addresses?  
Perhaps --ignore-address-file= and --bogus-nxdomain-file= ?

James

___
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 : NXDOMAIN all domains on network

[dnsmasqlist2021]

That was quick, thanks.

I will have to think of something more challenging we need :)

On Wed, 17 Mar 2021, Simon Kelley wrote:


On 15/03/2021 02:36, dnsmasqlist2...@rscubed.com wrote:


Hello,

Thanks for the many years of support for DNSMasq I have used it for a
long time as a filter for most of my machines and servers.

Currently I think DNSMasq has the ability to sinkhole all domains on an
IP using the bogus-nxdomain feature.

We would like to be able to make all domains on whole networks sinkhole
/ return NXDOMAIN.

So if bogus-nxdomain could be updated to accept a network cidr I think
that would work.

This would be a powerful feature for helping everyone weed out malious
domains in bulk from known bad networks.

I would like to use it with the spamhaus DROP list (A list of bad
network blocks) to make all domains (known and currently unknown) on
those networks disappear.

This would also help stop the new evil CNAME redirector networks by
allowing us to bogus-nxdomain the end network even with the badguys
changing domains/ subdomains regularly.




Done. I needed a bit of low-hanging fruit. The enhancement works for
--ignore-address too.

Cheers,

Simon.


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



___
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 : NXDOMAIN all domains on network

[Simon Kelley]

On 15/03/2021 02:36, dnsmasqlist2...@rscubed.com wrote:
> 
> Hello,
> 
> Thanks for the many years of support for DNSMasq I have used it for a
> long time as a filter for most of my machines and servers.
> 
> Currently I think DNSMasq has the ability to sinkhole all domains on an
> IP using the bogus-nxdomain feature.
> 
> We would like to be able to make all domains on whole networks sinkhole
> / return NXDOMAIN.
> 
> So if bogus-nxdomain could be updated to accept a network cidr I think
> that would work.
> 
> This would be a powerful feature for helping everyone weed out malious
> domains in bulk from known bad networks.
> 
> I would like to use it with the spamhaus DROP list (A list of bad
> network blocks) to make all domains (known and currently unknown) on
> those networks disappear.
> 
> This would also help stop the new evil CNAME redirector networks by
> allowing us to bogus-nxdomain the end network even with the badguys
> changing domains/ subdomains regularly.
> 


Done. I needed a bit of low-hanging fruit. The enhancement works for
--ignore-address too.

Cheers,

Simon.


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

[Dnsmasq-discuss] feature request : NXDOMAIN all domains on network

[dnsmasqlist2021]

Hello,

Thanks for the many years of support for DNSMasq I have used it for a long time 
as a filter for most of my machines and servers.


Currently I think DNSMasq has the ability to sinkhole all domains on an IP using 
the bogus-nxdomain feature.


We would like to be able to make all domains on whole networks sinkhole / return 
NXDOMAIN.


So if bogus-nxdomain could be updated to accept a network cidr I think that 
would work.


This would be a powerful feature for helping everyone weed out malious domains 
in bulk from known bad networks.


I would like to use it with the spamhaus DROP list (A list of bad network 
blocks) to make all domains (known and currently unknown) on those networks 
disappear.


This would also help stop the new evil CNAME redirector networks by allowing us 
to bogus-nxdomain the end network even with the badguys changing domains/ 
subdomains regularly.


thanks

Matt

___
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: add one DNS cache statistic

[Simon Kelley]

On 03/03/2020 09:03, Wim Nelis wrote:
> Hello,
> 
> 
> If the cache statistics are requested, the maximum cache size is
> returned together with the number of insertions and the number of
> deletions before expiration of the cache entry (live freed aka
> evictions). The request is to add preferably the actual cache size or
> alternatively the number of deletions due to expiration of the cache entry.
> 
> Currently one can only see that the cache is too small if the number of
> live freed entries becomes too large. The opposite, the cache is too
> big, is not visible. This can be advantageous to know in a
> resource-limited environment.
> 
> The suggested alternative is based on the assumption that the actual
> size equals the total insertions minus the live freed entries minus the
> expired freed entries.
> 
> 

I think what you probably need here is the maximum cache occupancy, ie
if entries are thrown out of the cache as soon as the expire, what is
the maximum number of cache entries, ever. Unfortunately, that's kind of
difficult to determine, because expired entries only get removed
opportunistically, unless there's pressure for cache space. The maximum
cache occupancy would include a load of already-expired entries which
will never be used again, but which have not been deleted because
finding them takes resources, and there's no need because we've not run
short of cache space.


Simon.


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

[Dnsmasq-discuss] Feature request: add one DNS cache statistic

[Wim Nelis]

  
  

  Hello,
  
  
  If the cache statistics are requested, the maximum cache size
is returned together with the number of insertions and the
number of deletions before expiration of the cache entry (live
freed aka evictions). The request is to add preferably the
actual cache size or alternatively the number of deletions due
to expiration of the cache entry.
  Currently one can only see that the cache is too small if the
number of live freed entries becomes too large. The opposite,
the cache is too big, is not visible. This can be advantageous
to know in a resource-limited environment.
  The suggested alternative is based on the assumption that the
actual size equals the total insertions minus the live freed
entries minus the expired freed entries.
  
  
  Regards,
    Wim Nelis.
  

  


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

Re: [Dnsmasq-discuss] [Feature Request] Tagged server and address configuration

[M. Buecher]

On 2018-11-22 21:24, Simon Kelley wrote:

On 19/11/2018 21:07, M. Buecher wrote:

Hello Simon and dnsmasq fellows,

I blacklist several domains via host files and wanted to skip the
blacklist for my testing client.
Unfortunately I couldn't find a solution for this in the man page, or
maybe I just didn't see the correct config combination.
Or did I miss a way to configure this with the existing features?


So I came up with the idea of tag-matching server and address
configuration, like...
--server=[tag:[,tag:],][/[]/[domain/]][[#][@|[#]]

--address=[tag:[,tag:],]/[/...]/[]

This would provide a highly flexible way to blacklist/whitelist  
domains

for specific clients.
But I assume it may be an ugly coding hell to implement.




The problem lies in the fact that there's nothing in the DNS part of
dnsmasq to determine the tags - the taq-set that's used in the DHCP 
part

of dnsmasq is determined dynamically during each DHCP transaction:
there's no way to make it long-lived and associate it with DNS request
that arrives later.


Cheers,

Simon.




Thanks for the info.

Right now I'm trying to find out how to run multiple dnsmasq instances 
for different interfaces on Debian with systemd.
The second interface shall be a virtual one on the real one with a 
different ip address, so that I can distribute "a different DNS server" 
to my test client.


Thanks for your time
Maddes


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

Re: [Dnsmasq-discuss] [Feature Request] Tagged server and address configuration

[Simon Kelley]

On 19/11/2018 21:07, M. Buecher wrote:
> Hello Simon and dnsmasq fellows,
> 
> I blacklist several domains via host files and wanted to skip the
> blacklist for my testing client.
> Unfortunately I couldn't find a solution for this in the man page, or
> maybe I just didn't see the correct config combination.
> Or did I miss a way to configure this with the existing features?
> 
> 
> So I came up with the idea of tag-matching server and address
> configuration, like...
> --server=[tag:[,tag:],][/[]/[domain/]][[#][@|[#]]
> 
> --address=[tag:[,tag:],]/[/...]/[]
> 
> This would provide a highly flexible way to blacklist/whitelist  domains
> for specific clients.
> But I assume it may be an ugly coding hell to implement.
> 
> 

The problem lies in the fact that there's nothing in the DNS part of
dnsmasq to determine the tags - the taq-set that's used in the DHCP part
of dnsmasq is determined dynamically during each DHCP transaction:
there's no way to make it long-lived and associate it with DNS request
that arrives later.


Cheers,

Simon.



> Kind regards
> Maddes
> 
> 
> 
> 
> ___
> 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] [Feature Request] Tagged server and address configuration

[M. Buecher]

Hello Simon and dnsmasq fellows,

I blacklist several domains via host files and wanted to skip the 
blacklist for my testing client.
Unfortunately I couldn't find a solution for this in the man page, or 
maybe I just didn't see the correct config combination.

Or did I miss a way to configure this with the existing features?


So I came up with the idea of tag-matching server and address 
configuration, like...

--server=[tag:[,tag:],][/[]/[domain/]][[#][@|[#]]
--address=[tag:[,tag:],]/[/...]/[]

This would provide a highly flexible way to blacklist/whitelist  domains 
for specific clients.

But I assume it may be an ugly coding hell to implement.


Kind regards
Maddes




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

Re: [Dnsmasq-discuss] feature request: ipset options

[Leonardo Rodrigues]

    While i can't give you exact configurations, i can say it's a 
simple configuration on dnsmasq feeding some ipset sets based on domains 
(plain simple configuration) and those sets being used by iptables rules.


    While the set sizes simply doesn't matter when you have Gbs of RAM, 
when trying to do that with 32 MB of RAM, things chance a little. So 
that's because i'm trying to squeeze each KB of used memory by reducing 
the ipset set sizes by IP aggregation.



Em 24/04/18 00:23, Eliezer Croitoru escreveu:

Hey Leondaro,

Can you share your setup details?
It's kind of interest me.


-Original Message-
From: Dnsmasq-discuss <dnsmasq-discuss-boun...@lists.thekelleys.org.uk> On 
Behalf Of Leonardo Rodrigues
Sent: Monday, April 23, 2018 23:15
To: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: [Dnsmasq-discuss] feature request: ipset options


  I'm running dnsmasq with ipset support in some VERY low memory machines 
(those all-in-one boards), and RAM is really my main concern here. I'm actually 
using some 'ipset' rules on dnsmasq.conf to have some domains IPs on an ipset 
list and, thus, being able to allow/deny them with iptables.

  Some of the sets are REALLY large (10k+ entries).

  I was thinking on having a dnsmasq option for, instead of adding the full 
IP to the set, adding its /24 network for example (simple stripping last digit 
and adding '.0/24'). In that case, the sets would be significantly smaller. I 
know with this i'll pottentially allowing traffic i'm not looking for, by 
assuming th domain holds the entire /24 network. But i'm really concerned with 
RAM usage, and i'm willing to have that risk.

  Would it be hard to implement something like that in dnsmasq ?
Would this be useful for any one else ?





--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it




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

Re: [Dnsmasq-discuss] feature request: ipset options

[Eliezer Croitoru]

Hey Leondaro,

Can you share your setup details?
It's kind of interest me.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: Dnsmasq-discuss <dnsmasq-discuss-boun...@lists.thekelleys.org.uk> On 
Behalf Of Leonardo Rodrigues
Sent: Monday, April 23, 2018 23:15
To: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: [Dnsmasq-discuss] feature request: ipset options


 I'm running dnsmasq with ipset support in some VERY low memory machines 
(those all-in-one boards), and RAM is really my main concern here. I'm actually 
using some 'ipset' rules on dnsmasq.conf to have some domains IPs on an ipset 
list and, thus, being able to allow/deny them with iptables.

 Some of the sets are REALLY large (10k+ entries).

 I was thinking on having a dnsmasq option for, instead of adding the full 
IP to the set, adding its /24 network for example (simple stripping last digit 
and adding '.0/24'). In that case, the sets would be significantly smaller. I 
know with this i'll pottentially allowing traffic i'm not looking for, by 
assuming th domain holds the entire /24 network. But i'm really concerned with 
RAM usage, and i'm willing to have that risk.

 Would it be hard to implement something like that in dnsmasq ? 
Would this be useful for any one else ?


-- 


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it




___
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] feature request: ipset options

[Simon Kelley]

I'm no ipset expert, but it looks to me like you can get this effect
anyway, by creating the ipset as type hash:ip and specifying a netmask.


http://ipset.netfilter.org/ipset.man.html

hash:ip
The hash:ip set type uses a hash to store IP host addresses (default) or
network addresses. Zero valued IP address cannot be stored in a hash:ip
type of set.
CREATE-OPTIONS := [ family { inet | inet6 } ] | [ hashsize value ] [
maxelem value ] [ netmask cidr ] [ timeout value ] [ counters ] [
comment ] [ skbinfo ]

ADD-ENTRY := ipaddr

ADD-OPTIONS := [ timeout value ] [ packets value ] [ bytes value ] [
comment string ] [ skbmark value ] [ skbprio value ] [ skbqueue value ]

DEL-ENTRY := ipaddr

TEST-ENTRY := ipaddr

Optional create options:

netmask cidr
When the optional netmask parameter specified, network addresses will be
stored in the set instead of IP host addresses. The cidr prefix value
must be between 1-32 for IPv4 and between 1-128 for IPv6. An IP address
will be in the set if the network address, which is resulted by masking
the address with the netmask, can be found in the set. Examples:
ipset create foo hash:ip netmask 30
ipset add foo 192.168.1.0/24
ipset test foo 192.168.1.2


Cheers,

Simon.




On 23/04/18 21:15, Leonardo Rodrigues wrote:
> 
>     I'm running dnsmasq with ipset support in some VERY low memory
 (those all-in-one boards), and RAM is really my main concern
> here. I'm actually using some 'ipset' rules on dnsmasq.conf to have some
> domains IPs on an ipset list and, thus, being able to allow/deny them
> with iptables.
> 
>     Some of the sets are REALLY large (10k+ entries).
> 
>     I was thinking on having a dnsmasq option for, instead of adding the
> full IP to the set, adding its /24 network for example (simple stripping
> last digit and adding '.0/24'). In that case, the sets would be
> significantly smaller. I know with this i'll pottentially allowing
> traffic i'm not looking for, by assuming th domain holds the entire /24
> network. But i'm really concerned with RAM usage, and i'm willing to
> have that risk.
> 
>     Would it be hard to implement something like that in dnsmasq ? Would
> this be useful for any one else ?
> 
> 

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

[Dnsmasq-discuss] feature request: ipset options

[Leonardo Rodrigues]

    I'm running dnsmasq with ipset support in some VERY low memory 
machines (those all-in-one boards), and RAM is really my main concern 
here. I'm actually using some 'ipset' rules on dnsmasq.conf to have some 
domains IPs on an ipset list and, thus, being able to allow/deny them 
with iptables.


    Some of the sets are REALLY large (10k+ entries).

    I was thinking on having a dnsmasq option for, instead of adding 
the full IP to the set, adding its /24 network for example (simple 
stripping last digit and adding '.0/24'). In that case, the sets would 
be significantly smaller. I know with this i'll pottentially allowing 
traffic i'm not looking for, by assuming th domain holds the entire /24 
network. But i'm really concerned with RAM usage, and i'm willing to 
have that risk.


    Would it be hard to implement something like that in dnsmasq ? 
Would this be useful for any one else ?



--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it




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

Re: [Dnsmasq-discuss] Feature Request: IPv6: Enable RA and set its options per dhcp-range

[M. Buecher]

dnsmasq 2.76 (Debian 8 "Jessie" package) enables RA for all dhcp-ranges, 
even if a subnet that dnsmasq got from the dhcp-range constructor method 
is handled by a different router.
This creates multiple RAs for the same subnet, which may cause routing 
issues.
Current workaround is to set the router's priority to high, so that its 
RA superseeds then one of dnsmasq.


Therefore this feature request for an option to enable/disable RA per 
dhcp-range configuration (either explicitly or via tagging).
Additionally it would be great to specify the RA options per dhcp-range 
configuration too.



Easiest way to reproduce is to assign an ULA and a GUA from your other 
router via RA on the NIC (here eth0).

Then use the "constructor" on your NIC.

Example config:
## Unique Local Addresses (ULA) with dynamic+static DHCPv6, no SLAAC 
(="no mode" specified)

dhcp-range=set:ula6,fd7a:d:e:f::1:0,fd7a:d:e:f::1:,64,12h
## sent Router Advertisments (with M[anaged] flag) so that all clients 
create routing information for the ULA; necessary for Windows, most 
Linux clients will automatically create the route via DHCPv6

enable-ra

## Global Unicast Addresses (GUA) and other subnets only with static 
DHCPv6, no SLAAC

dhcp-range=set:gua6,::1:0,::1:,constructor:eth0,static,64,12h

Results:
Aug 20 14:02:36 dnsmasq-dhcp[22348]: DHCPv6, static leases only on 
::0.1.255.255, lease time 12h, template for eth0

Aug 20 14:02:36 dnsmasq-dhcp[22348]: router advertisement on eth0
Aug 20 14:02:36 dnsmasq-dhcp[22348]: DHCPv6, IP range fd7a:d:e:f::1:0 -- 
fd7a:d:e:f::1:, lease time 12h
Aug 20 14:02:36 dnsmasq-dhcp[22348]: router advertisement on 
fd7a:d:e:f::
Aug 20 14:02:36 dnsmasq-dhcp[22348]: DHCPv6, static leases only on 
2003:a:b:c::1:, lease time 12h, constructed for eth0
Aug 20 14:02:36 dnsmasq-dhcp[22348]: router advertisement on 
2003:a:b:c::, constructed for eth0
Aug 20 14:02:36 dnsmasq-dhcp[22348]: DHCPv6, static leases only on 
fd7a:d:e:f::1:, lease time 12h, constructed for eth0
Aug 20 14:02:36 dnsmasq-dhcp[22348]: router advertisement on 
fd7a:d:e:f::, constructed for eth0

Aug 20 14:02:36 dnsmasq-dhcp[22348]: RTR-ADVERT(eth0) 2003:a:b:c::
Aug 20 14:02:36 dnsmasq-dhcp[22348]: RTR-ADVERT(eth0) fd7a:d:e:f::
Aug 20 14:02:36 dnsmasq-dhcp[22348]: IPv6 router advertisement enabled


Kind regards
Matthias Bücher


On 2017-08-20 14:06, M. Buecher wrote:


On 2017-08-18 15:38, M. Buecher wrote:


Hello dnsmasq fellows,
Hello Simon,

I want to assign additional static DHCPv6 global unicast addresses 
(GUA) to some machines (mainly servers).

Yet I have failed to do so with dnsmasq.


Got it working. Indeed it was working.

The GUA prefix [1] is advertised by my router "AVM FRITZ!Box 7490" 
[3].
Its Router Advertisement (RA) has M-, O- and A-flag set. Priority is 
middle.

And it is the standard gateway for Internet connections.

dnsmasq 2.76 is running on a Raspberry with Raspbian 8 "Jessie" [4].
It is the only DNSv4/v6 server in the LAN and serves the local domain.
All other requests are forwarded by dnsmasq via IPv4 to the DNS relay 
of the router, this way those requests are resolved by the ISP's DNS 
servers.
It also advertises the Unique Local Addresses (ULA) [2] for the LAN 
via RA and assigns addresses via DHCPv6 only.
The host with dnsmasq (Raspberry) has a GUA via SLAAC by the router's 
RA.


Test machine is Windows 10 with latest updates.
It got its ULA via DHCPv6 from dnsmasq and has a GUA via SLAAC by the 
router's RA.
Additionally a second GUA is present due to Windows' IPv6 privacy 
extensions for outgoing connections.

*But* it doesn't have it's static GUA from dnsmasq!

Am I missing something in my dnsmasq configuration (see below)?
Or do I have to configure the clients in another way?
Any other enhancements for my configuration?


If you run "ipconfig /renew6 " on Windows (here 10), then 
Windows only requests the existing IPv6 addresses to be renewed.
To also get new addresses for the Windows you have to release all IPv6 
addresses before with "ipconfig /release6 ".


So on Windows always do the following for testing in an admin/elevated 
command prompt or Powershell:

ipconfig /release [Name Pattern]
ipconfig /renew [Name Pattern]

If this doesn't help, then deactivate and re-activate the interface via 
netsh to start afresh:

netsh interface set interface  admin=disabled
netsh interface set interface  admin=enabled


By the way:
Does dnsmasq also send a RA for the second/GUA dhcp range? How can I 
avoid this?

I would prefer to handle RA settings per dhcp-range via tags.


Yes, sends RA for each IPv6 DHCP range it manages. Couldn't find an 
option to disable or enable it for a specific dhcp range.
Additionally if a dhcp range is defined multiple times, it also sends 
the RA multiple times.

Will create to feature requests for these issues in separate posts.


Configuration:
1. File /etc/default/dnsmasq (Debian specific)
#DOMAIN_SUFFIX=`dnsdomainname`

Re: [Dnsmasq-discuss] Feature request

[Archimede Pitagorico]

Hi Albert.

thanks for your reply.

My example with just 2 domains was merely for illustration. I do indeed need 
wildcards. I know that if the set of possibilities is finite and known in 
advance I could just enumerate all the possibilities.
 
Regards

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

Re: [Dnsmasq-discuss] Feature request

[Archimede Pitagorico]

Hi Albert.

thanks for your reply.

My example with just 2 domains was merely for illustration. I do indeed need wildcards. I know that if the set of possibilities is finite and known in advance I could just enumerate all the possibilities.

 

Regards

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

Re: [Dnsmasq-discuss] Feature request

[Albert ARIBAUD]

Hi Archi,

Le Wed, 7 Sep 2016 10:03:04 +0200
"Archimede Pitagorico"  a écrit:

> I use a lot the --server and --ipset options. In brief, I want
> certain domains to be dispatched to a special DNS and their IP
> address to be stored in an ipset, so that using iptables and policy
> routing I can dispatch all traffic to these web sites via a special
> interface. it all works well, except that I miss some flexibility in
> defining domain names. for instance I would like
> ipset=/somewebsite.*/specialiface to store the IP addresses for
> somewebsite.com and somewebsite.org in the ipset specialiface. I
> tried to use wildcards, as in the example above, but that t does not
> work. Is there a way to do it? Otherwise, is it possible to add more
> flexibility in specification of domain names (either simple wild
> cards support, or regex support)? thanks a lot Archi

I don't think there is support for wildcard in the domain name for
--ipset, --address or --server directives; at least the manpage does not
indicate there are any.

However, your query is contradictory in that on the one hand youseem to
want to write a generic directive covering any possible TLD, andon the
other hand, you describe a scenario where you only want to catch.org
and .com TLDs.

The latter, I think, is covered with the syntax

--ipset=/somewebsite.com/somewebsite.org/specialiface

More than two domains can be specified, BTW -- I just tried with three
domains using TLD .net, .org and .com, and it works (but then, it would
also work with three --ipset directives each targettting one TLD).

Of course, if you want to catch any FQDN like "*somewebsite.*", that
won't work.

Amicalement,
-- 
Albert.

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

[Dnsmasq-discuss] Feature request

[Archimede Pitagorico]

I use a lot the --server and --ipset options. In brief, I want certain domains to be dispatched to a special DNS and their IP address to be stored in an ipset, so that using iptables and policy routing I can dispatch all traffic to these web sites via a special interface.

 

it all works well, except that I miss some flexibility in defining domain names. for instance I would like

ipset=/somewebsite.*/specialiface

to store the IP addresses for somewebsite.com and somewebsite.org in the ipset specialiface.

 

I tried to use wildcards, as in the example above, but that t does not work. Is there a way to do it? Otherwise, is it possible to add more flexibility in specification of domain names (either simple wild cards support, or regex support)?

 

thanks a lot

Archi

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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Andre Heider]

On Tue, Jan 12, 2016 at 11:16 AM, Andre Heider  wrote:
> On Mon, Jan 11, 2016 at 10:27 PM, Simon Kelley  
> wrote:
>> dig @5.9.49.12 dnskey . | dnssec-dsfromkey -2 -f - .
> I knew it was just a hash, but I was too lazy to look up how to get it

random note: `drill -s` does that too:
 "-s When encountering a DNSKEY print the equivalent DS also."

drill -t -s free dnskey
...
;; ANSWER SECTION:
free.   86400   IN  DNSKEY  256 3 8
AwEAAbhd9S94l+8MmCBGgh5UvJ0MBmHFmQMln2kZ3+8ygMBJ/LCsGQuwJNeHKs1yTCeiaIdz/XpDc5dqXP/bWzjE2PpX6Jeds7Ub3j8xJ+VfKINwdHPYoyjsG2lCnVhtUKtRDfPOpFhEvOq8wzwJBXHFxK7Z5jPcSmAaUQlBIPTDI+As6C2dccB4I0mN+4XB7V1VfD3QwdgvCXdAW6yh3V9XZPDEkZeI3yu2CTzu2wT00wKZB7iPUhmqB/UCu0iOuEccYQpZ5Lp1FIf6wYQ4cfHYBhEv5S5cILXMnMtJ9L4PTHRcbQ3px32BtniEX1g4lQj/SNgSQNyG4F7NtFKfxqCXaAU=
;{id = 43806 (zsk), size = 2048b}

free.   86400   IN  DNSKEY  257 3 8
AwEAAcwvNG8OQAlDpQVo7yuspxG2QeKjtPJQynADPElT6t8HwnqgY8rHCzJ8asd3+OSn5WSsgRlIqpwXGZoOJD3ULQ5IabyHpreDqDU3hEAMwK/nUVb25wV1klKC6OdOU2B/XGtqJVFcPNnXvNVtL7xu7ss6D43mfXZYwgrqKMb5Rb/vOLo6m43IbIUIpni3QePhyX4vi4tgx7rUXbpIdrRQsBaqnylZeO5JpLkxW+VkL1XtV4/sc8DJh/QlXpsW8+G3WYZ3tBqI3ojLlK11/6ORnu0vhWqqUPorOsxIqGq6xso0fiwfOFUbWDICcUX2R42hHeIqlSw4F831cBlk6IE1Uot8e8fCovYSDNO+e06wBqEmsygv0iYL/qBs1ABbkf+QshggTN6M+XKUCweH1965PWISIEzfEd5lTIR0fOKcIq3t1aozOOHEakPiCYa3UWN3lkebmyHAjEUJa7/aAlEXR/uCzdyiShm5FYjmid5hEX1MtP/VOR9BcY5aYkAED6Xdi/YZWtJw+W27ufWH0jMWMq89ZBwWTWkB24E9O40ecImSG6x8hY7BYNx4Vyroh2S3LNaa/M6zpE543t3gr7jFGLbxGohuWhpIQW9LTOFlWUTxRc1CqQRwJi/ZGyFH5OU0KRpxQwKcCnzvPTosxy6EkdoyUlgPcwIO7XUYTa7yidCH
;{id = 43336 (ksk), size = 4096b}
...
; equivalent DS records for key 43806:
; sha1: free.   86400   IN  DS  43806 8 1
9ba8d3af79d783e7168d04b066b8348bcbbee7e9
; sha256: free. 86400   IN  DS  43806 8 2
72a7e6a65775d2c96b460af2429605bc402ecf0b4eaff99bdcb6ff570b4b0586
;
; equivalent DS records for key 43336:
; sha1: free.   86400   IN  DS  43336 8 1
8f568552cd5744047a241763d33ae0379de1ed72
; sha256: free. 86400   IN  DS  43336 8 2
9518ec9290f40e43e8cce6044ff9216bc5099b12620774d394666856e9106377

Regards,
Andre

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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Simon Kelley]

I've got the code I described into dnsmasq.

server=/domain/

now disables DNSSEC for queries sent to that server, unless there's
a corresponding

trust-anchor=domain,...

That all seems to work well, I can delegate to opennic at the TLD-level,
rather than the root level.

I realised that there's a fundamental problem that all DNSSEC queries to
validate a query get send to the same server as the original query. That
would break, eg a domain under .free which held a CNAME to another TLD.
Fixing that needs some long-overdue code re-writing, which is now in
progress.


Cheers,

Simon.


On 12/01/16 10:16, Andre Heider wrote:
> On Mon, Jan 11, 2016 at 10:27 PM, Simon Kelley  
> wrote:
>> dig @5.9.49.12 dnskey . | dnssec-dsfromkey -2 -f - .
>>
>> The -2 flag tells dsfromkey to make the SHA256 hash
>>
>> . IN DS 7372 8 2
>> 14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678D620324CE7B55285
>>
>>
>> A quick re-format into dnsmasq config format gives us
>>
>> trust-anchor=.,7372,8,2,14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678
>> D620324CE7B55285
> 
> I knew it was just a hash, but I was too lazy to look up how to get it
> into a compatible format :)
> dnssec-dsfromkey is the solution, thanks for that info.
> 
> Thanks,
> Andre
> 


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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Andre Heider]

On Mon, Jan 11, 2016 at 10:27 PM, Simon Kelley  wrote:
> dig @5.9.49.12 dnskey . | dnssec-dsfromkey -2 -f - .
>
> The -2 flag tells dsfromkey to make the SHA256 hash
>
> . IN DS 7372 8 2
> 14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678D620324CE7B55285
>
>
> A quick re-format into dnsmasq config format gives us
>
> trust-anchor=.,7372,8,2,14A2B8CAF58BFAAE0BD7C257488A341FCC542F9F88F0B678
> D620324CE7B55285

I knew it was just a hash, but I was too lazy to look up how to get it
into a compatible format :)
dnssec-dsfromkey is the solution, thanks for that info.

Thanks,
Andre

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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 10/01/16 14:46, Andre Heider wrote:
> Hi,
> 
> On Sat, Jan 9, 2016 at 7:25 PM, Simon Kelley
>  wrote:
>> No that one slipped though the net. Thinking about that some
>> more, there are likely fundamental problems with doing ant DNSSEC
>> on servers handling subdomains, since the chain-of-trust isn't
>> going to wor k.
>> 
>> EG. you run dnsmasq with
>> 
>> server=/example.com/
>> 
>> This is likely because that server knows about stuff under
>> example.com which is not known about by the "global" DNS server
>> which dnsmasq is forwarding to. Even if the example.com server is
>> signing DNSSEC, it's highly unlikely that dnsmasq will be able to
>> validate its output, since the chain-of-trust won't reach to it.
>> If you're going to the trouble of getting the DS record for
>> example.com signed by the .com administrators, then you may as
>> well have them serve the delegation as well, and make example.com
>> globally visible.
>> 
>> It therefore makes sense to turn off DNSSEC validation for any
>> domains handled by such servers.
>> 
>> The next stage would be to turn it back on if there's a
>> trust-anchor supplied for the domain. That would allow DNS
>> servers for private domains to work with DNSSEC. Doing that is
>> predicated on making the dnsmasq validation code work with
>> non-root trust anchors. I don't think it does at the moment.
>> 
>> So, that's a plan.
>> 
>> 1) disable validation when forwarding to servers for a domain.
>> 
>> and longer term
>> 
>> 2) make non-root trust anchors work and turn it back on is one
>> is provided.
>> 
>> 
>> Comments?
> 
> It would be solving the .onion problem without the security issue
> of disabling dnsseccheckunsigned.
> 
> But there are already non IANA TLDs using DNSSEC out there, like 
> opennic, see [0].
> 
> Right now I can make use of that, e.g. with their .free TLD: * dig
> +tcp +multi +noall +answer DS free @5.9.49.12 *
> trust-anchor=free, *
> server=/free/5.9.49.12
> 
> and make dnsmasq resolve e.g. reg.for.free with dnssec enabled
> (next to all the IANA TLDs). Your plan would break that until 2)
> is implemented.
> 
> Having that that, this example isn't a clear solution either. It 
> fishes out the .free DS record since it's the only way I could find
> to tell dnsmasq about it (using the trust-anchor "domain" field).
> 
> Maybe "named" trust-anchors are the most flexible solution.
> Something like this: * trust-anchor=iana,... *
> trust-anchor=opennic,... * server=x.x.x.x/iana *
> server=/free/x.x.x.x/opennic * server=/indy/x.x.x.x/opennic *
> server=/onion/x.x.x.x/none
> 
> But whatever 2) will be, having 1) so we don't have to disable 
> dnsseccheckunsigned would be a first step.
> 
> Thanks, Andre
> 
> [0] http://wiki.opennicproject.org/dnssecroot
> 


Your opennic example is interesting. The opennic nameservers provide
an alternative root, and delegate all the IANA TLDs (or at least all
the ones which existed before ICANN started whoring them out to
whoever would pay.) The solution, therefore is to send all the
queries to opennic, they'll get the answers from the conventional TLDs
and return them just fine.

The clever bit is that opennic has signed the root zone with their own
key - they have to to be able to add .free and friends, since the
ICANN private key isn't available to them. The Opennic website doesn't
provide this key in easy to use form, as far as I can see, but we can
easily  get it.

dig @5.9.49.12 dnskey .

will us the key (actually three keys, two zone-signing keys and a key
signing key - that's the one we're interested in - it has flags field
== 257.

; <<>> DiG 9.9.5-3ubuntu0.6-Ubuntu <<>> @5.9.49.12 dnskey .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  DNSKEY

;; ANSWER SECTION:
.   86400   IN  DNSKEY  256 3 8
AwEAAbBeOAxco/hOn+ENrbiIW8s4YMZXRGmNAx58Oy8PQBWSf9G5JDyQ
owOLQLQlrVX7S2qmtF8OOUgX3inM+IUm6g+Nbjh1fYrdFYHMKD+T13fw
aYT6gUJJKtLrfjznDfZ3+ViRoywd4riLA/xMR1+B+2lZqdCW1mN9z+7J
gsBJs5tuKqUaLLj89fF+80DPicbQyKm/VFsXIFve2foM0YiK9+x0QYS7
yYkpgMRd2OyCfpCMf8dipYnVWwxGIBtT8FE10///M+OAedCLfWyScqWV
xHnf6G3fH0+Lxh5Kp+xa7szf80wO7xAoMcRWctCq8DoKQZJ41MJhlIVe Xq7ng21lKws=
.   86400   IN  DNSKEY  257 3 8
AwEAAe2SqWzJDU5l8IiTdWIEi4gG0fNGXzX3ISbU1a6JAsUPFl7rCWDe
9f5J67xGSAkbwS2doYzvPL72AmI077wFapBtNFCgUT4KruO+f0j0pO74
QFM6dFlIRbVJBUuTReRcikiqP8e1wWvLXd4PknSkAi6k+TQpl48YOEYC
rf1jqWqPTJVZuJlMMdYyHSXndRhN5QF7+kP7FmulpDhLCNLFVHWCXXxH
td6AgF6OyuTMr1iQd44tBz2e8sNK9qJ9fsCvF2iRRUlePh1q2WKzC6DG
J5PJgeHKefSE515+hdyBWhGId2u7yOTNMxcbAOq17KOmf/fct1nvlqOM
cLZ55oKPy0t9nU/niQaYhU0P+F8rmdyCkK29ri4hbBHgOO7INw2ElYxA

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Andre Heider]

Hi,

On Sat, Jan 9, 2016 at 7:25 PM, Simon Kelley  wrote:
> No that one slipped though the net. Thinking about that some more,
> there are likely fundamental problems with doing ant DNSSEC  on
> servers handling subdomains, since the chain-of-trust isn't going to wor
> k.
>
> EG. you run dnsmasq with
>
> server=/example.com/
>
> This is likely because that server knows about stuff under example.com
> which is not known about by the "global" DNS server which dnsmasq is
> forwarding to. Even if the example.com server is signing DNSSEC, it's
> highly unlikely that dnsmasq will be able to validate its output,
> since the chain-of-trust won't reach to it. If you're going to the
> trouble of getting the DS record for example.com signed by the .com
> administrators, then you may as well have them serve the delegation as
> well, and make example.com globally visible.
>
> It therefore makes sense to turn off DNSSEC validation for any domains
> handled by such servers.
>
> The next stage would be to turn it back on if there's a trust-anchor
> supplied for the domain. That would allow DNS servers for private
> domains to work with DNSSEC. Doing that is predicated on making the
> dnsmasq validation code work with non-root trust anchors. I don't
> think it does at the moment.
>
> So, that's a plan.
>
> 1) disable validation when forwarding to servers for a domain.
>
> and longer term
>
> 2) make non-root trust anchors work and turn it back on is one is
> provided.
>
>
> Comments?

It would be solving the .onion problem without the security issue of
disabling dnsseccheckunsigned.

But there are already non IANA TLDs using DNSSEC out there, like
opennic, see [0].

Right now I can make use of that, e.g. with their .free TLD:
* dig +tcp +multi +noall +answer DS free @5.9.49.12
* trust-anchor=free,
* server=/free/5.9.49.12

and make dnsmasq resolve e.g. reg.for.free with dnssec enabled (next
to all the IANA TLDs). Your plan would break that until 2) is
implemented.

Having that that, this example isn't a clear solution either. It
fishes out the .free DS record since it's the only way I could find to
tell dnsmasq about it (using the trust-anchor "domain" field).

Maybe "named" trust-anchors are the most flexible solution. Something like this:
* trust-anchor=iana,...
* trust-anchor=opennic,...
* server=x.x.x.x/iana
* server=/free/x.x.x.x/opennic
* server=/indy/x.x.x.x/opennic
* server=/onion/x.x.x.x/none

But whatever 2) will be, having 1) so we don't have to disable
dnsseccheckunsigned would be a first step.

Thanks,
Andre

[0] http://wiki.opennicproject.org/dnssecroot

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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/01/16 14:18, Andre Heider wrote:
> Hi,
> 
> On Sat, Sep 6, 2014 at 6:55 PM, Simon Kelley
>  wrote:
>> On 29/08/14 08:59, Rene Bartsch wrote:
>>> Hi,
>>> 
>>> I'm running Dnsmasq with DNSSEC-validation and
>>> "--dnssec-check-unsigned" enabled.
>>> "server=/onion/127.0.0.1#9053" forwards .onion-queries to the 
>>> TOR-resolver. Unfortunately the TOR-resolver provides A-RRs
>>> only. So resolving .onion-domains fails when
>>> "--dnssec-check-unsigned" is enabled.
>>> 
>>> Please extend "--dnssec-check-unsigned" with an option for the
>>> server address and port.
>>> 
>>> "dnssec-check-unsigned" would enable for all upstream servers.
>>> 
>>> "dnssec-check-unsigned=127.0.0.1#9053" would enable only for 
>>> 127.0.0.1#9053.
>>> 
>> 
>> This ties in with something I was considering, which is to be
>> able to disable DNSSEC checking for particular upstream servers.
>> I guess it's better to associate it with the the server than
>> enable-dnssec or dnssec-check-unsigned, so we could have
>> 
>> server-no-dnssec=/onion/127.0.0.1#9053
>> 
>> or
>> 
>> server-no-dnssec-unsigned=/onion/127.0.0.1#9053
> 
> I just ran into this, was anything implemented to allow disabling 
> dnssec for selected servers?
> 
> Regards, Andre
> 
No that one slipped though the net. Thinking about that some more,
there are likely fundamental problems with doing ant DNSSEC  on
servers handling subdomains, since the chain-of-trust isn't going to wor
k.

EG. you run dnsmasq with

server=/example.com/

This is likely because that server knows about stuff under example.com
which is not known about by the "global" DNS server which dnsmasq is
forwarding to. Even if the example.com server is signing DNSSEC, it's
highly unlikely that dnsmasq will be able to validate its output,
since the chain-of-trust won't reach to it. If you're going to the
trouble of getting the DS record for example.com signed by the .com
administrators, then you may as well have them serve the delegation as
well, and make example.com globally visible.

It therefore makes sense to turn off DNSSEC validation for any domains
handled by such servers.

The next stage would be to turn it back on if there's a trust-anchor
supplied for the domain. That would allow DNS servers for private
domains to work with DNSSEC. Doing that is predicated on making the
dnsmasq validation code work with non-root trust anchors. I don't
think it does at the moment.

So, that's a plan.

1) disable validation when forwarding to servers for a domain.

and longer term

2) make non-root trust anchors work and turn it back on is one is
provided.


Comments?

Simon.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWkVCAAAoJEBXN2mrhkTWiAbIP/ibFSvVuBhA3jsB84CZpDwZV
hKNUdxaLahxK4Hh8ccDYqYyeghIR8OKZmVnI2QUBm9nFK2r2FSP8jzQosDm+eitn
Ef+j8anZTudTFOwaeZwS62i1DDxXjj+HjupFJ2LVs8Y2gcbERaqxzEQpEubwLwWj
bbnqLMq2Z0irvtlxcxDP4NZGb5DUbEGYokjv/n6UaNIce4jG1ep3mgJY1TwPFhTk
Y9/0hkWrXyWuya4BqqLSpxyKwRRs5E9AeiSyGFiYBcPfX8gXhA8RE+r22ds3jYpc
KGFrwuZqVQznc6YbY+CNovy4mYwAnphFNZl2OZGa/4y/rwsR+87fXJbSzCmTjFNx
IgQevAX8YG5o2ovheOlDv/KO+X9E/Z+FbiDks3MRsTZpzFsDXFQm/6BSEhxquX8A
RFfXL7pZLaAaMOa2lvjdevgRq6z3iNyAAKdWlBbk/P7rw4VFGFaniUOpHKk5uavw
us945QCAdjXRRfEZ4qD9jviMShE5Jf+AqCieskMPyvJ5IYOvx2Barlz0NpndOzG1
Z/ITrEZJ6bgUTMIRyHVXfgV1lqyQ7btpAFT/FgzninMWp6QlQH2c8B29Ay6bhIbo
iJqoeoPYZurVK6xN6oMnSUW/Y+N9yX51CKuHbF1kwSXXyVhMEu1dZa8ABcg9EEsy
Q7niSaD3k0WVJ/WG0Vkp
=lygh
-END PGP SIGNATURE-

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

Re: [Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Andre Heider]

Hi,

On Sat, Sep 6, 2014 at 6:55 PM, Simon Kelley  wrote:
> On 29/08/14 08:59, Rene Bartsch wrote:
>> Hi,
>>
>> I'm running Dnsmasq with DNSSEC-validation and "--dnssec-check-unsigned"
>> enabled. "server=/onion/127.0.0.1#9053" forwards .onion-queries to the
>> TOR-resolver. Unfortunately the TOR-resolver provides A-RRs only. So
>> resolving .onion-domains fails when "--dnssec-check-unsigned" is enabled.
>>
>> Please extend "--dnssec-check-unsigned" with an option for the server
>> address and port.
>>
>> "dnssec-check-unsigned" would enable for all upstream servers.
>>
>> "dnssec-check-unsigned=127.0.0.1#9053" would enable only for
>> 127.0.0.1#9053.
>>
>
> This ties in with something I was considering, which is to be able to
> disable DNSSEC checking for particular upstream servers. I guess it's
> better to associate it with the the server than enable-dnssec or
> dnssec-check-unsigned, so we could have
>
> server-no-dnssec=/onion/127.0.0.1#9053
>
> or
>
> server-no-dnssec-unsigned=/onion/127.0.0.1#9053

I just ran into this, was anything implemented to allow disabling
dnssec for selected servers?

Regards,
Andre

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

Re: [Dnsmasq-discuss] Feature request: block certain domain's A/AAAA/MX record

[喵喵]

Thanks for your reply.
As you may already know, our government has blocked many websites,
including Google, YouTube and Facebook (see:
https://en.wikipedia.org/wiki/Internet_censorship_in_China). Using
tunnelbroker to gain IPv6 connectivity is a easy way to bypass such
restrictions. The problem I mention above is such small side effect. If
dnsmasq can introduce this feature that will certainly helps me.

2014-11-25 17:40 GMT+08:00 samlt samuel.leth...@intelunix.fr:

  On Tue, 2014-11-25 at 10:13 +0800, 喵喵 wrote:

 Hello there,


  First of all, sorry for my improving English.

  I'd like to request a feature that user can block a certain domain's
 A//MX record.

  I am using tomato firmware with dnsmasq built in. Since I live in China
 and I use HE.net's free IPv6 tunnelbroker to gain IPv6 internet
 connectivity. But there's a problem, when I visit a site in China which has
 IPv4/v6 dual stack, browsers and other apps will try to connect via IPv6
 first, that will be much slower than using IPv4. So if you guys can
 introduce a feature that block a certain domain's  record, that will be
 very helpful for me.


 Hello,

 Quick question then: what would be the point of using an IPv6 tunnelbroker
 then?


  Thanks for your time, have a good day.


  Erwin

  ___
 Dnsmasq-discuss mailing 
 listdnsmasq-disc...@lists.thekelleys.org.ukhttp://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] Feature request: block certain domain's A/AAAA/MX record

[samlt]

On Tue, 2014-11-25 at 10:13 +0800, 喵喵 wrote:
 Hello there,
 
 
 
 First of all, sorry for my improving English.
 
 
 I'd like to request a feature that user can block a certain domain's
 A//MX record.
 
 
 I am using tomato firmware with dnsmasq built in. Since I live in
 China and I use HE.net's free IPv6 tunnelbroker to gain IPv6 internet
 connectivity. But there's a problem, when I visit a site in China
 which has IPv4/v6 dual stack, browsers and other apps will try to
 connect via IPv6 first, that will be much slower than using IPv4. So
 if you guys can introduce a feature that block a certain domain's 
 record, that will be very helpful for me.
 


Hello,

Quick question then: what would be the point of using an IPv6
tunnelbroker then?


 
 Thanks for your time, have a good day.
 
 
 
 Erwin
 
 
 ___
 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] Feature request: block certain domain's A/AAAA/MX record

[klondike]

El 25/11/14 03:13, 喵喵 escribió:
 Hello there,

 First of all, sorry for my improving English.
 I'd like to request a feature that user can block a certain domain's
 A//MX record.
 I am using tomato firmware with dnsmasq built in. Since I live in
 China and I use HE.net's free IPv6 tunnelbroker to gain IPv6 internet
 connectivity. But there's a problem, when I visit a site in China
 which has IPv4/v6 dual stack, browsers and other apps will try to
 connect via IPv6 first, that will be much slower than using IPv4. So
 if you guys can introduce a feature that block a certain domain's 
 record, that will be very helpful for me.
 Thanks for your time, have a good day.
Just set the preferences on your client computer. On linux using glibc
this is done in the gai.conf file



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Feature request: block certain domain's A/AAAA/MX record

[喵喵]

Thanks for your advice. Clients including Windows PC, Mac, Android Phone,
iPhone etc. Not every device are mine so it's impossible to config on every
device.
On Nov 25, 2014 6:42 PM, klondike klond...@klondike.es wrote:

 El 25/11/14 03:13, 喵喵 escribió:
  Hello there,
 
  First of all, sorry for my improving English.
  I'd like to request a feature that user can block a certain domain's
  A//MX record.
  I am using tomato firmware with dnsmasq built in. Since I live in
  China and I use HE.net's free IPv6 tunnelbroker to gain IPv6 internet
  connectivity. But there's a problem, when I visit a site in China
  which has IPv4/v6 dual stack, browsers and other apps will try to
  connect via IPv6 first, that will be much slower than using IPv4. So
  if you guys can introduce a feature that block a certain domain's 
  record, that will be very helpful for me.
  Thanks for your time, have a good day.
 Just set the preferences on your client computer. On linux using glibc
 this is done in the gai.conf file


 ___
 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] Feature request: block certain domain's A/AAAA/MX record

[喵喵]

Hello there,

First of all, sorry for my improving English.
I'd like to request a feature that user can block a certain domain's
A//MX record.
I am using tomato firmware with dnsmasq built in. Since I live in China and
I use HE.net's free IPv6 tunnelbroker to gain IPv6 internet connectivity.
But there's a problem, when I visit a site in China which has IPv4/v6 dual
stack, browsers and other apps will try to connect via IPv6 first, that
will be much slower than using IPv4. So if you guys can introduce a feature
that block a certain domain's  record, that will be very helpful for me.
Thanks for your time, have a good day.

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

[Dnsmasq-discuss] Feature request: allow to enable/disable --dnssec-check-unsigned per upstream server

[Rene Bartsch]

Hi,

I'm running Dnsmasq with DNSSEC-validation and --dnssec-check-unsigned 
enabled. server=/onion/127.0.0.1#9053 forwards .onion-queries to the 
TOR-resolver. Unfortunately the TOR-resolver provides A-RRs only. So 
resolving .onion-domains fails when --dnssec-check-unsigned is 
enabled.


Please extend --dnssec-check-unsigned with an option for the server 
address and port.


dnssec-check-unsigned would enable for all upstream servers.

dnssec-check-unsigned=127.0.0.1#9053 would enable only for 
127.0.0.1#9053.


--
Best regards,

Renne


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

[Dnsmasq-discuss] Feature request: `address=/#/#`

[Sam Pinkus]

Hi,

Currently the address option only supports mapping a set of domains to
an IP. I think it would useful to provide a level of inderection here:
# for this host - or the host ip the dns client is connecting to.
Maybe additionally, even allow a domain here, although you'd have to
prevent a infinite loop.

Thanks,

Sam.

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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Damian Kaczkowski]

On 19 June 2013 11:31, Simon Kelley si...@thekelleys.org.uk wrote:

 That would increase the delay for real failures, but since this is the
 server and not the client, that's probably not a big problem, it just means
 that it takes longer for the failure message to be logged.

 Change committed for next release.


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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Simon Kelley]

On 18/06/13 23:03, Damian Kaczkowski wrote:

On 18 June 2013 22:46, Simon Kelleysi...@thekelleys.org.uk  wrote:


No, that's not the right place to change. The retransmissions/timeouts are
actually exponential, so the code waits 1 seconds for a reply, retransmits,
waits 2 seconds, retransmits, waits 4 seconds, retransmits and finally
waits 8 seconds and then gives up. You can extend that sequence by changing
the constant in

  else if (++transfer-backoff  5  len != 0)

changing 5 to 6 will give you another 16 seconds, to 7 will give you 32
seconds, etc etc.




   else if (++transfer-backoff  7  len != 0)

Works like a charm for me (6 doesn't). Thank you again.


ps. Maybe you consider changing 5 to 7 is the code instead of implementing
new option?




That would increase the delay for real failures, but since this is the 
server and not the client, that's probably not a big problem, it just 
means that it takes longer for the failure message to be logged.



Change committed for next release.


Cheers,

Simon.

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

[Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Damian Kaczkowski]

Hello fellow members.

I have a problem with dnsmasq and its tftp server. I have an embedded
device which needs very high timeout settings for bootp tftp transfer to
work. Currently it is not possible to successfully transfer a file to this
device using dnsmasq. Transfer timeouts before completion. I have to use
some third party tftp server for transfer to work. I need to set
--retry-timeout to something like 60 so the server won't consider
connection as broken too early. After then all works ok.

It would be nice if dnsmasq team could implement new options for setting
timeout and max retransmit count for tftp. What do you say? Will this idea
pass to new versions or it's unlikely to see this implemented in future
versions?


btw.
Would someone be so kind and point me out what part of tftp.c should I edit
to longer the retransmit timeout, please?

Will changing:
  transfer-timeout = now + 2;
to:
  transfer-timeout = now + 60;
work?

I am no coder so I'm not sure what I am doing... ; )

Many thanks in advance for your help.


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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Damian Kaczkowski]

On 18 June 2013 22:00, Damian Kaczkowski wrote:

 Will changing:
   transfer-timeout = now + 2;
 to:
   transfer-timeout = now + 60;
 work?


Seems that the above doesn't work,

but changing this:
  /* timeout, retransmit */
  transfer-timeout += 1 + (1transfer-backoff);
to this:
  /* timeout, retransmit */
  transfer-timeout += 60 + (1transfer-backoff);
works : )


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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Simon Kelley]

On 18/06/13 21:00, Damian Kaczkowski wrote:

Hello fellow members.

I have a problem with dnsmasq and its tftp server. I have an embedded
device which needs very high timeout settings for bootp tftp transfer to
work. Currently it is not possible to successfully transfer a file to
this device using dnsmasq. Transfer timeouts before completion. I have
to use some third party tftp server for transfer to work. I need to set
--retry-timeout to something like 60 so the server won't consider
connection as broken too early. After then all works ok.

It would be nice if dnsmasq team could implement new options for setting
timeout and max retransmit count for tftp. What do you say? Will this
idea pass to new versions or it's unlikely to see this implemented in
future versions?


It's difficult to say: a glance at the man-page shows that dnsmasq 
doesn't have a shortage of options, overall, but we try and restrict 
them to options that will actually be used by more than one person. I 
don't have much of a feeling about if you have a very pathalogical 
client, or this is something that might be more generally useful.



btw.
Would someone be so kind and point me out what part of tftp.c should I
edit to longer the retransmit timeout, please?

Will changing:
   transfer-timeout = now + 2;
to:
   transfer-timeout = now + 60;
work?

I am no coder so I'm not sure what I am doing... ; )



No, that's not the right place to change. The retransmissions/timeouts 
are actually exponential, so the code waits 1 seconds for a reply, 
retransmits, waits 2 seconds, retransmits, waits 4 seconds, retransmits 
and finally waits 8 seconds and then gives up. You can extend that 
sequence by changing the constant in


 else if (++transfer-backoff  5  len != 0)

changing 5 to 6 will give you another 16 seconds, to 7 will give you 32 
seconds, etc etc.



Cheers,

Simon.



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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Damian Kaczkowski]

On 18 June 2013 22:47, Simon Kelley si...@thekelleys.org.uk wrote:

 See my previous reply which crossed with this for a better answer (though
 you suggestion will increase the timeout, but not in a very controlled way)


Thank you Simon. Will look into this.

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

Re: [Dnsmasq-discuss] Feature request - customizable timeout and max retransmit count for tftp transfer

[Damian Kaczkowski]

On 18 June 2013 22:46, Simon Kelley si...@thekelleys.org.uk wrote:

 No, that's not the right place to change. The retransmissions/timeouts are
 actually exponential, so the code waits 1 seconds for a reply, retransmits,
 waits 2 seconds, retransmits, waits 4 seconds, retransmits and finally
 waits 8 seconds and then gives up. You can extend that sequence by changing
 the constant in

  else if (++transfer-backoff  5  len != 0)

 changing 5 to 6 will give you another 16 seconds, to 7 will give you 32
 seconds, etc etc.



  else if (++transfer-backoff  7  len != 0)

Works like a charm for me (6 doesn't). Thank you again.


ps. Maybe you consider changing 5 to 7 is the code instead of implementing
new option?


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

Re: [Dnsmasq-discuss] Feature Request: tftp-script

[Simon Kelley]

On 25/03/12 17:02, Shantanu Gadgil wrote:
 Hi,
 
 What I was suggesting in my previous post was ...
 
 lets consider the following as a possible scenario ...
 --- snip ---
 tftp-script=/path/to/mytftpscript
 dhcp-script=/path/to/mydhcpscript
 dhcp6-script=/path/to/mydhcp6script
 dns-script=/path/to/dnsscript
 dns6-script=/path/to/dns6script
 --- snip ---
 
 [root@server ~]# ls -l /path/to/mytftpscript
 lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mytftpscript - 
 mycommonscript
 [root@server ~]# ls -l /path/to/mydhcpscript
 lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mydhcpscript - 
 mycommonscript
 [root@server ~]# ls -l /path/to/mydhcp6script
 lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mydhcp6script - 
 mycommonscript
 
 ... and so on ...
 
 The mycommonscript should have the necessary logic to decide which script 
 is actually being called based of the value of $0 (argv[0] in C speak) (the 
 actual filename)
 
 Keeping it this way would allow you to separate the $1 value for the 
 various possibilities, and not have to worry about script breakage during 
 adding more parameters.
 It becomes the script-writer's headache to cater/handle parameters as they 
 appear (!)
 
 The very attractive part here is that the user has to maintain only a single 
 script.
 

That's attractive, except that it increases the already vast number of
configuration options in dnsmasq, and it doesn't work correspondingly on
the Lua side, where there can be only one Lua script file, but functions
for each  (dhcp, tftp, dhcp6, etc etc)

I think the way to go is to call dhcp-script with $1 as tftp


Cheers,

Simon.

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

Re: [Dnsmasq-discuss] Feature Request: tftp-script

[Shantanu Gadgil]

Hi,

What I was suggesting in my previous post was ...

lets consider the following as a possible scenario ...
--- snip ---
tftp-script=/path/to/mytftpscript
dhcp-script=/path/to/mydhcpscript
dhcp6-script=/path/to/mydhcp6script
dns-script=/path/to/dnsscript
dns6-script=/path/to/dns6script
--- snip ---

[root@server ~]# ls -l /path/to/mytftpscript
lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mytftpscript - 
mycommonscript
[root@server ~]# ls -l /path/to/mydhcpscript
lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mydhcpscript - 
mycommonscript
[root@server ~]# ls -l /path/to/mydhcp6script
lrwxrwxrwx.   1 root root   3 Mar 21 00:20 /path/to/mydhcp6script - 
mycommonscript

... and so on ...

The mycommonscript should have the necessary logic to decide which script 
is actually being called based of the value of $0 (argv[0] in C speak) (the 
actual filename)

Keeping it this way would allow you to separate the $1 value for the various 
possibilities, and not have to worry about script breakage during adding more 
parameters.
It becomes the script-writer's headache to cater/handle parameters as they 
appear (!)

The very attractive part here is that the user has to maintain only a single 
script.

Regards,
Shantanu


--- On Wed, 3/21/12, Simon Kelley si...@thekelleys.org.uk wrote:

 From: Simon Kelley si...@thekelleys.org.uk
 Subject: Re: [Dnsmasq-discuss] Feature Request: tftp-script
 To: dnsmasq-discuss@lists.thekelleys.org.uk
 Date: Wednesday, March 21, 2012, 5:35 PM
 On 21/03/12 11:49, Ed W wrote:
  On 21/03/2012 09:50, Simon Kelley wrote:
  http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test7.tar.gz
 
 
  Has the tftp action implemented. At the moment
 it's sent to the
  --dhcp-script script always. I'm still tending
 towards that solution,
  but haven't made the final decision. The bulk of
 the changes are done
  anyway.
 
  Just from the point of view of longer term plans.
 Recently I actually
  read the documentation on Nginx perl (I think I put in
 the correct link
  below?).
  http://zzzcpan.github.com/nginx-perl/
 
  The point of looking is simply that at first sight,
 embedding a
  relatively slow scripting language looks troublesome
 and a performance
  issue. However, I was quite surprised at just HOW
 embedded is perl in
  what is perhaps one of the highest performing network
 server software we
  have to study at the moment
 
  Lua would seem like a better bet for dnsmasq (than
 perl) due to the very
  low installation size. Also performance is alleged to
 be extremely high
  (for a scripting language) and the runtime is designed
 with
  embeddability in mind. Nginx also allows embedded lua,
 although I
  haven't studied to see if they achieve similar levels
 of integration
 
  I have an application (captive portal) where it would
 be quite
  interesting to manufacture answers under some
 conditions, tweak
  answers under others, and also cheat on caching
 timeouts in specific
  situations (if the user if offline/dialup for
 example).
 
  Just trying to put ideas into your head...
 
 
 Ed,
 
 It's not quite clear if you've looked at dnsmasq-2.60+ or
 not. Try
 
 
 make COPTS=-DHAVE_LUASCRIPT
 
 Lua got there first.
 
 
 There's an architectural problem with all the scripting (Lua
 and 
 fork/exec) in dnsmasq at the moment; there's no sensible way
 to get 
 information from the script back to dnsmasq. Events in
 dnsmasq get sent 
 asynchronously down a pipe to a distinct the process which
 then runs the 
 script. This achieves 1) privilege separation. 2) Script
 can't block 
 dnsmasq - especially important when dnsmasq is a bit of a
 swiss-army knife.
 
 There is a back-channel for errors, which could be expanded.
 But there's 
 no sensible way at the moment to make dnsmasq wait whilst
 (eg) a script 
 tweaks a DNS answer.
 
 Cheers,
 
 Simon.
 
 
 
 
 
 ___
 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] Feature Request: tftp-script

[Shantanu Gadgil]

Hi,

I think it would be OK to add different --*-script commands. So you can have 
'dhcp6-script', 'tftp-script' ... possibly 'dns-script', etc, etc.

I know that I would like to have a single script to deal with each of these, 
and that IS how I would do it.
The way I would do (and usually is done) is that /each/ of the --*-script 
command would point to a *different* file; each of which is a symlink to the 
same real file!

The real script should look at '$0' and figure out which action is 
triggering self and take appropriate action.

Regards,
Shantanu


--- On Tue, 3/20/12, Simon Kelley si...@thekelleys.org.uk wrote:

 From: Simon Kelley si...@thekelleys.org.uk
 Subject: Re: [Dnsmasq-discuss] Feature Request: tftp-script
 To: richardvo...@gmail.com richardvo...@gmail.com
 Cc: dnsmasq-discuss@lists.thekelleys.org.uk
 Date: Tuesday, March 20, 2012, 5:14 PM
 On 19/03/12 17:51, richardvo...@gmail.com
 wrote:
  Existing scripts could definitely break, imagine one
 that just logs
  certain environment variables plus the parameter. 
 The new action values
  won't have the right environment variable set.
 
 A good point, but such scripts are already going to suffer
 as soon as DHCPv6 is used: that has the same action values,
 but some environment variables change.
 
 Adding --tftp-script will work this time, but it will have
 to be repeated with more --*-script options if we ever add
 more functions. That starts to get silly. Biting the bullet
 now, and documenting that the script has to ignore unknown
 actions, fixes the problem once and for all.
 
 Of course, that should have been the case from the start,
 but it's too late now. Dnsmasq's record on backwards
 compatibility is pretty good, so maybe we're entitled to a
 bit of slack.
 
  
  How about both?  Give the --tftp-script the same
 action parameter, and
  keep actions unique, that way both options can be
 pointed to the same
  script, or separate scripts.
  
 
 If --tftp-script is used, that's the way to go, for sure.
 
 Cheers,
 
 Simon.
 
 ___
 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] Feature Request: tftp-script

[Ed W]

On 21/03/2012 09:50, Simon Kelley wrote:
http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test7.tar.gz 



Has the tftp action implemented. At the moment it's sent to the 
--dhcp-script script always. I'm still tending towards that solution, 
but haven't made the final decision. The bulk of the changes are done 
anyway.


Just from the point of view of longer term plans.  Recently I actually 
read the documentation on Nginx perl (I think I put in the correct link 
below?).

http://zzzcpan.github.com/nginx-perl/

The point of looking is simply that at first sight, embedding a 
relatively slow scripting language looks troublesome and a performance 
issue.  However, I was quite surprised at just HOW embedded is perl in 
what is perhaps one of the highest performing network server software we 
have to study at the moment


Lua would seem like a better bet for dnsmasq (than perl) due to the very 
low installation size.  Also performance is alleged to be extremely high 
(for a scripting language) and the runtime is designed with 
embeddability in mind.  Nginx also allows embedded lua, although I 
haven't studied to see if they achieve similar levels of integration


I have an application (captive portal) where it would be quite 
interesting to manufacture answers under some conditions, tweak 
answers under others, and also cheat on caching timeouts in specific 
situations (if the user if offline/dialup for example).


Just trying to put ideas into your head...

All the best

Ed W



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

Re: [Dnsmasq-discuss] Feature Request: tftp-script

[Simon Kelley]

On 21/03/12 11:49, Ed W wrote:

On 21/03/2012 09:50, Simon Kelley wrote:

http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test7.tar.gz


Has the tftp action implemented. At the moment it's sent to the
--dhcp-script script always. I'm still tending towards that solution,
but haven't made the final decision. The bulk of the changes are done
anyway.


Just from the point of view of longer term plans. Recently I actually
read the documentation on Nginx perl (I think I put in the correct link
below?).
http://zzzcpan.github.com/nginx-perl/

The point of looking is simply that at first sight, embedding a
relatively slow scripting language looks troublesome and a performance
issue. However, I was quite surprised at just HOW embedded is perl in
what is perhaps one of the highest performing network server software we
have to study at the moment

Lua would seem like a better bet for dnsmasq (than perl) due to the very
low installation size. Also performance is alleged to be extremely high
(for a scripting language) and the runtime is designed with
embeddability in mind. Nginx also allows embedded lua, although I
haven't studied to see if they achieve similar levels of integration

I have an application (captive portal) where it would be quite
interesting to manufacture answers under some conditions, tweak
answers under others, and also cheat on caching timeouts in specific
situations (if the user if offline/dialup for example).

Just trying to put ideas into your head...



Ed,

It's not quite clear if you've looked at dnsmasq-2.60+ or not. Try


make COPTS=-DHAVE_LUASCRIPT

Lua got there first.


There's an architectural problem with all the scripting (Lua and 
fork/exec) in dnsmasq at the moment; there's no sensible way to get 
information from the script back to dnsmasq. Events in dnsmasq get sent 
asynchronously down a pipe to a distinct the process which then runs the 
script. This achieves 1) privilege separation. 2) Script can't block 
dnsmasq - especially important when dnsmasq is a bit of a swiss-army knife.


There is a back-channel for errors, which could be expanded. But there's 
no sensible way at the moment to make dnsmasq wait whilst (eg) a script 
tweaks a DNS answer.


Cheers,

Simon.





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

Re: [Dnsmasq-discuss] Feature Request: tftp-script

[Simon Kelley]

On 18/03/12 07:09, Shantanu Gadgil wrote:

Hi,

I was wondering whether it would be possible to have hooks for the TFTP 
operations, just like the DHCP operations.

This is just a rough thought for now ...
When a TFTP request is made from the client (or is successful when the file is 
/actually/ provided), I want to be able to log the IP adress (or maybe send a 
mail) to collect some data as to how many network based installations actually 
started, etc.

If it could be possible to have the filename as one of the parameters in the 
hook, it would be even better, as then I can isolate actual installations that 
started, as opposed to TFTP requests which just loading the PXE menu.

Regards,
Shantanu


That sounds to me like a very sensible suggestion.

There are two obvious ways to do it: either add an extra hook 
(--tftp-script), or add an extra possible action value to the current 
--dhcp-script. I think the later is how I'd do it if starting from 
scratch, but it has the disadvantage of possibly breaking existing 
script code. On the other hand, any sane script should just ignore 
unrecognised actions; the example code supplied with dnsmasq does.


Any script users out there, please check your code, would adding another 
value to {add, old, del, init} break stuff?




Cheers,

Simon.

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

Re: [Dnsmasq-discuss] Feature Request: tftp-script

[Shantanu Gadgil]

As a script writer I can confirm that a well written script should not break if 
a new first parameter in added; in place of 'add', 'del' and 'old'

Any code, script or otherwise, should basically follow the same modular 
philosophy.

Wrt the actual thought, I have been sitting on this idea for quite some time, 
not sure how to nicely (correctly) minimize the TFTP script invocations.

I do think that some intelligence can be added to dnsamsq itself to trigger the 
TFTP script upon actual file delivery to client (before file send, after file 
send, etc, hooks), rather than any-tftp-request.

Not having used the dhcp-script too much myself, I won't be able to immediately 
create a mental picture whether mixing TFTP and DHCP in the same script would 
be any problem at all.

Thanks for the positive response on the idea though,
Regards,
Shantanu

--- On Mon, 3/19/12, Simon Kelley si...@thekelleys.org.uk wrote:

 From: Simon Kelley si...@thekelleys.org.uk
 Subject: Re: [Dnsmasq-discuss] Feature Request: tftp-script
 To: dnsmasq-discuss@lists.thekelleys.org.uk
 Date: Monday, March 19, 2012, 4:48 PM
 On 18/03/12 07:09, Shantanu Gadgil
 wrote:
  Hi,
  
  I was wondering whether it would be possible to have
 hooks for the TFTP operations, just like the DHCP
 operations.
  
  This is just a rough thought for now ...
  When a TFTP request is made from the client (or is
 successful when the file is /actually/ provided), I want to
 be able to log the IP adress (or maybe send a mail) to
 collect some data as to how many network based installations
 actually started, etc.
  
  If it could be possible to have the filename as one of
 the parameters in the hook, it would be even better, as then
 I can isolate actual installations that started, as opposed
 to TFTP requests which just loading the PXE menu.
  
  Regards,
  Shantanu
 
 That sounds to me like a very sensible suggestion.
 
 There are two obvious ways to do it: either add an extra
 hook (--tftp-script), or add an extra possible action
 value to the current --dhcp-script. I think the later is how
 I'd do it if starting from scratch, but it has the
 disadvantage of possibly breaking existing script code. On
 the other hand, any sane script should just ignore
 unrecognised actions; the example code supplied with dnsmasq
 does.
 
 Any script users out there, please check your code, would
 adding another value to {add, old, del, init} break stuff?
 
 
 
 Cheers,
 
 Simon.
 
 ___
 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] Feature Request: tftp-script

[richardvo...@gmail.com]

Existing scripts could definitely break, imagine one that just logs certain
environment variables plus the parameter.  The new action values won't have
the right environment variable set.

How about both?  Give the --tftp-script the same action parameter, and keep
actions unique, that way both options can be pointed to the same script, or
separate scripts.

On Mon, Mar 19, 2012 at 6:18 AM, Simon Kelley si...@thekelleys.org.ukwrote:

 On 18/03/12 07:09, Shantanu Gadgil wrote:

 Hi,

 I was wondering whether it would be possible to have hooks for the TFTP
 operations, just like the DHCP operations.

 This is just a rough thought for now ...
 When a TFTP request is made from the client (or is successful when the
 file is /actually/ provided), I want to be able to log the IP adress (or
 maybe send a mail) to collect some data as to how many network based
 installations actually started, etc.

 If it could be possible to have the filename as one of the parameters in
 the hook, it would be even better, as then I can isolate actual
 installations that started, as opposed to TFTP requests which just loading
 the PXE menu.

 Regards,
 Shantanu


 That sounds to me like a very sensible suggestion.

 There are two obvious ways to do it: either add an extra hook
 (--tftp-script), or add an extra possible action value to the current
 --dhcp-script. I think the later is how I'd do it if starting from scratch,
 but it has the disadvantage of possibly breaking existing script code. On
 the other hand, any sane script should just ignore unrecognised actions;
 the example code supplied with dnsmasq does.

 Any script users out there, please check your code, would adding another
 value to {add, old, del, init} break stuff?



 Cheers,

 Simon.


 __**_
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.**thekelleys.org.ukDnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.**uk/mailman/listinfo/dnsmasq-**discusshttp://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] Feature Request: tftp-script

[Shantanu Gadgil]

Hi,

I was wondering whether it would be possible to have hooks for the TFTP 
operations, just like the DHCP operations.

This is just a rough thought for now ...
When a TFTP request is made from the client (or is successful when the file is 
/actually/ provided), I want to be able to log the IP adress (or maybe send a 
mail) to collect some data as to how many network based installations actually 
started, etc.

If it could be possible to have the filename as one of the parameters in the 
hook, it would be even better, as then I can isolate actual installations that 
started, as opposed to TFTP requests which just loading the PXE menu.

Regards,
Shantanu

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

Re: [Dnsmasq-discuss] Feature Request(s)

[Simon Kelley]

On 15/03/12 22:22, Rob Zwissler wrote:



Consistency is always nice, so the choice is between consistent behavior
across hosts  dnsmasq.conf style configs, or consistent behavior within
dnsmasq.conf, I'd vote for the latter, so expand-hosts would be ignored
for host-record.


Agreed


If it does expand it it for host-record but not txt-record, etc, that
seems somewhat un-intuitive.

Perhaps a second expand-host-record to separately enable that?  Or a
more general expand-records (?) directive that would work for
host-record, txt-record, etc...


Hmm, maybe. I have a feeling that this is getting complex, especially as 
the domain added depends on --domain, which can be address-dependent. 
expand-hosts for /etc/hosts has the justification that (some) OS's work 
that way when using /etc/hosts outside dnsmasq, for dnsmasq-exclusive 
config, I'm inclined to keep it simple, especially as it's possible to 
include a simple name and an expanded name in the same line


host-record=laptop, laptop.thekelleys.org.uk, 192.168.0.1




The bind behavior with default expansion and a . to override seems nice,
simple  intuitive, what about a expand-bind-style directive to turn
that behavior on, so as not to break existing syntax, but give that fine
grained control to people who want it?


That breaks the rule that syntactically different configurations should 
vary by more than one pixel ;-). Missing the period at the end of a name 
in a BIND file is almost as annoying as mixing spaces and tabs in a 
Makefile.


I've got the host-record syntax above working fine. I'll update the man 
page and changelog later today an push it out for you to play with.




Cheers,

Simon.



Rob



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

Re: [Dnsmasq-discuss] Feature Request(s)

[Rob Zwissler]

Works great, thanks for the quick and excellent work Simon!

Rob


On Fri, Mar 16, 2012 at 9:26 AM, Simon Kelley si...@thekelleys.org.ukwrote:

 Test release with --host-record is there now:

 http://www.thekelleys.org.uk/**dnsmasq/test-releases/dnsmasq-**
 2.61test5.tar.gzhttp://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test5.tar.gz


 Cheers,

 Simon.



 __**_
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.**thekelleys.org.ukDnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.**uk/mailman/listinfo/dnsmasq-**discusshttp://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] Feature Request(s)

[Rob Zwissler]

On Fri, Mar 16, 2012 at 3:10 AM, Simon Kelley si...@thekelleys.org.ukwrote:


 Perhaps a second expand-host-record to separately enable that?  Or a
 more general expand-records (?) directive that would work for
 host-record, txt-record, etc...


 Hmm, maybe. I have a feeling that this is getting complex, especially as
 the domain added depends on --domain, which can be address-dependent.
 expand-hosts for /etc/hosts has the justification that (some) OS's work
 that way when using /etc/hosts outside dnsmasq, for dnsmasq-exclusive
 config, I'm inclined to keep it simple, especially as it's possible to
 include a simple name and an expanded name in the same line

 host-record=laptop, laptop.thekelleys.org.uk, 192.168.0.1

 The bind behavior with default expansion and a . to override seems nice,
 simple  intuitive, what about a expand-bind-style directive to turn
 that behavior on, so as not to break existing syntax, but give that fine
 grained control to people who want it?


 That breaks the rule that syntactically different configurations should
 vary by more than one pixel ;-). Missing the period at the end of a name in
 a BIND file is almost as annoying as mixing spaces and tabs in a Makefile.

 I've got the host-record syntax above working fine. I'll update the man
 page and changelog later today an push it out for you to play with.


The syntax you went with works great, it's simple, intuitive, and does the
job.

I was thinking about dnsmasq syntax and current functionality, the more I
think about it, if it was going to do any kind of host expansion, it would
be nice to do it in a similar way that bind does it with @ORIGIN, that is
to say, multiple @ORIGIN/$TTLs can be specified, and depending on where the
RR is located in the config file determines which @ORIGIN/$TTL it uses...

I'm guessing that would be require a lot rewriting the way dnsmasq parses
the config file, and at some point it's just turning dnsmasq into bind,
which it isn't...

So, good choice ;) the way it works now is great for my application.

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

Re: [Dnsmasq-discuss] Feature Request(s)

[Jan-Piet Mens]

 Maybe take it one step further,
 --host-record=address,name[,alias,alias,...] so we can keep the
 CNAMEs right there too.

Sounds sensible, as long as multiple --host-record are allowed for one name
(multi-homed, IPv4, IPv6)

-JP

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

Re: [Dnsmasq-discuss] Feature Request(s)

[/dev/rob0]

On Thu, Mar 15, 2012 at 10:24:44AM -0700, Rob Zwissler wrote:
 Yah, seems to me it would make more sense to key off the IP address 
 (or have that come first in the config) as it seems to make more 
 sense to organize zone files by IP, and since you can have multiple 
 A's per IP but not multiple IPs per PTR.

You CAN have as many PTR records as you want on any name. However, 
it's unlikely to do anything useful.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

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

Re: [Dnsmasq-discuss] Feature Request(s)

[Rob Zwissler]

On Thu, Mar 15, 2012 at 1:35 PM, Simon Kelley si...@thekelleys.org.ukwrote:


 All the other DNS record-creation options (txt-record, ptr-record,
 naptr-record, srv-host, mx-host) take the name as first argument,
 followed by target(s), so it would be good to follow that, however
 something more flexible is possible, by allowing an arbitrary number of
  names followed by an IPv4 address, an IPv6 address, or both


 --host-record = thekelleys.org, www.thekelleys.org, 1.2.3.4, 1234::11

 As usual, the first name gets the PTR record, so 'dig -x 1.2.3.4'
 returns thekelleys.org in my example.

 Next question, should expand-hosts work on the names as it does in
 /etc/hosts, but doesn't in txt-record and friends?


Consistency is always nice, so the choice is between consistent behavior
across hosts  dnsmasq.conf style configs, or consistent behavior within
dnsmasq.conf, I'd vote for the latter, so expand-hosts would be ignored for
host-record.

If it does expand it it for host-record but not txt-record, etc, that seems
somewhat un-intuitive.

Perhaps a second expand-host-record to separately enable that?  Or a more
general expand-records (?) directive that would work for host-record,
txt-record, etc...

The bind behavior with default expansion and a . to override seems nice,
simple  intuitive, what about a expand-bind-style directive to turn that
behavior on, so as not to break existing syntax, but give that fine grained
control to people who want it?

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

Re: [Dnsmasq-discuss] Feature Request(s)

[Rob Zwissler]

I think he was talking about multiple PTR records for a single IP, not
multiple PTR records all returning the same hostname (which agreed, is
clearly a reasonable usage).  It does look like bind will do it, but seems
like an unusual thing to do; although I didn't see an explicit mention of
it being poor practice in RFC 1912, or a couple other RFCs I skimmed, but
I'm far from a DNS guru.  Is there a legitimate use to that?

;; QUESTION SECTION:
;149.50.14.10.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
149.50.14.10.in-addr.arpa. 604800 INPTR hostname.domain.com.
149.50.14.10.in-addr.arpa. 604800 INPTR hostname-2.domain.com.

regards

Rob

On Thu, Mar 15, 2012 at 3:27 PM, Ben Finney 
bignose+hates-s...@benfinney.id.au wrote:

 /dev/rob0 r...@gmx.co.uk writes:

  You CAN have as many PTR records as you want on any name. However,
  it's unlikely to do anything useful.

 It can be quite useful, since machines can have multiple NICs on the
 same network (for redundancy, among other reasons) each presenting a
 different IP address.

 --
  \  “The best way to get information on Usenet is not to ask a |
  `\   question, but to post the wrong information.” —Aahz |
 _o__)  |
 Ben Finney


 ___
 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] Feature Request(s)

[/dev/rob0]

On Thu, Mar 15, 2012 at 03:14:08PM -0500,
   richardvo...@gmail.com wrote:
 On Thu, Mar 15, 2012 at 2:34 PM, /dev/rob0 r...@gmx.co.uk wrote:
 
  On Thu, Mar 15, 2012 at 10:24:44AM -0700, Rob Zwissler wrote:
   Yah, seems to me it would make more sense to key off the IP 
   address (or have that come first in the config) as it seems to 
   make more sense to organize zone files by IP, and since you can 
   have multiple A's per IP but not multiple IPs per PTR.
 
  You CAN have as many PTR records as you want on any name. 
  However, it's unlikely to do anything useful.
 
 Since the PTR name contains the IP, by definition different IPs
 means different PTR records.

There is nothing preventing you from having as many PTRs on a single 
in-addr.arpa name as you might wish. Here's a silly example:

$ dig 78.247.23.216.in-addr.arpa. any @216.23.247.74

;; QUESTION SECTION:
;78.247.23.216.in-addr.arpa.IN  ANY

;; ANSWER SECTION:
78.247.23.216.in-addr.arpa. 7200 IN SOA ns.slackbuilds.org. 
hostmaster.ns.slackbuilds.org. 2012031502 28800 7200 864000 7200
78.247.23.216.in-addr.arpa. 7200 IN NS  ns2.slackbuilds.org.
78.247.23.216.in-addr.arpa. 7200 IN PTR c78.nodns4.us.
78.247.23.216.in-addr.arpa. 7200 IN PTR 
look.here.another.ptr.78.247.23.216.in-addr.arpa.
78.247.23.216.in-addr.arpa. 7200 IN PTR third.ptr.wow.
78.247.23.216.in-addr.arpa. 7200 IN A   216.23.247.79
78.247.23.216.in-addr.arpa. 7200 IN TXT A TXT record also.
78.247.23.216.in-addr.arpa. 7200 IN TXT CNAME record is the one thing 
we cannot do.

SOA, NS, three PTRs, A, and two TXTs on that name. Silly stuff, yet 
quite within the range of DNS legitimacy. My point is, however, that 
resolvers won't know what to do with multiple PTRs on the same name.

Similarly, you can add PTR records in forward zones. There's no 
limit to the fun, fine in DNS. But no resolver would ask for these 
PTRs (unless in an RFC 2317 CNAME reference.)

See, I even missed the trailing dot on the middle PTR for fun. Or 
pure sloppiness. :)

In 877gylpki8@benfinney.id.au
On Fri, Mar 16, 2012 at 09:27:59AM +1100, Ben Finney wrote:
 /dev/rob0 r...@gmx.co.uk writes:

  You CAN have as many PTR records as you want on any name. 
  However, it's unlikely to do anything useful.

 It can be quite useful, since machines can have multiple NICs
 on the same network (for redundancy, among other reasons) each 
 presenting a different IP address.

I thought we were talking about multiple PTRs on the same name. 
Different IP addresses would mean different in-addr.arpa names. It
sounds like you are talking about multiple identical PTR values, 
where the in-addr.arpa names differ.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

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

Re: [Dnsmasq-discuss] Feature Request(s)

[Simon Kelley]

On 09/03/12 19:05, Rob Zwissler wrote:
 Hi Simon - I'm a big fan of DNSMasq, it's great software, thanks all for
 your hard work.  I had three requests/questions I just wanted to throw out
 there that would come in handy for simplifying configuration in what I
 think would be an intuitive way.  For the most part, this is related to
 consolidating DNSMasq implementations into a single config file and
 extending cmd line syntax to reduce reliance on external files.  I really
 like the self contained simple nature of DNSMasq and I won't be happy until
 it's as powerful and cryptic as Perl ;)
 
 1) address=/domain/ip works great as described, but *.domain and *.*.domain
 (etc...) also resolv based on this syntax.  Syntax like address=/.domain/ip
 that would prevent *.domain from resolving, or address=/..domain/ip would
 prevent *.*.domain but allow *.domain, something in that vain, would come
 in handy.  That way, single A records could be overridden with
 address=/.host/ip so I could keep everything in a single dnsmasq.conf file
 without maintaining a separate addn-hosts file.  Seems like this could
 extend functionality in a very intuitive, backwards-compatible way without
 adding much messiness to config or documentation.

That's a bit of a minefield: address=/.domain/ and address=/domain/ are
equivalent, the former being accepted for backwards-compatibility
reasons. There exists a patch which allows full regexps, which takes the
line of reasoning to the limit. It's never been included because I thing
trying to encode policy on names is wrong, it's too easy end up with the
wrong results if you make statement about anything other than a domain.
 
 2) Any reason why an /etc/hosts syntax line can't be put in a dnsmasq.conf
 file?  As far as I can tell it wouldn't break the dnsmasq syntax, and it
 would allow for consolidating files in a very intuitive, minimalist way.
 

/etc/hosts syntax would be difficult to translate into equivalent
command line options, for consistency, something like

--a-record = name,address
---record = name, address

and

--host-record = name, address

which does a both forward and backwards would be possible, I've
considered this before, but most people seem to like to split off such
data into a separate /etc/hosts or another hosts-like file.

 3) If #1  #2 aren't feasible, how about something like a=host,ip that
 would allow for an A/PTR pair in more traditional dnsmasq.conf style
 syntax, to reduce the need for an addn-hosts file.

See above.
 
 4) How come cname= only works for local hosts?  Would that be difficult to
 implement so you could create CNAMEs for A records hosted on upstream
 servers?
 
It's a real architectural limitation: the data in a reply has to come
from only local information, or only upstream information, mixing the
two isn't possible. Stub resolvers require both bits of information in
one reply.

Cheers,

Simon.


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

Re: [Dnsmasq-discuss] Feature Request(s)

[Rob Zwissler]

On Wed, Mar 14, 2012 at 1:07 PM, Simon Kelley si...@thekelleys.org.ukwrote:

 /etc/hosts syntax would be difficult to translate into equivalent
 command line options, for consistency, something like

 --a-record = name,address
 ---record = name, address

 and

 --host-record = name, address

 which does a both forward and backwards would be possible, I've
 considered this before, but most people seem to like to split off such
 data into a separate /etc/hosts or another hosts-like file


If you're taking votes, I'd like to see this, it'd be nice to have one
centralized file for a dns config.  It would be nice to keep SRV/TXT
records right next to their matching A record, bind style.  Having PTRs in
the same file would put you one step above bind :)

Maybe take it one step further,
--host-record=address,name[,alias,alias,...] so we can keep the
CNAMEs right there too.

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

[Dnsmasq-discuss] Feature Request(s)

[Rob Zwissler]

Hi Simon - I'm a big fan of DNSMasq, it's great software, thanks all for
your hard work.  I had three requests/questions I just wanted to throw out
there that would come in handy for simplifying configuration in what I
think would be an intuitive way.  For the most part, this is related to
consolidating DNSMasq implementations into a single config file and
extending cmd line syntax to reduce reliance on external files.  I really
like the self contained simple nature of DNSMasq and I won't be happy until
it's as powerful and cryptic as Perl ;)

1) address=/domain/ip works great as described, but *.domain and *.*.domain
(etc...) also resolv based on this syntax.  Syntax like address=/.domain/ip
that would prevent *.domain from resolving, or address=/..domain/ip would
prevent *.*.domain but allow *.domain, something in that vain, would come
in handy.  That way, single A records could be overridden with
address=/.host/ip so I could keep everything in a single dnsmasq.conf file
without maintaining a separate addn-hosts file.  Seems like this could
extend functionality in a very intuitive, backwards-compatible way without
adding much messiness to config or documentation.

2) Any reason why an /etc/hosts syntax line can't be put in a dnsmasq.conf
file?  As far as I can tell it wouldn't break the dnsmasq syntax, and it
would allow for consolidating files in a very intuitive, minimalist way.

3) If #1  #2 aren't feasible, how about something like a=host,ip that
would allow for an A/PTR pair in more traditional dnsmasq.conf style
syntax, to reduce the need for an addn-hosts file.

4) How come cname= only works for local hosts?  Would that be difficult to
implement so you could create CNAMEs for A records hosted on upstream
servers?

regards,

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

Re: [Dnsmasq-discuss] Feature request:

[Ed W]

 
 The solution is to use --dhcp-hostsfile instead. That gives you all the 
 functionality of dhcp-host but in database file.


Superb.  Additionally, this function isn't documented in the example
config, but does in fact work fine as a configfile option!

I guess I missed it by only reading the config example and not looking
at the command line options - it's quite a useful feature, so perhaps
worth documenting next to the /etc/ethers example?

Thanks for the wonderful software which is dnsmasq!

Ed W

Re: [Dnsmasq-discuss] Feature request:

[Simon Kelley]

Ed W wrote:
 The solution is to use --dhcp-hostsfile instead. That gives you all the 
 functionality of dhcp-host but in database file.
 
 
 Superb.  Additionally, this function isn't documented in the example
 config, but does in fact work fine as a configfile option!
 
 I guess I missed it by only reading the config example and not looking
 at the command line options - it's quite a useful feature, so perhaps
 worth documenting next to the /etc/ethers example?

A good suggestion. The example config currently falls between to stools,
it's neither  comprehensive nor small enough to be quickly usable for
simple installations. Ideally there shoud be two examples, one for each
of these functions.


Cheers,

Simon.

 
 Thanks for the wonderful software which is dnsmasq!
 
 Ed W
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
 

Re: [Dnsmasq-discuss] Feature request:

[Simon Kelley]

On 09/03/11 22:49, Ed W wrote:

I'm trying to manage as much of my static config as possible using only
/etc/ethers (managed basically as a small text database)

However, I have a small number of machines where I fudge things a little
for convenience, eg my laptop I force the same IP on both the wired and
wireless interface (it allows me to unplug the wired network, walk away
from my desk and my ssh sessions don't drop).

This config I haven't been able to figure out how to express in
/etc/ethers notation and I need to use /etc/dnsmasq.conf like:

dhcp-host=01:02:03:04:05:06,06:05:04:03:02:01,192.168.1.222

If it's possible to use ethers could you please describe how?  If it's
not could I please make a feature request to support this in some future
release?


The syntax and semantics of /etc/ethers are defined elsewhere: it's not 
possible to extend them without breaking other systems which also read 
/etc/ethers.


The solution is to use --dhcp-hostsfile instead. That gives you all the 
functionality of dhcp-host but in database file.


Cheers,

Simon.