Re: [Dnsmasq-discuss] [PATCH] Re: --server=/example/8.8.8.8 --server=/example/9.9.9.9 behaviour
On 5/4/21 4:00 PM, Petr Menšík wrote: [...] With some hierarchy, it could reduce number of entries compared. Binary tree implementation still might be better, but harder to implement well. why is that? btree libraries have been around for decades and should be easy enough to add and use... we used them fairly often back in my PASCAL days but the world has changed a bit since then... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH v6] Connection track mark based DNS query filtering.
This extends query filtering support beyond what is currently possible with the `--ipset` configuration option, by adding support for: 1) Specifying allowlists on a per-client basis, based on their associated Linux connection track mark. 2) Dynamic configuration of allowlists via Ubus. 3) Reporting when a DNS query resolves or is rejected via Ubus. 4) DNS name patterns containing wildcards. Disallowed queries are not forwarded; they are rejected with a REFUSED error code. Signed-off-by: Etan Kissling (addressed reviewer feedback) Signed-off-by: Etan Kissling --- v2: Rebase to v2.83, and fix compilation when HAVE_UBUS not present. v3: Rebase to v2.84test2. v4: Rebase to v2.84rc2 (update copyright notice). v5: Correct logging of `ubus_notify` errors (also in existing code). Etan Kissling : v6: Integrate checks for weird queries into `extract_request`. Skip Ubus reporting when daemon->namebuff is not initialized. Fix options parsing for mark / mask with bit 31 set. Disable filtering for external queries (`auth_dns && !local_auth`). Report all CNAME RRs via Ubus instead of just a (potential) subset. Avoid redundant `is_valid_dns_name` evaluations. Unify DNS name pattern matching logic across transports (UDP / TCP). Makefile | 2 +- man/dnsmasq.8 | 31 +++- src/dnsmasq.h | 25 +++- src/forward.c | 134 +- src/option.c | 151 src/pattern.c | 386 ++ src/rfc1035.c | 77 +- src/ubus.c| 184 +++- 8 files changed, 980 insertions(+), 10 deletions(-) create mode 100644 src/pattern.c diff --git a/Makefile b/Makefile index e4c3f5c..506e56b 100644 --- a/Makefile +++ b/Makefile @@ -79,7 +79,7 @@ copts_conf = .copts_$(sum) objs = cache.o rfc1035.o util.o option.o forward.o network.o \ dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o \ helper.o tftp.o log.o conntrack.o dhcp6.o rfc3315.o \ - dhcp-common.o outpacket.o radv.o slaac.o auth.o ipset.o \ + dhcp-common.o outpacket.o radv.o slaac.o auth.o ipset.o pattern.o \ domain.o dnssec.o blockdata.o tables.o loop.o inotify.o \ poll.o rrfilter.o edns0.o arp.o crypto.o dump.o ubus.o \ metrics.o hash_questions.o diff --git a/man/dnsmasq.8 b/man/dnsmasq.8 index ac7c9fa..04d666d 100644 --- a/man/dnsmasq.8 +++ b/man/dnsmasq.8 @@ -368,7 +368,10 @@ provides service at that name, rather than the default which is .TP .B --enable-ubus[=] Enable dnsmasq UBus interface. It sends notifications via UBus on -DHCPACK and DHCPRELEASE events. Furthermore it offers metrics. +DHCPACK and DHCPRELEASE events. Furthermore it offers metrics +and allows configuration of Linux connection track mark based filtering. +When DNS query filtering based on Linux connection track marks is enabled +UBus notifications are generated for each resolved or filtered DNS query. Requires that dnsmasq has been built with UBus support. If the service name is given, dnsmasq provides service at that namespace, rather than the default which is @@ -533,6 +536,32 @@ These IP sets must already exist. See .BR ipset (8) for more details. .TP +.B --connmark-allowlist-enable[=] +Enables filtering of incoming DNS queries with associated Linux connection track marks +according to individual allowlists configured via a series of \fB--connmark-allowlist\fP +options. Disallowed queries are not forwarded; they are rejected with a REFUSED error code. +DNS queries are only allowed if they do not have an associated Linux connection +track mark, or if the queried domains match the configured DNS patterns for the +associated Linux connection track mark. If no allowlist is configured for a +Linux connection track mark, all DNS queries associated with that mark are rejected. +If a mask is specified, Linux connection track marks are first bitwise ANDed +with the given mask before being processed. +.TP +.B --connmark-allowlist=[/][,[/...]] +Configures the DNS patterns that are allowed in DNS queries associated with +the given Linux connection track mark. +If a mask is specified, Linux connection track marks are first bitwise ANDed +with the given mask before they are compared to the given connection track mark. +Patterns follow the syntax of DNS names, but additionally allow the wildcard +character "*" to be used up to twice per label to match 0 or more characters +within that label. Note that the wildcard never matches a dot (e.g., "*.example.com" +matches "api.example.com" but not "api.us.example.com"). Patterns must be +fully qualified, i.e., consist of at least two labels. The final label must not be +fully numeric, and must not be the "local" pseudo-TLD. A pattern must end with at least +two literal (non-wildcard) labels. +Instead of a pattern, "*" can be specified to disable allowlist filtering +for a given Linux connection track mark entirely. +.TP .B \-m, --mx-host=[[,],] Return an MX record
Re: [Dnsmasq-discuss] [PATCH] Re: --server=/example/8.8.8.8 --server=/example/9.9.9.9 behaviour
Hi, wrote some ideas I had about it. On 5/3/21 6:49 PM, Simon Kelley wrote: > This is just to mark that I have spent the afternoon thinking about > this, and I'm in the process of a rather larger re-factor of the code. > > The aim of this is to cover the points Petr makes below, but > additionally, to: > > 1) Allow a fast matching between subdomains in the configuration and the > query domain, s=to handle the ad-blocks that use thousands of > --local=/porn.here/ configuration lines. It seems to me comparison in something like wire format would be more efficient. It might for example store each label separately, making it a tree. If the name ends with .com, it does not need check filters with .org, .net or .info. With some hierarchy, it could reduce number of entries compared. Binary tree implementation still might be better, but harder to implement well. test.com example.com one.bad.net blocked.net becomes: com net / | | \ test example bad blocked | one Not sure how much pointers on 64 bit platforms would compare with ability to store just non-overlaping labels. Just a simple hierarchy would store complex domain names with a cascade of pointers. Should help on hosts with a lot of domain filters, common parts would get reused. Interesting especially for top level domains. Might fragment memory too much on the other hand. > > 2) To make the storage of --local=/domain/ more efficient. > > 3) To tidy up the mess that is search servers. > > > The first part of the plan is to remove the overloading of struct server > to store --address, --local and --rebind-domain-ok My design attempt just moved some flags to domain, making --local and --rebind-domain-ok propery of domain, not the server. > > > There will be a data-structure that just holds domains, around which a > fast search algorithm can be put. Each domain will hold a pointer to a > struct server and a pointer to a list of addresses, to handle the > situation of > > --server=/example.com/1.2.3.4 > --address=/example.com/1.1.1.1 Is this scenario even documented? It it desirable to behave described way? According to man page, --address should handle also all subdomains. Unless we allow --server=/*.example.com/1.2.3.4, this seems like configuration error, or warning --address would override --server statement before. Should we mark .example.com with some flag, so its meaning is different from example.com I would say those instructions are in conflict and should result in configuration error. Are they needed in specific cases? > > Which answers A queries for example.com with 1.1.1.1 but forwards other > queries to 1.2.3.4 > > The algorithm for forwarding is > > 1) look up query-domain for domain-structure above with longest match. If those domains are sorted smart way, it can know no better match would be found before walking over to the last domain record. Was that considered? > 2) Is there a suitable address? If so answer with that. > 3) Otherwise, the struct server pointer points to the one of the set of > servers which cover this domain, all linked in a ring with a new > group_next pointer. > > The last_server feature is implemented by setting a flag for whichever > server in this ring is last used. That server has the forwarded counts > and times as well. When I was thinking about it, I considered also rotation of servers in selected domain. When middle S2 becomes last_used server, just append any servers before it to the end. s1-s2-s3 becomes s2-s3-s1 on setting s2 as last successful server. If pointer to last item is stored, it could be done without iteration to the end of list. I think it is more CPU effective than searching the server with flag each time query should be sent, trying the first one or potentially walking over all of them. Send number count and last timestamp is property of domain IMO, not the server record itself. But it won't be used on domain without forwarders. Does it make sense to store query counts for other than non-last server, multiple times per domain? > > This makes the forwarding code which cycles through all eligible servers > very easy. > > This code replaces some really knarly and old code, so it's not a small > job to re-write it, especially as the list of servers is dynamic, with > DBUS etc. Sure, it is quite a lot of changes. High risk of some regressions too. But could improve speed and memory requirements in some situations significantly. Any improvement would be great. > > > > Simon. > > > > > > On 19/04/2021 19:19, Petr Menšík wrote: >> Hi, >> >> I managed to prepare minimal change required. I think there is plenty of >> space to optimize daemon->servers handling, but added slight addition to >> it only. It introduces structure for every domain, keeping its state. >> >> According to dig ch txt servers.bind, it does what I tried. Reduces >> number of queries sent to alternative server, but queries it from time >> to
Re: [Dnsmasq-discuss] Using a reverse lookup host file
On 04.05.21 18:17, Ercolino de Spiacico wrote: 1) why doesn't dnsmasq perform reverse DNS resolution by default? All the info is in there but it seems like additional directives are needed. what do you mean? dnsmasq resoves everything it can, but only if you ask for it. 2) Talking about having an external file where reverse lookup info is held, how would this be linked to the main dnsmasq configuration and what would the content of it look like e.g. syntax? All I could find are configuration directives like: host-record=node01.black.system,10.248.11.21 well, by this you explicitly configure dnsmasq to provide only A lookup. but my idea would be to have something that looks more like the host file (if possible at all). Where can I find the relevant documentation on how to achieve this and/or can I get some help on how to get started? you can /etc/hosts instead, which is standard file in UN*X operating systems. dnsmasq uses it for forward and reverse resolution, unless you disable it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Using a reverse lookup host file
I would like to ask two questions on dnsmasq name resolution: 1) why doesn't dnsmasq perform reverse DNS resolution by default? All the info is in there but it seems like additional directives are needed. 2) Talking about having an external file where reverse lookup info is held, how would this be linked to the main dnsmasq configuration and what would the content of it look like e.g. syntax? All I could find are configuration directives like: host-record=node01.black.system,10.248.11.21 but my idea would be to have something that looks more like the host file (if possible at all). Where can I find the relevant documentation on how to achieve this and/or can I get some help on how to get started? 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] [PATCH] Re: --server=/example/8.8.8.8 --server=/example/9.9.9.9 behaviour
> On 3 May 2021, at 17:49, Simon Kelley wrote: > > This is just to mark that I have spent the afternoon thinking about > this, and I'm in the process of a rather larger re-factor of the code. Can’t wait to test it ‘cos the description sounds great - thanks for the update. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
