Re: [Dnsmasq-discuss] Behavior change of upstream servers set via DBus
Thanks for your help, I'll try getting the problem sloved once I get some free time. For now, I'm still using dnsmasq 2.85 and that should be fine for a while. On Wed, 2021-11-24 at 15:32 +0100, Petr Menšík wrote: > I understand Jerry had simple setup with dnsmasq 2.85, just using > NetworkManager and dns=dnsmasq. He were able to configure something > like > two sets of nameservers. One configured automatically by Network > Manager, the second hardcoded using server=/#/1.1.1.1. > > It is interesting use case. I think something similar to dhcp tags > would > be nice here. If he could define alternative set of servers and not > copy > again and again target server IP. Especially when he uses kind of > negated matches. > > I do not think this were implemented intentionally before. /#/ is > documented only for --address as a fallback, it seems like more > coincidence it worked this way also with --server. > > I think good approach would be sending clean domains to alternative > instance listening on localhost, different port or IP. That would > have > configured just server=1.1.1.1. You might be even able to setup > stubby > for DNS over TLS encryption for those clean domains, if that is > permitted and possible. It might be any other dns server, while > dnsmasq > would be configured by Network Manager for easy configuration and > provide name based redirection. > > # example of clean record > server=/clean.example/127.0.0.1#1053 > > I understand it requires additional instance, but that should be okay > on > common laptop. > > Cheers, > Petr > > On 11/20/21 19:07, Matus UHLAR - fantomas via Dnsmasq-discuss wrote: > > On 17.11.21 15:50, Jerry Xiao wrote: > > > It's unnecessary and inefficient to rebuild a config file that > > > long > > > every time you connect to a new wifi network, > > > > well, you have used default and "default" server, where the > > "default" was > > not really default, because only configured domains were pointed to > > it. > > > > yes, you used undocumented feature of dnsmasq that gort removed. > > > > what you need is some kind of "server-alias", I guess you are > > welcome to > > provide a patch or hope someone will make it for you. > > > > > and btw this is also bad for your ssd. > > > > have you never heard of tmpfs? > > > > alternatively, you can use multiple dnsmasq instances, one > > forwarding to > > default server and only named domains to the second instance. The > > second > > instance will forward to dhcp-provided nameserver(s). > > > > > > On 11.11.21 15:12, Jerry Xiao wrote: > > > > > I was using dnsmasq 2.85 to do all of this, until it is > > > > > upgraded > > > > > and no > > > > > longer works. I'm not quite sure if it is an unintentional > > > > > feature > > > > > on > > > > > the old version 2.85, in option.c there is a piece of clearly > > > > > intentional code to deal with the sharp inside something like > > > > > "server=/#/1.1.1.1" > > > > > > > > > > if (strcmp(arg, "#") == 0) > > > > > domain = ""; > > > > > > > > > > this also sets the SERV_HAS_DOMAIN server flag below. > > > > > I remember seeing the feature being discussed in the mailing > > > > > list, > > > > > though the thread is not that easy to find. > > > > > > > > > > I spent some more time digging into the code base, only to > > > > > find out > > > > > that there is no "easy" way to implement this in the new > > > > > version > > > > > because of the new sorting algorithm used for choosing > > > > > servers, the > > > > > vastly changed server flags (SERV_HAS_DOMAIN, along with some > > > > > other > > > > > flags, are removed) and the fact that server flags and query > > > > > flags > > > > > are > > > > > already full, idk if the upstream is willing to merge my > > > > > changes if > > > > > the > > > > > size of the flags are enarged. > > > > > > > > > > Worst case I just replace dnsmasq with systemd-networkd, but > > > > > before > > > > > that I'd like to know if there's still other ways to > > > > > implement > > > > > this. > > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CNAME responses are not processed through address=/ ... / filter
Hey Alex, On Thu, 2021-11-25 at 11:05 -0600, Alex Rainchik wrote: > Not sure if it’s a bug or feature request :) The latter. The observed behavior is expected. Note that dnsmasq is a DNS *forwarder* equipped with a local cache. It is not a *recursive* server. Dnsmasq has to forward queries where no local answers exist to upstream DNS servers and relies on external recursion. On Thu, 2021-11-25 at 11:05 -0600, Alex Rainchik wrote: > Expected behavior would be for setup.icloud.com query to get > "10.10.10.10" response, same as for setup.fe.apple-dns.net. > Because setup.icloud.com is a CNAME pointing to setup.fe.apple- > dns.net As Geert already mentioned, dnsmasq is neither meant nor designed to post-process replies from upstream DNS server. Best, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CNAME responses are not processed through address=/ ... / filter
On Thu, Nov 25, 2021 at 11:05:03AM -0600, Alex Rainchik wrote: > Hello, > > This is my first message here :) Welcome > Not sure if it’s a bug or feature request :) Me neither 8^) > It looks like CNAME responses are not processed through address=/ ... / > filter, > here is an example > > Config file test.cfg: > > # listening DNS port > port=3 > # do not read /etc/resolv.conf at all > no-resolv > # do not re-read /etc/resolv.conf when file was changed by ISP > no-poll > # default upstream dns server > server=1.1.1.1 > address=/setup.fe.apple-dns.net/10.10.10.10 > log-debug > log-queries=extra > log-facility=/dev/stdout > keep-in-foreground > no-daemon > > Running test as “dnsmasq -C test.cfg” > > Direct query for "setup.fe.apple-dns.net" works as expected: > > username@mac:~$ dig @127.0.0.1 -p3 -t A setup.fe.apple-dns.net. +short > 10.10.10.10 > > However when I query "setup.icloud.com", which is a CNAME pointing to > "setup.fe.apple-dns.net" it does not get processed trough > address=/ … / filter: > > username@mac:~$ dig @127.0.0.1 -p3 -t A setup.icloud.com +short > setup.fe.apple-dns.net. > 17.248.190.138 > 17.248.190.206 > 17.248.190.112 > 17.248.190.68 > 17.248.168.72 > 17.248.190.71 > 17.248.168.68 > 17.248.190.104 > > Expected behavior would be for setup.icloud.com query to get > "10.10.10.10" response, same as for setup.fe.apple-dns.net. Because > setup.icloud.com is a CNAME pointing to setup.fe.apple-dns.net $ dig @9.9.9.9 -t A setup.icloud.com ; <<>> DiG 9.16.13-Debian <<>> @9.9.9.9 -t A setup.icloud.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30811 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;setup.icloud.com. IN A ;; ANSWER SECTION: setup.icloud.com. 3371IN CNAME setup.fe.apple-dns.net. setup.fe.apple-dns.net. 19 IN A 17.248.177.5 setup.fe.apple-dns.net. 19 IN A 17.248.176.36 setup.fe.apple-dns.net. 19 IN A 17.248.176.50 setup.fe.apple-dns.net. 19 IN A 17.248.177.40 setup.fe.apple-dns.net. 19 IN A 17.248.176.237 setup.fe.apple-dns.net. 19 IN A 17.248.176.41 setup.fe.apple-dns.net. 19 IN A 17.248.176.233 setup.fe.apple-dns.net. 19 IN A 17.248.176.48 ;; Query time: 28 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: do nov 25 18:44:52 CET 2021 ;; MSG SIZE rcvd: 209 As I see it: * the `dig -t A setup.icloud.com` is one single request * the response comes from one single upstream server * there is no need for Dnsmasq to redact the response My advise to original poster is to add address=/setup.icloud.com/10.10.10.10 to the configuration. 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
[Dnsmasq-discuss] CNAME responses are not processed through address=/ ... / filter
Hello, This is my first message here :) Not sure if it’s a bug or feature request :) It looks like CNAME responses are not processed through address=/ ... / filter, here is an example Config file test.cfg: # listening DNS port port=3 # do not read /etc/resolv.conf at all no-resolv # do not re-read /etc/resolv.conf when file was changed by ISP no-poll # default upstream dns server server=1.1.1.1 address=/setup.fe.apple-dns.net/10.10.10.10 log-debug log-queries=extra log-facility=/dev/stdout keep-in-foreground no-daemon Running test as “dnsmasq -C test.cfg” Direct query for "setup.fe.apple-dns.net" works as expected: username@mac:~$ dig @127.0.0.1 -p3 -t A setup.fe.apple-dns.net. +short 10.10.10.10 However when I query "setup.icloud.com", which is a CNAME pointing to "setup.fe.apple-dns.net" it does not get processed trough address=/ … / filter: username@mac:~$ dig @127.0.0.1 -p3 -t A setup.icloud.com +short setup.fe.apple-dns.net. 17.248.190.138 17.248.190.206 17.248.190.112 17.248.190.68 17.248.168.72 17.248.190.71 17.248.168.68 17.248.190.104 Expected behavior would be for setup.icloud.com query to get "10.10.10.10" response, same as for setup.fe.apple-dns.net. Because setup.icloud.com is a CNAME pointing to setup.fe.apple-dns.net ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
