Re: [Dnsmasq-discuss] How to store CNAME, MX, and other non-A/AAAA records in /etc/hosts?
On Fri, Jul 03, 2020 at 01:16:45PM -0500, Johnny Utahh wrote: > How can dnsmasq store CNAME, MX, and other non-A/ records in /etc/hosts? Not. > I can thus far only see how to store A and records in /etc/hosts (or > alternative 'addn-hosts' file). > > If not in 'addn-hosts' or /etc/hosts, where else? > I'm guessing /etc/dnsmasq.d (?), OK, then try it ... Regards Geert Stappers In an attempt to encourage explorers to discover the world. -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] host(1) queries to AAAA, MX records; making authoritative server
Two related questions: 1. Support non-error host(1) queries to and MX records? Cmdline-session details, with private info (hopefully) redacted: https://gist.githubusercontent.com/johnnyutahh/0f171e47e6ed861f66a1835150a11e4a/raw Short version: a. host(1) against my dnsmasq server == 5(REFUSED) b. host(1) against Cloudflare/GoDaddy == no error Details: Ubuntu 20.04's host(1) by default appears to (I think?) query all 3 of of A, , and MX records. In my simple, dnsmasq-served-by-only-the-A-record-is-in-/etc/hosts-config, host(1) complains about the and MX looks. When asking Cloudflare (with GoDaddy as source/authoritative server), host(1) does not complain. How can I make my dnsmasq server mimic the Cloudflare/GoDaddy response and make host(1) happy? (I'd like my users to not complain after a switchover.) Does Cloudflare/GoDaddy answer with a blank/empty-string and MX record, while dnsmasq simply respond with a "not here"/5(REFUSED) response? What is better/best-practice behavior and why? 2. Make dnsmasq, sans upstream DNS, the authoritative DNS for my domains? The host(1) output from dnsmasq's server shows the reply as non-authoritative, if I'm reading its output correctly. Why would dnsmasq not, by default, claim it's the authoritative server if (in my case) there's no upstream DNS? And how can I make it do so? ~Johnny -- // -- // ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] How to store CNAME, MX, and other non-A/AAAA records in /etc/hosts?
How can dnsmasq store CNAME, MX, and other non-A/ records in /etc/hosts? I can thus far only see how to store A and records in /etc/hosts (or alternative 'addn-hosts' file). If not in 'addn-hosts' or /etc/hosts, where else? I'm guessing /etc/dnsmasq.d (?), and if so, how do I manage the per-domain/per-conf "Includes" (of /etc/dnsmasq.d/* files)? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] host(1) queries to AAAA, MX records; making authoritative server
On 2020-07-03 1:07 PM, Johnny Utahh wrote: Two related questions: 1. Support non-error host(1) queries to and MX records? Cmdline-session details, with private info (hopefully) redacted: https://gist.githubusercontent.com/johnnyutahh/0f171e47e6ed861f66a1835150a11e4a/raw Short version: a. host(1) against my dnsmasq server == 5(REFUSED) b. host(1) against Cloudflare/GoDaddy == no error Details: Ubuntu 20.04's host(1) by default appears to (I think?) query all 3 of of A, , and MX records. In my simple, dnsmasq-served-by-only-the-A-record-is-in-/etc/hosts-config, host(1) complains about the and MX looks. When asking Cloudflare (with GoDaddy as source/authoritative server), host(1) does not complain. How can I make my dnsmasq server mimic the Cloudflare/GoDaddy response and make host(1) happy? (I'd like my users to not complain after a switchover.) Does Cloudflare/GoDaddy answer with a blank/empty-string and MX record, while dnsmasq simply respond with a "not here"/5(REFUSED) response? What is better/best-practice behavior and why? 2. Make dnsmasq, sans upstream DNS, the authoritative DNS for my domains? The host(1) output from dnsmasq's server shows the reply as non-authoritative, if I'm reading its output correctly. Why would dnsmasq not, by default, claim it's the authoritative server if (in my case) there's no upstream DNS? And how can I make it do so? Clarifying: When asking Cloudflare (with GoDaddy as source/authoritative server), host(1) does not complain. ...even when there is no nor MX record. -- // ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Minimal config: small # of A records, no upstream server
On 2020-07-03 12:39 AM, Geert Stappers wrote: On Thu, Jul 02, 2020 at 08:44:02PM -0700, Frank wrote: On Jul 2, 2020, at 7:18 PM, Johnny Utahh wrote: On 2020-07-02 12:57 PM, Geert Stappers wrote: On Thu, Jul 02, 2020 at 06:16:49AM -0500, Johnny Utahh wrote: On 2020-07-02 2:18 AM, Geert Stappers wrote: On Wed, Jul 01, 2020 at 10:06:36PM -0500, Johnny Utahh wrote: Hello, Do I need to make any edits/additions to the dnsmasq.conf below to support the following scenario? Ubuntu 20.04 dnsmasq 2.80 Details: I want to provide a _minimal_ DNS server. It *only* serves a few A records (from /etc/hosts). A key point: I want to make sure it does NOTHING else. No upstream-DNS-server/service connection. Any DNS requests sent to said server outside of the /etc/hosts A-record list will fail. Further: no DHCP, tftp, or any others. All of the other bells and whistles I do not know about: I want them disabled, too. Just plain old proper DNS records serving and associated error-condition handling. Additionally, the dnsmasq-based DNS server will bind/interface/respond-to only `eth8`. /etc/dnsmasq.conf: interface=eth8 no-dhcp-interface=eth8 That is indeed not enough for the desired use case. Thanks, quite good to know. What edits or additions (to the following `/etc/dnsmasq.conf` or any other file) are needed to serve this use case? Something that tells Dnsmasq to do non default things. server=127.0.0.1#13131 The idea is that dnsmasq does go searching for an upstream DNS. That it uses localhost port 13131. With nothing at 13131 should result in a "nothing here" and thus ending the DNS resolve attempt. If that truely gets back to the DNS client as "hostname not found" is unknown to me. In other words: Default behaviour of dnsmasq is to use the DNS available to the host. Original Poster doesn't want that, so should do something extra to prevent. But be aware that I never have travelled that road. Euh yes, I would like to hear how it went. I'm presuming the only issue here is preventing searches and potential "uplinks" with upstream DNS nameservers and that "disabling all other features" is addressed by the following settings: /etc/dnsmasq.conf: port=[myport] no-resolv no-poll interface=eth8 no-dhcp-interface=eth8 no-hosts addn-hosts=/etc/dnsmasq_a_records domain=[mydomain.tld] The idea is that dnsmasq does go searching for an upstream DNS. Okay, copy that, very helpful. It seems dnsmasq is currently determined to hunt for upstream namesevers and there's no elegant way to disable this... but I explore this point more-exhaustively with these points/comments: 1. I'm surprised there's no directive/setting to specifically prevent dnsmasq from searching for an upstream DNS. If so: why is my scenario (seemingly?) rare enough that such a feature (presumably?) was not needed? While this use case is not predominate, this does not seem like an uncommon use case, namely for "isolated VPNs." 2. Does `no-resolv` + `no-poll` effectively implement the feature described in #1? 3. I'm happy to implement `server=127.0.0.1#[unused_port_number]` to effectively provide the feature described in #1. However, I'm concerned about a couple, potential, derivative behaviors: 3.a. How certain are we that this "workaround" completely disables the upstream searching/connections? 3.b. Minor concern: does a continual attempt to connect with a non-served port (especially if it's a UDP request) effectively create some performance degradation over time (particularly if "reconnects" are attempted frequently)? 4. Are there truly, absolutely no other options to prevent upstream-nameserver searches? Does someone besides Geert have any direct experience with or hear of others trying this? 5. If I restrict the interface bindings to a VPN-only ethernet device (that is itself isolated from the public internet), does this help with this "upstream searching restriction"? no-resolv no-poll Assuming the man page is correct, those are the two options you want to prevent DNS from being forwarded. Don’t put a server statement in your config as Geert is suggesting. Acknowledge on that. In any case, I will test this approach and report back what I find. Looking forward to it. Does this (the "no upstream servers configured" log output) provide sufficient evidence for test success (for the above-mentioned use case)? syslog excerpt when running with the following .conf: dnsmasq[x]: warning: no upstream servers configured /etc/dnsmasq.conf: port=[myport] domain-needed bogus-priv no-resolv no-poll interface=[mydev] no-dhcp-interface=[mydev] bind-interfaces no-hosts addn-hosts=/etc/dnsmasq_records domain=[mydomain] Ubuntu 20.04 dnsmasq 2.80 -- // ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.81-3 segmentation fault for no apparent reason
Hey Mikko, there is a quite substantial bug in v2.81 concerning TCP forks which is why v2.82 is already on its way. If you feel comfortable with compiling dnsmasq yourself, then grab the latest source of dnsmasq from here: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary Best, Dominik On Fri, 2020-07-03 at 09:49 +0200, Mikko Laaksonen wrote: > Hello, > > First, my apologies for most likely doing this the wrong way. I could > not find the right way, so I will start here in my quest to find the > right way. > > dnsmasq 2.81-3 on a Fedora 32 with kernel 5.6.19-300.fc32.x86_64 has > made a habit of dying in the middle of the night, for no reason that > I can see. While I am happily asleep, systemd[1]: dnsmasq.service: > Main process exited, code=killed, status=11/SEGV will appear in the > system log, some 5 hours after any previous log entry from dnsmasq. > Downgrading to 2.80 seems to fix this but does not seem to be an > actual fix. Naturally, this does not happen every night. > > What can I do to debug the real cause of the annoyance? > > Thank you > > ___ > 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] dnsmasq 2.81-3 segmentation fault for no apparent reason
Hello, First, my apologies for most likely doing this the wrong way. I could not find the right way, so I will start here in my quest to find the right way. dnsmasq 2.81-3 on a Fedora 32 with kernel 5.6.19-300.fc32.x86_64 has made a habit of dying in the middle of the night, for no reason that I can see. While I am happily asleep, systemd[1]: dnsmasq.service: Main process exited, code=killed, status=11/SEGV will appear in the system log, some 5 hours after any previous log entry from dnsmasq. Downgrading to 2.80 seems to fix this but does not seem to be an actual fix. Naturally, this does not happen every night. What can I do to debug the real cause of the annoyance? Thank you ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Minimal config: small # of A records, no upstream server
On Thu, Jul 02, 2020 at 08:44:02PM -0700, Frank wrote: > On Jul 2, 2020, at 7:18 PM, Johnny Utahh > wrote: > > On 2020-07-02 12:57 PM, Geert Stappers wrote: > >> On Thu, Jul 02, 2020 at 06:16:49AM -0500, Johnny Utahh wrote: > >>> On 2020-07-02 2:18 AM, Geert Stappers wrote: > On Wed, Jul 01, 2020 at 10:06:36PM -0500, Johnny Utahh wrote: > > Hello, > > > > Do I need to make any edits/additions to the dnsmasq.conf below to > > support > > the following scenario? > > > > Ubuntu 20.04 > > dnsmasq 2.80 > > > > Details: > > > > I want to provide a _minimal_ DNS server. It *only* serves a few A > > records > > (from /etc/hosts). > > > > A key point: I want to make sure it does NOTHING else. No > > upstream-DNS-server/service connection. Any DNS requests sent to said > > server > > outside of the /etc/hosts A-record list will fail. Further: no DHCP, > > tftp, > > or any others. All of the other bells and whistles I do not know about: > > I > > want them disabled, too. Just plain old proper DNS records serving and > > associated error-condition handling. > > > > Additionally, the dnsmasq-based DNS server will > > bind/interface/respond-to > > only `eth8`. > > > > > > /etc/dnsmasq.conf: > > interface=eth8 > > no-dhcp-interface=eth8 > > > That is indeed not enough for the desired use case. > > >>> Thanks, quite good to know. What edits or additions (to the following > >>> `/etc/dnsmasq.conf` or any other file) are needed to serve this use case? > >> Something that tells Dnsmasq to do non default things. > >> > >> server=127.0.0.1#13131 > >> > >> The idea is that dnsmasq does go searching for an upstream DNS. That it > >> uses localhost port 13131. With nothing at 13131 should result in > >> a "nothing here" and thus ending the DNS resolve attempt. If that truely > >> gets back to the DNS client as "hostname not found" is unknown to me. > >> > >> In other words: Default behaviour of dnsmasq is to use the DNS available > >> to the host. Original Poster doesn't want that, so should do something > >> extra to prevent. But be aware that I never have travelled that road. > >> Euh yes, I would like to hear how it went. > > > > I'm presuming the only issue here is preventing searches and potential > > "uplinks" with upstream DNS nameservers and that "disabling all > > other features" is addressed by the following settings: > > > > /etc/dnsmasq.conf: > > port=[myport] > > no-resolv > > no-poll > > interface=eth8 > > no-dhcp-interface=eth8 > > no-hosts > > addn-hosts=/etc/dnsmasq_a_records > > domain=[mydomain.tld] > > > >> The idea is that dnsmasq does go searching for an upstream DNS. > > > > Okay, copy that, very helpful. It seems dnsmasq is currently > > determined to hunt for upstream namesevers and there's no elegant > > way to disable this... but I explore this point more-exhaustively > > with these points/comments: > > > > 1. I'm surprised there's no directive/setting to specifically prevent > > dnsmasq from searching for an upstream DNS. If so: why is my scenario > > (seemingly?) rare enough that such a feature (presumably?) was > > not needed? While this use case is not predominate, this does not > > seem like an uncommon use case, namely for "isolated VPNs." > > > > 2. Does `no-resolv` + `no-poll` effectively implement the feature > > described in #1? > > > > 3. I'm happy to implement `server=127.0.0.1#[unused_port_number]` > > to effectively provide the feature described in #1. However, I'm > > concerned about a couple, potential, derivative behaviors: > > > > 3.a. How certain are we that this "workaround" completely disables > > the upstream searching/connections? > > > > 3.b. Minor concern: does a continual attempt to connect with a > > non-served port (especially if it's a UDP request) effectively create > > some performance degradation over time (particularly if "reconnects" > > are attempted frequently)? > > > > 4. Are there truly, absolutely no other options to prevent > > upstream-nameserver searches? Does someone besides Geert have any > > direct experience with or hear of others trying this? > > > > 5. If I restrict the interface bindings to a VPN-only ethernet device > > (that is itself isolated from the public internet), does this help > > with this "upstream searching restriction"? > > > > no-resolv > no-poll > > Assuming the man page is correct, those are the two options you want > to prevent DNS from being forwarded. Don’t put a server statement > in your config as Geert is suggesting. Acknowledge on that. > > In any case, I will test this approach and report back what I find. Looking forward to it. Regards Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list
