Re: [Dnsmasq-discuss] Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query?
Hey Rick, On 9/24/2021 4:05, Rick Thomas wrote: You are right. It is a mis-config. If you have the time and interest, I'd appreciate any help you (or the list) can give on correcting the mis-config... Here's the story: As noted, my ISP does not provide IPv6 and has no plans to provide it in the future. I've emailed their technical help line and asked when they might provide IPv6, and got absolute total stony silence in reply. But I wanted to try experimenting with making my home LAN dual-stack, and fortunately, Hurricane Electric (HE) provides a free (no cost) easy-to-set-up tunnel service for folks like me. So I signed up with HE and got a /48 IPv6 subnet for my local home LAN. I bought an inexpensive netgate box (nowadays, I'd use a Raspberry Pi4B) and set it up running Debian as a gateway to HE for my LAN. It worked great! I was able to access IPv6-only sites and able to login directly from outside the home LAN (without any firewall pinholes) to the auto-configured IPv6 address of the machines on my LAN. And thereby lies the catch. With this setup, any hacker with an IPv6 connection can connect to and try to hack any of the machines on my LAN. I'd like to prevent that with the equivalent of an IPv4 NAT whereby incoming IPv6 packets are filtered so that anything that is not part of an established connection initiated from inside the LAN will be dropped. I'm sure it's possible but I'm finding the "iptables" documentation pretty opaque. Anybody who can point me to a worked example from someone who has done this successfully will be a friend for life. So I disabled forwarding for IPv6 on the netgate machine -- or at least I thought I did. It appears that somehow the IPv6 subnet address was still leaking out and all the machines on my LAN were convinced that the netgate machine was still acting as a gateway. On that assumption, I unplugged the netgate, so that such leakage would be physically impossible, and -- lo and behold -- the problems went away! Now, what I'd like to do -- but need help doing -- is to set up an iptables firewall to prevent outside access via IPv6, so I can continue experimenting and contributing to world-wide acceptance of IPv6. Thanks! Rick I am using an HE tunnel in one of my networks as well. But I am using OpenWrt on the router, which does the firewall setting (ip6tables) for me. Maybe it's an option to switch to OpenWrt instead of Debian? Otherwise, this link gives some examples, which might be of help to setup stateful firewalling: https://www.sixxs.net/wiki/IPv6_Firewalling PS: My original question still stands, though as more of a request for new feature: It would be nice have some way to tell dnsmasq to give a negative reply to any IPv6 query for IPv4-only nets. And vice versa -- give a negative reply to any IPv4 query for IPv6-only nets. Is such a thing possible? I was actually working on a patch that would do this (although no autodetection). However, my patch had some serious flaws and I have no idea how to implement it now (I was told I have to use rrfilter, but I am too unskilled in C to understand how it's all connected under the hood). Cheers, Treysis On Thu, Sep 23, 2021, at 1:56 AM, Trey Sis wrote: There's something wrong with your setup. Did you manually configure an IPv6 address for your machine? wget shouldn't try the IPv6 address if there is no route to the destination. Cheers, Treysis On 9/23/2021 10:02, Rick Thomas wrote: My ISP does not support IPv6 at all. Recently I have been having trouble connecting (web and/or ssh) to hosts outside of my local home LAN that have both IPv4 and IPv6 addresses. For example: rbthomas@monk:~$ host www.google.com www.google.com has address 142.251.33.68 www.google.com has IPv6 address 2607:f8b0:400a:806::2004 rbthomas@monk:~$ wget www.google.com --2021-09-22 18:23:06-- http://www.google.com/ Resolving www.google.com (www.google.com)... 2607:f8b0:400a:806::2004, 142.251.33.68 Connecting to www.google.com (www.google.com)|2607:f8b0:400a:806::2004|:80... ^C Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query? I'm using the debian dnsmasq package version 2.85-1 Thanks! Rick ___ 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
Re: [Dnsmasq-discuss] Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query?
You are right. It is a mis-config. If you have the time and interest, I'd appreciate any help you (or the list) can give on correcting the mis-config... Here's the story: As noted, my ISP does not provide IPv6 and has no plans to provide it in the future. I've emailed their technical help line and asked when they might provide IPv6, and got absolute total stony silence in reply. But I wanted to try experimenting with making my home LAN dual-stack, and fortunately, Hurricane Electric (HE) provides a free (no cost) easy-to-set-up tunnel service for folks like me. So I signed up with HE and got a /48 IPv6 subnet for my local home LAN. I bought an inexpensive netgate box (nowadays, I'd use a Raspberry Pi4B) and set it up running Debian as a gateway to HE for my LAN. It worked great! I was able to access IPv6-only sites and able to login directly from outside the home LAN (without any firewall pinholes) to the auto-configured IPv6 address of the machines on my LAN. And thereby lies the catch. With this setup, any hacker with an IPv6 connection can connect to and try to hack any of the machines on my LAN. I'd like to prevent that with the equivalent of an IPv4 NAT whereby incoming IPv6 packets are filtered so that anything that is not part of an established connection initiated from inside the LAN will be dropped. I'm sure it's possible but I'm finding the "iptables" documentation pretty opaque. Anybody who can point me to a worked example from someone who has done this successfully will be a friend for life. So I disabled forwarding for IPv6 on the netgate machine -- or at least I thought I did. It appears that somehow the IPv6 subnet address was still leaking out and all the machines on my LAN were convinced that the netgate machine was still acting as a gateway. On that assumption, I unplugged the netgate, so that such leakage would be physically impossible, and -- lo and behold -- the problems went away! Now, what I'd like to do -- but need help doing -- is to set up an iptables firewall to prevent outside access via IPv6, so I can continue experimenting and contributing to world-wide acceptance of IPv6. Thanks! Rick PS: My original question still stands, though as more of a request for new feature: It would be nice have some way to tell dnsmasq to give a negative reply to any IPv6 query for IPv4-only nets. And vice versa -- give a negative reply to any IPv4 query for IPv6-only nets. Is such a thing possible? On Thu, Sep 23, 2021, at 1:56 AM, Trey Sis wrote: > There's something wrong with your setup. Did you manually configure an > IPv6 address for your machine? wget shouldn't try the IPv6 address if > there is no route to the destination. > > Cheers, > > Treysis > > On 9/23/2021 10:02, Rick Thomas wrote: >> My ISP does not support IPv6 at all. Recently I have been having trouble >> connecting (web and/or ssh) to hosts outside of my local home LAN that have >> both IPv4 and IPv6 addresses. >> >> For example: >> >> rbthomas@monk:~$ host www.google.com >> www.google.com has address 142.251.33.68 >> www.google.com has IPv6 address 2607:f8b0:400a:806::2004 >> rbthomas@monk:~$ wget www.google.com >> --2021-09-22 18:23:06-- http://www.google.com/ >> Resolving www.google.com (www.google.com)... 2607:f8b0:400a:806::2004, >> 142.251.33.68 >> Connecting to www.google.com >> (www.google.com)|2607:f8b0:400a:806::2004|:80... ^C >> >> >> Is there some way I can tell dnsmasq to give a negative reply to any IPv6 >> query? >> >> I'm using the debian dnsmasq package version 2.85-1 >> >> Thanks! >> Rick >> >> ___ >> 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] [BUG] [PATCH] Segmentation fault in src/forward.c
On 23/09/2021 18:16, Petr Menšík wrote: > I am quite sure also --rebind-domain-ok is broken. It allocates struct > serv_local, but does not set any flags if I saw it correctly. Therefore > it would be later threated as struct server and checked in wrong places. Those structures are kept on a completely separate linked-list which is only touched by domain_no_rebind() which doesn't use the flags field at all, so the code is correct, if possibly confusing. One could define a different structure to eliminate the redundant flags field and make things clearer. A bigger problem is possibly that this doesn't call the IDN infrastructure. Should the send-buffers patch also touch dhcp.c, which also calls sendmsg? I'm not sure about adding code and complexity just to placate valgrind, especially as the code actually initialises all the published members, so the uninitialised data is presumably alignment padding? I'm also not sure about the structure re-arrangement. The code is more complex but how is it better? Cheers, Simon. > > That is still unfixed even after commit > de372d6914ae20a1f9997815f258efbf3b14c39b. > > Made that change separate commit, rebased the previous change with small > changes. > > On 9/23/21 12:28, Simon Kelley wrote: >> >> On 22/09/2021 23:07, Petr Menšík wrote: >>> Good catch. A new bug #2006367 [1] were also reported on Fedora. It >>> seems to point to related structures and memory corruption in them. I >>> have no coredump to check it (yet), so mostly guessing. >>> >>> Juggling with type unsafe structures with few common members is quite >>> bad idea. I think those structures should contain common server_local >>> struct member at the start. They could pass pointer to it on every place >>> which needs working just with those common parts. >>> >>> On domain-match.c:677 is also suspicious memset. Its flags are not >>> directly related to allocated size. I think there might be a case, when >>> it overwrites more memory than allocated for the pointer. On line 696 it >>> may overwrite interface target even with flags SERV_4ADDR | SERV_6ADDR. >>> Both allow rewriting uid member when HAVE_LOOP is set, which is a >>> default. >> SERV_IS_LOCAL is defined at the top of the file, and provides a simple >> check. If that's NOT true then the record is a complete server struct. >> If it is set then it's a struct serv_local, possibly with added IPv4 or >> IPV6 address, controlled by the SERV_4ADDR and SERV_6ADDR flags bits. >> >> /* If the server is USE_RESOLV or LITERAL_ADDRESS, it lives on the >> local_domains chain. */ >> #define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS) >> >> With that information, it's fairly easy to see that the code is correct. >> >> The problem here was nothing to do with this code, the domain search >> code assumed that --server=/example.com/# would not be set along with >> --server=/example.com/#/ and when that was done, it wrongly >> returned BOTH server records, each if which has different lengths. The >> consumer of that set of records assumed (as it was entitled to do) they >> were of the same type and length, hence the dereferencing of fields >> outside allocated memory. >> >>> I see many tricky corners without simple and readable checks >>> ensuring it always does what it should. I think char type enum would >>> definitely not hurt in common structure instead of this juggling with >>> flags. It would be much more clear what members are available. I think >>> default struct should be the smallest one and only retyped to bigger >>> struct, if some flag clearly indicated it is there. Preferred would be >>> separate type member. >> A major goal of this rewrite was to avoid wasting memory when there are >> 100,000 --address=/adserver.com/ lines in the configuration. Doing what >> you suggest would break that. >>> At first it should be fixed by minimal fix. I think constant sized >>> structure with some unused members would be far more safe. I think union >>> would be good candidate here. Its a pity we did not notice those issues >>> before release. I should spend some time on basic automated tests again. >>> I think dnsmasq it small, but needs more regular testing. >>> >> >> Agree entirely. I still have you test system in a git branch, and would >> like to progress it. It would have been nice to find the regression >> (removal) of --address=/#/. before release. >> >> >> Cheers, >> >> Simon. >> >> >> >>> Cheers, >>> >>> Petr >>> >>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2006367 >>> >>> On 9/16/21 16:31, Dominik DL6ER wrote: Addendum: Depending on the configuration, it can happen that the query is sent to another server that is configured to be used for an altogether different domain, e.g. > server=127.0.0.1#5353 > server=::1#5353 > rev-server=192.168.0.1/24,192.168.0.1 > server=/fritz.box/192.168.0.1 > server=/bo.net/# > address=/bo.net/#/ resulting in "A bo.net" being sent to 192.168.0.1 >>>
Re: [Dnsmasq-discuss] config error is REFUSED (EDE: not ready) since v2.86
On Thu, 2021-09-23 at 11:00 +0100, Simon Kelley wrote: > I just pushed a pretty straightforward patch to fix this. Can confirm this fixes it. 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] Upstream servers by host tag (or MAC)
Hi Michael, It works, i've created a docker-compose project with two dnsmasq instance, each one listening on one ethernet alias. I've disabled dchp on the children instance. Thanks for the advice! Hubert. Le 23/09/2021 à 18:43, Michael a écrit : On 9/23/21 04:35, Petr Menšík wrote: Hi Hubert, it may work, if you would run two dnsmasq instances. One for children with OpenDNS as upstream servers, another for everyone else. default instance: bind-interfaces listen-address=10.1.0.1 server=8.8.8.8 domain=home.arpa dhcp-option=option:dns-server,10.1.0.1,8.8.8.8 dhcp-option=tag:child,option:dns-server:10.1.0.2,208.67.222.123 ... children instance: bind-interfaces listen-address=10.1.0.2 server=208.67.222.123 server=/home.arpa/10.1.0.1 Because the second instance would forward local domain to main instance, which also registers dhcp, they should be able to resolve any local names. But other names would be served by different server. Children might have reserved different address range, but it might be handy to be on shared broadcast link. Good for link-local address resolution and easy local games setup. Not sure it is relevant anymore. Not sure if 10.1.0.2 can be on the same interface as 10.1.0.1. It would work fine with just DNS, but I think dhcp requires interface=eth0 or similar. Which would block the second instance from working correctly. I think alternative address would have to be on different interface. I do almost exactly this so I can confirm it works. I have one machine running docker. On that machine, I run two containers with their own IP addresses (macvlan). .1 for the primary including DHCP pointing to my main DNS. Then the .2 version that points to the safe DNS, but relays local name queries (and reverse) over to the .1. Then in config as you highlighted above, I point the child machines to the .2 and everything else to .1. It would be nice if you could use tags to point to different DNS servers, but until that is an option, this works. Michael ___ 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] Upstream servers by host tag (or MAC)
On 23/09/2021 17:43, Michael wrote: > On 9/23/21 04:35, Petr Menšík wrote: >> Hi Hubert, >> >> it may work, if you would run two dnsmasq instances. One for children >> with OpenDNS as upstream servers, another for everyone else. >> >> default instance: >> >> bind-interfaces >> listen-address=10.1.0.1 >> server=8.8.8.8 >> domain=home.arpa >> dhcp-option=option:dns-server,10.1.0.1,8.8.8.8 >> dhcp-option=tag:child,option:dns-server:10.1.0.2,208.67.222.123 >> ... >> >> children instance: >> >> bind-interfaces >> listen-address=10.1.0.2 >> server=208.67.222.123 >> server=/home.arpa/10.1.0.1 >> >> Because the second instance would forward local domain to main instance, >> which also registers dhcp, they should be able to resolve any local >> names. But other names would be served by different server. >> >> Children might have reserved different address range, but it might be >> handy to be on shared broadcast link. Good for link-local address >> resolution and easy local games setup. Not sure it is relevant anymore. >> >> Not sure if 10.1.0.2 can be on the same interface as 10.1.0.1. It would >> work fine with just DNS, but I think dhcp requires interface=eth0 or >> similar. Which would block the second instance from working correctly. I >> think alternative address would have to be on different interface. >> > I do almost exactly this so I can confirm it works. > > > I have one machine running docker. On that machine, I run two > containers with their own IP addresses (macvlan). .1 for the primary > including DHCP pointing to my main DNS. Then the .2 version that > points to the safe DNS, but relays local name queries (and reverse) over > to the .1. > > > Then in config as you highlighted above, I point the child machines to > the .2 and everything else to .1. > > > It would be nice if you could use tags to point to different DNS > servers, but until that is an option, this works. > > Michael I think using different upstream servers based on the requesting client would be a problem because that would mean the same query would get different results. That would appear to be what you would like to see (IIUC), but you then have all sorts of issues with the caches - there would need to be separate caches for separate tag-selected servers, with all the complexity involved in managing that. Since running multiple copies of dnsmasq for DNS can be done on separate IPs (I suggest with only one of them serving DHCP) I would tend to go with that rather than adding multiple-cache complexity. Regards, Geoff. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Geoff Back What if we're all just characters in someone's nightmares? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [BUG] [PATCH] Segmentation fault in src/forward.c
I am quite sure also --rebind-domain-ok is broken. It allocates struct serv_local, but does not set any flags if I saw it correctly. Therefore it would be later threated as struct server and checked in wrong places. That is still unfixed even after commit de372d6914ae20a1f9997815f258efbf3b14c39b. Made that change separate commit, rebased the previous change with small changes. On 9/23/21 12:28, Simon Kelley wrote: > > On 22/09/2021 23:07, Petr Menšík wrote: >> Good catch. A new bug #2006367 [1] were also reported on Fedora. It >> seems to point to related structures and memory corruption in them. I >> have no coredump to check it (yet), so mostly guessing. >> >> Juggling with type unsafe structures with few common members is quite >> bad idea. I think those structures should contain common server_local >> struct member at the start. They could pass pointer to it on every place >> which needs working just with those common parts. >> >> On domain-match.c:677 is also suspicious memset. Its flags are not >> directly related to allocated size. I think there might be a case, when >> it overwrites more memory than allocated for the pointer. On line 696 it >> may overwrite interface target even with flags SERV_4ADDR | SERV_6ADDR. >> Both allow rewriting uid member when HAVE_LOOP is set, which is a >> default. > SERV_IS_LOCAL is defined at the top of the file, and provides a simple > check. If that's NOT true then the record is a complete server struct. > If it is set then it's a struct serv_local, possibly with added IPv4 or > IPV6 address, controlled by the SERV_4ADDR and SERV_6ADDR flags bits. > > /* If the server is USE_RESOLV or LITERAL_ADDRESS, it lives on the > local_domains chain. */ > #define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS) > > With that information, it's fairly easy to see that the code is correct. > > The problem here was nothing to do with this code, the domain search > code assumed that --server=/example.com/# would not be set along with > --server=/example.com/#/ and when that was done, it wrongly > returned BOTH server records, each if which has different lengths. The > consumer of that set of records assumed (as it was entitled to do) they > were of the same type and length, hence the dereferencing of fields > outside allocated memory. > >> I see many tricky corners without simple and readable checks >> ensuring it always does what it should. I think char type enum would >> definitely not hurt in common structure instead of this juggling with >> flags. It would be much more clear what members are available. I think >> default struct should be the smallest one and only retyped to bigger >> struct, if some flag clearly indicated it is there. Preferred would be >> separate type member. > A major goal of this rewrite was to avoid wasting memory when there are > 100,000 --address=/adserver.com/ lines in the configuration. Doing what > you suggest would break that. >> At first it should be fixed by minimal fix. I think constant sized >> structure with some unused members would be far more safe. I think union >> would be good candidate here. Its a pity we did not notice those issues >> before release. I should spend some time on basic automated tests again. >> I think dnsmasq it small, but needs more regular testing. >> > > Agree entirely. I still have you test system in a git branch, and would > like to progress it. It would have been nice to find the regression > (removal) of --address=/#/. before release. > > > Cheers, > > Simon. > > > >> Cheers, >> >> Petr >> >> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2006367 >> >> On 9/16/21 16:31, Dominik DL6ER wrote: >>> Addendum: Depending on the configuration, it can happen that the >>> query is sent to another server that is configured to be used for >>> an altogether different domain, e.g. >>> server=127.0.0.1#5353 server=::1#5353 rev-server=192.168.0.1/24,192.168.0.1 server=/fritz.box/192.168.0.1 server=/bo.net/# address=/bo.net/#/ >>> resulting in "A bo.net" being sent to 192.168.0.1 >>> >>> Something is definitely fishy here. >>> >>> Best, >>> Dominik -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB From f3819fc908d34c7f8bd15be21ec7e96457d26c16 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= Date: Thu, 23 Sep 2021 11:21:59 +0200 Subject: [PATCH 3/3] Separate limited serv_local from full struct server MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make sure distinction from separate serv_local and server structure is obvious. Finish serv_local separation, make serv_addr4 and serv_addr6 have it as a member. Adds more checks into different places, ensuring members used are used only when flags indicate it were allocated. Signed-off-by: Petr Menšík --- src/dnsmasq.h | 24 - src/domain-match.c | 121 ++-
Re: [Dnsmasq-discuss] Upstream servers by host tag (or MAC)
On 9/23/21 04:35, Petr Menšík wrote: Hi Hubert, it may work, if you would run two dnsmasq instances. One for children with OpenDNS as upstream servers, another for everyone else. default instance: bind-interfaces listen-address=10.1.0.1 server=8.8.8.8 domain=home.arpa dhcp-option=option:dns-server,10.1.0.1,8.8.8.8 dhcp-option=tag:child,option:dns-server:10.1.0.2,208.67.222.123 ... children instance: bind-interfaces listen-address=10.1.0.2 server=208.67.222.123 server=/home.arpa/10.1.0.1 Because the second instance would forward local domain to main instance, which also registers dhcp, they should be able to resolve any local names. But other names would be served by different server. Children might have reserved different address range, but it might be handy to be on shared broadcast link. Good for link-local address resolution and easy local games setup. Not sure it is relevant anymore. Not sure if 10.1.0.2 can be on the same interface as 10.1.0.1. It would work fine with just DNS, but I think dhcp requires interface=eth0 or similar. Which would block the second instance from working correctly. I think alternative address would have to be on different interface. I do almost exactly this so I can confirm it works. I have one machine running docker. On that machine, I run two containers with their own IP addresses (macvlan). .1 for the primary including DHCP pointing to my main DNS. Then the .2 version that points to the safe DNS, but relays local name queries (and reverse) over to the .1. Then in config as you highlighted above, I point the child machines to the .2 and everything else to .1. It would be nice if you could use tags to point to different DNS servers, but until that is an option, this works. Michael ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] config error is REFUSED (EDE: not ready) since v2.86
Hi Simon, Thank you for the patch, and the explanation. Best, Jean-Philippe Le 23/09/2021 à 12:00, Simon Kelley a écrit : Apologies all. The --address=/#/.. functionality got omitted in the 2.86 domain-search rewrite, which explains everything. Treating # as a domain name, it doesn't match the test domain, so dnsmasq tries to forward upstream. There are no upstream servers configured, so it returns REFUSED. I just pushed a pretty straightforward patch to fix this. Cheers, Simon. On 22/09/2021 14:50, Jean-Philippe Lambert wrote: Hi Dominik, Thank you for trying. Le 22/09/2021 à 14:05, Dominik Derigs a écrit : Hey Jean-Philippe, The config is different in your two tries, but I guess this is just a typo. Yes. Anyway, I repeated your test on latest master and it is still showing the same as v2.86. Yes, on my side too. Going back, I noticed that v2.85 is the last that still works for me. On Wed, 2021-09-22 at 12:29 +0200, Jean-Philippe Lambert wrote: Is this a bug I guess so and it is likely linked to On Wed, 2021-09-22 at 12:29 +0200, Jean-Philippe Lambert wrote: dnsmasq: warning: no upstream servers configured But I precisely do not want an other server to answer, as I would like to redirect all traffic... I get the same result when adding --local='/#/' $ sudo ./bin/dnsmasq --no-daemon --log-queries=extra --log-debug --listen-address=127.0.0.1 --address='/#/127.0.0.1' --no-hosts --no-resolv --local='/#/' Password: dnsmasq: started, version 2.86 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth no-cryptohash no-DNSSEC loop-detect no-inotify dumpfile dnsmasq: setting --bind-interfaces option because of OS limitations dnsmasq: warning: no upstream servers configured dnsmasq: using only locally-known addresses for # dnsmasq: cleared cache dnsmasq: 1 127.0.0.1/64713 query[A] a.com from 127.0.0.1 dnsmasq: 1 127.0.0.1/64713 config error is REFUSED (EDE: not ready) Best, Jean-Philippe ___ 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] Upstream servers by host tag (or MAC)
Hi Hubert, it may work, if you would run two dnsmasq instances. One for children with OpenDNS as upstream servers, another for everyone else. default instance: bind-interfaces listen-address=10.1.0.1 server=8.8.8.8 domain=home.arpa dhcp-option=option:dns-server,10.1.0.1,8.8.8.8 dhcp-option=tag:child,option:dns-server:10.1.0.2,208.67.222.123 ... children instance: bind-interfaces listen-address=10.1.0.2 server=208.67.222.123 server=/home.arpa/10.1.0.1 Because the second instance would forward local domain to main instance, which also registers dhcp, they should be able to resolve any local names. But other names would be served by different server. Children might have reserved different address range, but it might be handy to be on shared broadcast link. Good for link-local address resolution and easy local games setup. Not sure it is relevant anymore. Not sure if 10.1.0.2 can be on the same interface as 10.1.0.1. It would work fine with just DNS, but I think dhcp requires interface=eth0 or similar. Which would block the second instance from working correctly. I think alternative address would have to be on different interface. Cheers, Petr On 9/21/21 08:32, Hubert FONGARNAND via Dnsmasq-discuss wrote: > Hi, > > Here's my use case : > > Some hosts in my home are for my children (smartphone, tablet...). I want 1) > they access internet > filtered by OpenDNS, 2) they could resolves internal hosts name (example home > printer, nas). > > My idea was to add the possibility to use the "server" directive like that > > |server = tag:child,208.67. 222.123 // OpenDNS family shield for children. > |server = 8.8.8.8 // default upstream for everyone else| > > I know that i can use DHCP for doing > > |dhcp-option=tag:child,option:dns-server,208.67. 222.123| > > But with this solution my childs devices would not be able to resolv internal > hosts (private > domain) which are handled by dnsmasq itself. > > Thanks for your ideas. We can try patches on github ? > > Sincerely, > > Hubert > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [BUG] [PATCH] Segmentation fault in src/forward.c
On 22/09/2021 23:07, Petr Menšík wrote: > Good catch. A new bug #2006367 [1] were also reported on Fedora. It > seems to point to related structures and memory corruption in them. I > have no coredump to check it (yet), so mostly guessing. > > Juggling with type unsafe structures with few common members is quite > bad idea. I think those structures should contain common server_local > struct member at the start. They could pass pointer to it on every place > which needs working just with those common parts. > > On domain-match.c:677 is also suspicious memset. Its flags are not > directly related to allocated size. I think there might be a case, when > it overwrites more memory than allocated for the pointer. On line 696 it > may overwrite interface target even with flags SERV_4ADDR | SERV_6ADDR. > Both allow rewriting uid member when HAVE_LOOP is set, which is a > default. SERV_IS_LOCAL is defined at the top of the file, and provides a simple check. If that's NOT true then the record is a complete server struct. If it is set then it's a struct serv_local, possibly with added IPv4 or IPV6 address, controlled by the SERV_4ADDR and SERV_6ADDR flags bits. /* If the server is USE_RESOLV or LITERAL_ADDRESS, it lives on the local_domains chain. */ #define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS) With that information, it's fairly easy to see that the code is correct. The problem here was nothing to do with this code, the domain search code assumed that --server=/example.com/# would not be set along with --server=/example.com/ and when that was done, it wrongly returned BOTH server records, each if which has different lengths. The consumer of that set of records assumed (as it was entitled to do) they were of the same type and length, hence the dereferencing of fields outside allocated memory. >I see many tricky corners without simple and readable checks > ensuring it always does what it should. I think char type enum would > definitely not hurt in common structure instead of this juggling with > flags. It would be much more clear what members are available. I think > default struct should be the smallest one and only retyped to bigger > struct, if some flag clearly indicated it is there. Preferred would be > separate type member. A major goal of this rewrite was to avoid wasting memory when there are 100,000 --address=/adserver.com/ lines in the configuration. Doing what you suggest would break that. > > At first it should be fixed by minimal fix. I think constant sized > structure with some unused members would be far more safe. I think union > would be good candidate here. Its a pity we did not notice those issues > before release. I should spend some time on basic automated tests again. > I think dnsmasq it small, but needs more regular testing. > Agree entirely. I still have you test system in a git branch, and would like to progress it. It would have been nice to find the regression (removal) of --address=/#/. before release. Cheers, Simon. > Cheers, > > Petr > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=2006367 > > On 9/16/21 16:31, Dominik DL6ER wrote: >> Addendum: Depending on the configuration, it can happen that the >> query is sent to another server that is configured to be used for >> an altogether different domain, e.g. >> >>> server=127.0.0.1#5353 >>> server=::1#5353 >>> rev-server=192.168.0.1/24,192.168.0.1 >>> server=/fritz.box/192.168.0.1 >>> server=/bo.net/# >>> address=/bo.net/#/ >> resulting in "A bo.net" being sent to 192.168.0.1 >> >> Something is definitely fishy here. >> >> Best, >> Dominik >> >> >> ___ >> 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] config error is REFUSED (EDE: not ready) since v2.86
Apologies all. The --address=/#/.. functionality got omitted in the 2.86 domain-search rewrite, which explains everything. Treating # as a domain name, it doesn't match the test domain, so dnsmasq tries to forward upstream. There are no upstream servers configured, so it returns REFUSED. I just pushed a pretty straightforward patch to fix this. Cheers, Simon. On 22/09/2021 14:50, Jean-Philippe Lambert wrote: > Hi Dominik, > > Thank you for trying. > > Le 22/09/2021 à 14:05, Dominik Derigs a écrit : >> Hey Jean-Philippe, >> >> The config is different in your two tries, but I guess this is >> just a typo. > > Yes. > >> >> Anyway, I repeated your test on latest master and it is still >> showing the same as v2.86. >> > > Yes, on my side too. Going back, I noticed that v2.85 is the last that > still works for me. > >> On Wed, 2021-09-22 at 12:29 +0200, Jean-Philippe Lambert wrote: >>> Is this a bug >> >> I guess so and it is likely linked to >> >> On Wed, 2021-09-22 at 12:29 +0200, Jean-Philippe Lambert wrote: >>> dnsmasq: warning: no upstream servers configured >> > > But I precisely do not want an other server to answer, as I would like > to redirect all traffic... I get the same result when adding --local='/#/' > >> $ sudo ./bin/dnsmasq --no-daemon --log-queries=extra --log-debug >> --listen-address=127.0.0.1 --address='/#/127.0.0.1' --no-hosts >> --no-resolv --local='/#/' >> Password: >> dnsmasq: started, version 2.86 cachesize 150 >> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n >> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset auth >> no-cryptohash no-DNSSEC loop-detect no-inotify dumpfile >> dnsmasq: setting --bind-interfaces option because of OS limitations >> dnsmasq: warning: no upstream servers configured >> dnsmasq: using only locally-known addresses for # >> dnsmasq: cleared cache >> dnsmasq: 1 127.0.0.1/64713 query[A] a.com from 127.0.0.1 >> dnsmasq: 1 127.0.0.1/64713 config error is REFUSED (EDE: not ready) > > > > Best, > > Jean-Philippe > > ___ > 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] [PATCH] Correctly warn if dynamic directory is not a directory
Applied. Thanks. Cheers, Simon. On 22/09/2021 14:36, Dominik Derigs wrote: > When users specify a file (instead of a directory) as argument of > hostsdir, dnsmasq will log: > >> dnsmasq: bad dynamic directory hosts: Success > > because stat() didn't fail for this file, however, the test > whether this is a directory failed. > > This patch changes the behavior to log > >> dnsmasq: bad dynamic directory hosts: not a directory > > instead in this case. > > Best, > Dominik > > > ___ > 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] Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query?
There's something wrong with your setup. Did you manually configure an IPv6 address for your machine? wget shouldn't try the IPv6 address if there is no route to the destination. Cheers, Treysis On 9/23/2021 10:02, Rick Thomas wrote: My ISP does not support IPv6 at all. Recently I have been having trouble connecting (web and/or ssh) to hosts outside of my local home LAN that have both IPv4 and IPv6 addresses. For example: rbthomas@monk:~$ host www.google.com www.google.com has address 142.251.33.68 www.google.com has IPv6 address 2607:f8b0:400a:806::2004 rbthomas@monk:~$ wget www.google.com --2021-09-22 18:23:06-- http://www.google.com/ Resolving www.google.com (www.google.com)... 2607:f8b0:400a:806::2004, 142.251.33.68 Connecting to www.google.com (www.google.com)|2607:f8b0:400a:806::2004|:80... ^C Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query? I'm using the debian dnsmasq package version 2.85-1 Thanks! Rick ___ 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] Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query?
My ISP does not support IPv6 at all. Recently I have been having trouble connecting (web and/or ssh) to hosts outside of my local home LAN that have both IPv4 and IPv6 addresses. For example: rbthomas@monk:~$ host www.google.com www.google.com has address 142.251.33.68 www.google.com has IPv6 address 2607:f8b0:400a:806::2004 rbthomas@monk:~$ wget www.google.com --2021-09-22 18:23:06-- http://www.google.com/ Resolving www.google.com (www.google.com)... 2607:f8b0:400a:806::2004, 142.251.33.68 Connecting to www.google.com (www.google.com)|2607:f8b0:400a:806::2004|:80... ^C Is there some way I can tell dnsmasq to give a negative reply to any IPv6 query? I'm using the debian dnsmasq package version 2.85-1 Thanks! Rick ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
