Re: [Dnsmasq-discuss] CNAME trouble with no AAAA
I have no complaints about a new thread. On Sun, Oct 20, 2019, at 6:47 PM, Kurt H Maier wrote: > On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote: > > 2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even > > when the CNAME does point to a host Dnsmasq knows locally. (I assume > > this is the reason for #1.) > > RFC2181 explicitly forbids MX records from being aliases. It's a bad > idea -- best case, it doubles DNS traffic. MX et al fall into > additional section processing, which does not contain CNAME records. > This means a CNAME-only MX record will cause no-address responses. > Which means the client, if it's trying hard enough, will just request a > regular lookup, get the CNAME, resolve that, and hopefully get the MX > record in additional-section along the way. > > Yes, all sorts of DNS server software allows this crap. It's still bad > behavior. MX records should not be CNAMEs. RFC5321 has more > information, including the directive that MX records MUST contain a > domain name with an A or record. > > khm > To be clear, I was referring to a CNAME whose target has an MX record (or TXT record, or probably others). For example, in Dnsmasq terms: cname=myhost.example.com,example.com host-record=example.com,192.168.0.1 mx-host=example.com,mail.example.com host-record=mail.example.com,192.168.0.2 An MX request for myhost.example.com results in NODATA. Admittedly, I'm not 100% sure that this is allowed by the RFCs either, but I didn't see anything indicating it shouldn't be (but it's entirely possible I missed something). ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CNAME trouble with no AAAA
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote: > 2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even > when the CNAME does point to a host Dnsmasq knows locally. (I assume > this is the reason for #1.) RFC2181 explicitly forbids MX records from being aliases. It's a bad idea -- best case, it doubles DNS traffic. MX et al fall into additional section processing, which does not contain CNAME records. This means a CNAME-only MX record will cause no-address responses. Which means the client, if it's trying hard enough, will just request a regular lookup, get the CNAME, resolve that, and hopefully get the MX record in additional-section along the way. Yes, all sorts of DNS server software allows this crap. It's still bad behavior. MX records should not be CNAMEs. RFC5321 has more information, including the directive that MX records MUST contain a domain name with an A or record. khm ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 IAID should be of unsigned type
On Sun, Oct 20, 2019 at 07:19:13PM +0200, Dominik DL6ER wrote: > Dear mailing list, > > The proposed patch ensures that the DHCPv6 IAID is of unsigned type. > This is entirely uncritical, however, as the variable is already now > interpreted and handled as being of unsigned type in > * lease.c:read_leases(), > * helper.c:create_helper(), > * dbus.c:dbus_add_lease(), and > * outpacket.c:put_opt6_long(), > its definition should reflect this to avoid inconsistencies. > > RFC3315 (section 22.4) confirms that the IAID is a 4 bytes long > unsigned integer. > > Best, > Dominik > From 93490e98789bf91d86d46e96c643feea4a08e387 Mon Sep 17 00:00:00 2001 > From: Dominik DL6ER > Date: Sun, 20 Oct 2019 18:51:52 +0200 > Subject: [PATCH] DHCPv6 IAID should be of unsigned type. > It is derived from strtoul() in lease.c:read_leases() and already > now interpreted as unsigned in helper.c:276 and outpacket.c:put_opt6_long(). > RFC3315 (section 22.4) shows that the IAID is 4 > bytes long so we do not need to go up to unsigned long. > To: dnsmasq-discuss > > Signed-off-by: Dominik DL6ER > --- But how long is a int? And that is for which compiler? So where the patch is now someting like `s/int iaid/unsigned int iaid/`, would I like to see something like `s/int iaid/uint32 iaid/`. Because uint32 is always 4 bytes long. Cheers Geert Stappers ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CNAME trouble with no AAAA
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote: > ... but I suspect this isn't intended behavior either, > so it seemed worth mentioning. Is it OK that I start a new thread (with matching Subject) for it? [yes/no] ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] DHCPv6 IAID should be of unsigned type
Dear mailing list,
The proposed patch ensures that the DHCPv6 IAID is of unsigned type.
This is entirely uncritical, however, as the variable is already now
interpreted and handled as being of unsigned type in
* lease.c:read_leases(),
* helper.c:create_helper(),
* dbus.c:dbus_add_lease(), and
* outpacket.c:put_opt6_long(),
its definition should reflect this to avoid inconsistencies.
RFC3315 (section 22.4) confirms that the IAID is a 4 bytes long
unsigned integer.
Best,
Dominik
From 93490e98789bf91d86d46e96c643feea4a08e387 Mon Sep 17 00:00:00 2001
From: Dominik DL6ER
Date: Sun, 20 Oct 2019 18:51:52 +0200
Subject: [PATCH] DHCPv6 IAID should be of unsigned type.
It is derived from strtoul() in lease.c:read_leases() and already
now interpreted as unsigned in helper.c:276 and outpacket.c:put_opt6_long().
RFC3315 (section 22.4) shows that the IAID is 4
bytes long so we do not need to go up to unsigned long.
To: dnsmasq-discuss
Signed-off-by: Dominik DL6ER
---
src/dhcp6.c | 2 +-
src/dnsmasq.h | 11 ++-
src/helper.c | 3 ++-
src/lease.c | 9 ++---
src/rfc3315.c | 4 ++--
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 5badc46..ce682db 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -423,7 +423,7 @@ struct dhcp_config *config_find_by_address6(struct dhcp_config *configs, struct
}
struct dhcp_context *address6_allocate(struct dhcp_context *context, unsigned char *clid, int clid_len, int temp_addr,
- int iaid, int serial, struct dhcp_netid *netids, int plain_range, struct in6_addr *ans)
+ unsigned int iaid, int serial, struct dhcp_netid *netids, int plain_range, struct in6_addr *ans)
{
/* Find a free address: exclude anything in use and anything allocated to
a particular hwaddr/clientid/hostname in our configuration.
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 149739d..9262381 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -721,7 +721,7 @@ struct dhcp_lease {
int new_prefixlen; /* and its prefix length */
#ifdef HAVE_DHCP6
struct in6_addr addr6;
- int iaid;
+ unsigned int iaid;
struct slaac_address {
struct in6_addr addr;
time_t ping_time;
@@ -1393,14 +1393,15 @@ struct dhcp_lease *lease4_allocate(struct in_addr addr);
#ifdef HAVE_DHCP6
struct dhcp_lease *lease6_allocate(struct in6_addr *addrp, int lease_type);
struct dhcp_lease *lease6_find(unsigned char *clid, int clid_len,
- int lease_type, int iaid, struct in6_addr *addr);
+ int lease_type, unsigned int iaid, struct in6_addr *addr);
void lease6_reset(void);
-struct dhcp_lease *lease6_find_by_client(struct dhcp_lease *first, int lease_type, unsigned char *clid, int clid_len, int iaid);
+struct dhcp_lease *lease6_find_by_client(struct dhcp_lease *first, int lease_type,
+ unsigned char *clid, int clid_len, unsigned int iaid);
struct dhcp_lease *lease6_find_by_addr(struct in6_addr *net, int prefix, u64 addr);
u64 lease_find_max_addr6(struct dhcp_context *context);
void lease_ping_reply(struct in6_addr *sender, unsigned char *packet, char *interface);
void lease_update_slaac(time_t now);
-void lease_set_iaid(struct dhcp_lease *lease, int iaid);
+void lease_set_iaid(struct dhcp_lease *lease, unsigned int iaid);
void lease_make_duid(time_t now);
#endif
void lease_set_hwaddr(struct dhcp_lease *lease, const unsigned char *hwaddr,
@@ -1518,7 +1519,7 @@ int get_incoming_mark(union mysockaddr *peer_addr, union all_addr *local_addr,
void dhcp6_init(void);
void dhcp6_packet(time_t now);
struct dhcp_context *address6_allocate(struct dhcp_context *context, unsigned char *clid, int clid_len, int temp_addr,
- int iaid, int serial, struct dhcp_netid *netids, int plain_range, struct in6_addr *ans);
+ unsigned int iaid, int serial, struct dhcp_netid *netids, int plain_range, struct in6_addr *ans);
int config_valid(struct dhcp_config *config, struct dhcp_context *context, struct in6_addr *addr);
struct dhcp_context *address6_available(struct dhcp_context *context,
struct in6_addr *taddr,
diff --git a/src/helper.c b/src/helper.c
index c392eec..62ac9cf 100644
--- a/src/helper.c
+++ b/src/helper.c
@@ -66,7 +66,8 @@ struct script_data
#endif
struct in6_addr addr6;
#ifdef HAVE_DHCP6
- int iaid, vendorclass_count;
+ int vendorclass_count;
+ unsigned int iaid;
#endif
unsigned char hwaddr[DHCP_CHADDR_MAX];
char interface[IF_NAMESIZE];
diff --git a/src/lease.c b/src/lease.c
index f14d128..081d90e 100644
--- a/src/lease.c
+++ b/src/lease.c
@@ -635,7 +635,8 @@ struct dhcp_lease *lease_find_by_addr(struct in_addr addr)
#ifdef HAVE_DHCP6
/* find address for {CLID, IAID, address} */
struct dhcp_lease *lease6_find(unsigned char *clid, int clid_len,
- int lease_type, int iaid, struct in6_addr *addr)
+ int lease_type, unsigned int iaid,
+ struct in6_addr *addr)
{
struct dhcp_lease *lease;
@@ -667,7 +668,9 @@ void lease6_reset(void)
Re: [Dnsmasq-discuss] CNAME trouble with no AAAA
I apologize for continuing the discussion on this. The patch (applied on top of 2.80-1 provided by Debian Buster) completely solved the issues I was having, but I did notice a couple other things. First, locally configured CNAMEs and records other than A or do not seem to play well together. For example, MX and TXT requests still get forwarded upstream, even after the patch. I played around with this a bit and discovered: 1. Unlike "host-record", "txt-record" and "mx-host" on the target are not enough to keep Dnsmasq from ignoring a locally defined CNAME. (I did not try others, like "srv-host".) 2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even when the CNAME does point to a host Dnsmasq knows locally. (I assume this is the reason for #1.) Second, it seems that when Dnsmasq caches a NXDOMAIN response from upstream, it starts giving a NODATA response for other request types on the same name. Strangely, log-queries indicates the requests are forwarded, but right after a SIGHUP to clear the cache, sending one of the NODATA queries results in NXDOMAIN. Neither of these are actually causing problems in my case, but I suspect this isn't intended behavior either, so it seemed worth mentioning. Nick On Sat, Oct 19, 2019, at 12:19 PM, Dominick C. Pastore wrote: > On Sat, Oct 19, 2019, at 6:16 AM, Simon Kelley wrote: > > The restriction still applies. indeed the patch relies on it. > > > > The origin of this is that, for architectural reasons, dnsmasq can only > > supply a reply which originates completely from locally known data, or > > completely from a reply from upstream. Since a local CNAME to a target > > in the public DNS necessarily has both, it's not possible. > > > > What the patch does, is allow a reply consisting only of the CNAME, of > > the target isn't locally defined for the type in question. This would be > > in error if the target was defined for the type in the public DNS, hence > > the condition disallowing that. The second version of the patch only > > does this for a locally defined CNAME, otherwise, you get the situation > > where a CNAME to a A record is cached from upstream, and then a query > > for an record on the CNAME name returns just the CNAME, rather than > > sending it upstream, because the record for the CNAME target it not > > currently cached. > > > > > > > > I ask because in the former case, that could mean Dnsmasq would send a > > > NODATA reply if the target only exists in public DNS, correct? I'm not > > > familiar enough with the intricacies of DNS to know if that would > > > cause a problem for clients. > > > > > > Such a reply could, in theory, cause a client to cache the Nodata status > > of the CNAME target, whereas, if it queried the target directly, it > > would get public data. A cabeat about that should, possibly be added to > > the current disclaimer :( > > > > > > > > Simon. > > Thanks for the detailed explanation. That makes sense and sounds very > reasonable. Thank you for all the help! > > Nick ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I've lost my ability to resolve local machine names without a domain suffix
On Sun, Oct 20, 2019 at 12:25:31PM +0100, Chris Green wrote: > On Sun, Oct 20, 2019 at 12:17:50PM +0200, john doe wrote: > > On 10/20/2019 10:15 AM, Chris Green wrote: > > > On Sun, Oct 20, 2019 at 08:59:03AM +0200, Geert Stappers wrote: > > >> On Sat, Oct 19, 2019 at 10:21:26PM +0100, Chris Green wrote: > > > I don't add any command line options to dnsmasq, my changes to the > > > defaults in /etc/dnsmasq.conf are as follows:- > > > > > > domain-needed > > > bogus-priv > > > expand-hosts > > > domain=zbmc.eu > > > dhcp-range=192.168.1.80,192.168.1.127,12h > > > dhcp-option=3,192.168.1.1 > > > dhcp-authoritative > > > local=/zbmc.eu/ > > > cname=bbb,beaglebone > > > cname=mx201,maxine-X201 > > > cname=ben,DESKTOP-978VD5M > > > cname=oki,MC342-AE529C > > > dhcp-host=00:BB:3A:E9:A3:15,maxineKindle > > > dhcp-host=00:09:B0:C9:CE:81,onkyoTx-nr616 > > > dhcp-host=28:EF:01:2D:EB:07,chrisKindle > > > dhcp-host=08:EB:74:9D:47:53,humaxFreeview > > > dhcp-host=2C:08:8C:CC:9A:9E,humaxYouview > > > dhcp-host=00:1F:E2:4E:8F:CA,maxineStudy > > > dhcp-host=AC:AE:19:2C:3F:5A,roku > > > dhcp-host=10:FE:ED:63:29:74,TL-WA7210 > > > dhcp-host=00:25:36:AE:52:9C,192.168.1.50 > > > > > > So I have a domain= like you. > > > > > >> What happens at _client_ side, actually happens at _client_ side. > > >> > > > Yes, of course, and it seems to be all OK now after restarting > > > everything (but no other changes) so *something* had got out of kilter > > > so that unqualified names weren't working but was fixed by the reboots. > > > It may well be that upgrades (that don't usually require restarts on > > > Linux) had got some systemd bits in a tangle which a restart sorted out. Consider that it is you who doesn't yet understand all the magic that is also known as advanced technology. > > >>> ... and why doesn't a local name only work on the machine running > > >>> dnsmasq? > > >> > > >> Sorry, can't parse that question. If the question was > > >> } ... and why does a local name only work on the machine running dnsmasq? > > >> or > > >>> ... and why doesn't a local name work on the machine running dnsmasq? > > >> say so. Yes, do put effort in asking a question.[1] The footnote text is back > > > Asking for the address of an unqualified name on the machine running > > > dnsmasq fails:- > > > > > > chris@newdns$ host esprimo > > > Host esprimo not found: 3(NXDOMAIN) > > > chris@newdns$ host esprimo.zbmc.eu > > > esprimo.zbmc.eu has address 192.168.1.3 > > > chris@newdns$ > > > > > > Is there any way to fix this? It's not incredibly impoprtant because > > > I only rarely do anything (as in log in and run programs) on that > > > machine but it would be nice if it worked the same as the other > > > machines on the LAN. > > > > > > It's presumably down to the order in which it runs its client DHCP > > > requests versus when dnsmasq starts so that it can answer itself. > > > > > > > You are not using 'dhcp-fqdn' (1)? > > > > 1) http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html > > > No, and reading what it does I can't see any good reason for doing so. Acknowlegde (I can't either see a reason why) > My LAN runs on a single subnet so all systems *must* have unique names > anyway. So time to make a table like | works fine |doesn't work yet --+---+-- hostname | | --+---+-- IP-address| | --+---+-- Item 3| | --+---+-- Item 4| | --+---+-- Item 5| | --+---+-- Item n| | Wishing you a nice discovery tour in your own network. Feel free to share the results. Groeten Geert Stappers Footnote [1] Read http://www.catb.org/~esr/faqs/smart-questions.html to prevent silence as an answer. -- Leven en laten leven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I've lost my ability to resolve local machine names without a domain suffix
On Sun, Oct 20, 2019 at 12:17:50PM +0200, john doe wrote: > On 10/20/2019 10:15 AM, Chris Green wrote: > > On Sun, Oct 20, 2019 at 08:59:03AM +0200, Geert Stappers wrote: > >> On Sat, Oct 19, 2019 at 10:21:26PM +0100, Chris Green wrote: > > I don't add any command line options to dnsmasq, my changes to the > > defaults in /etc/dnsmasq.conf are as follows:- > > > > domain-needed > > bogus-priv > > expand-hosts > > domain=zbmc.eu > > dhcp-range=192.168.1.80,192.168.1.127,12h > > dhcp-option=3,192.168.1.1 > > dhcp-authoritative > > local=/zbmc.eu/ > > cname=bbb,beaglebone > > cname=mx201,maxine-X201 > > cname=ben,DESKTOP-978VD5M > > cname=oki,MC342-AE529C > > dhcp-host=00:BB:3A:E9:A3:15,maxineKindle > > dhcp-host=00:09:B0:C9:CE:81,onkyoTx-nr616 > > dhcp-host=28:EF:01:2D:EB:07,chrisKindle > > dhcp-host=08:EB:74:9D:47:53,humaxFreeview > > dhcp-host=2C:08:8C:CC:9A:9E,humaxYouview > > dhcp-host=00:1F:E2:4E:8F:CA,maxineStudy > > dhcp-host=AC:AE:19:2C:3F:5A,roku > > dhcp-host=10:FE:ED:63:29:74,TL-WA7210 > > dhcp-host=00:25:36:AE:52:9C,192.168.1.50 > > > > So I have a domain= like you. > > > >> What happens at _client_ side, actually happens at _client_ side. > >> > > Yes, of course, and it seems to be all OK now after restarting > > everything (but no other changes) so *something* had got out of kilter > > so that unqualified names weren't working but was fixed by the reboots. > > It may well be that upgrades (that don't usually require restarts on > > Linux) had got some systemd bits in a tangle which a restart sorted out. > > > >> > >>> ... and why doesn't a local name only work on the machine running dnsmasq? > >> > >> Sorry, can't parse that question. If the question was > >> } ... and why does a local name only work on the machine running dnsmasq? > >> or > >>> ... and why doesn't a local name work on the machine running dnsmasq? > >> say so. Yes, do put effort in asking a question.[1] > >> > > Asking for the address of an unqualified name on the machine running > > dnsmasq fails:- > > > > chris@newdns$ host esprimo > > Host esprimo not found: 3(NXDOMAIN) > > chris@newdns$ host esprimo.zbmc.eu > > esprimo.zbmc.eu has address 192.168.1.3 > > chris@newdns$ > > > > Is there any way to fix this? It's not incredibly impoprtant because > > I only rarely do anything (as in log in and run programs) on that > > machine but it would be nice if it worked the same as the other > > machines on the LAN. > > > > It's presumably down to the order in which it runs its client DHCP > > requests versus when dnsmasq starts so that it can answer itself. > > > > You are not using 'dhcp-fqdn' (1)? > > 1) http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html > No, and reading what it does I can't see any good reason for doing so. My LAN runs on a single subnet so all systems *must* have unique names anyway. -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I've lost my ability to resolve local machine names without a domain suffix
On 10/20/2019 10:15 AM, Chris Green wrote: > On Sun, Oct 20, 2019 at 08:59:03AM +0200, Geert Stappers wrote: >> On Sat, Oct 19, 2019 at 10:21:26PM +0100, Chris Green wrote: >>> >>> So why does my laptop have *two* "search zbmc.eu" lines in >>> /etc/resolv.conf whereas other machines only have one? >> >> Yes, your laptop and your other machines in your network. >> > Only my laptop gets *two* "search zbmc.eu" lines, all the other > machines (well, all two of them that are actual accessible computers > running Linux) have only one "search zbmc.eu" which seems more > reasonable. > > >> >>> Also, how does this line get added to /etc/resolv.conf? >> >> Welcome to the wonderful world of the server-client-concept. >> >> The DHCP client does a "DHCP request", DHCP server (Dnsmasq) answers. >> In the reply are >> https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_configuration_parameters >> >> such as code 15 (domain) and code 119 (domain search). >> Client uses the recieved configuration parameters (where it seems fit). >> > OK, yes, I supposed that must be the way it happens. I guess for some > reason my laptop is doing something odd/wrong. In fact I've just had > a thought, it maybe connects using WiFi sometimes and using a wired > connection at other times. It could well be that it sends out a DHCP > broadcast request for both wired and WiFi connections. > > >> Check in the manual page of Dnsmasq the section "--domain". It starts >> with: "Specifies DNS domains for the DHCP server." and contains >> | In addition, when a suffix is set then hostnames without a domain part >> | have the suffix added as an optional domain part. Eg on my network I >> | can set --domain=thekelleys.org.uk and have a machine whose DHCP >> | hostname is "laptop". The IP address for that machine is available >> | from dnsmasq both as "laptop" and "laptop.thekelleys.org.uk". >> That gives some information about _server_ side. >> > I don't add any command line options to dnsmasq, my changes to the > defaults in /etc/dnsmasq.conf are as follows:- > > domain-needed > bogus-priv > expand-hosts > domain=zbmc.eu > dhcp-range=192.168.1.80,192.168.1.127,12h > dhcp-option=3,192.168.1.1 > dhcp-authoritative > local=/zbmc.eu/ > cname=bbb,beaglebone > cname=mx201,maxine-X201 > cname=ben,DESKTOP-978VD5M > cname=oki,MC342-AE529C > dhcp-host=00:BB:3A:E9:A3:15,maxineKindle > dhcp-host=00:09:B0:C9:CE:81,onkyoTx-nr616 > dhcp-host=28:EF:01:2D:EB:07,chrisKindle > dhcp-host=08:EB:74:9D:47:53,humaxFreeview > dhcp-host=2C:08:8C:CC:9A:9E,humaxYouview > dhcp-host=00:1F:E2:4E:8F:CA,maxineStudy > dhcp-host=AC:AE:19:2C:3F:5A,roku > dhcp-host=10:FE:ED:63:29:74,TL-WA7210 > dhcp-host=00:25:36:AE:52:9C,192.168.1.50 > > So I have a domain= like you. > >> What happens at _client_ side, actually happens at _client_ side. >> > Yes, of course, and it seems to be all OK now after restarting > everything (but no other changes) so *something* had got out of kilter > so that unqualified names weren't working but was fixed by the reboots. > It may well be that upgrades (that don't usually require restarts on > Linux) had got some systemd bits in a tangle which a restart sorted out. > >> >>> ... and why doesn't a local name only work on the machine running dnsmasq? >> >> Sorry, can't parse that question. If the question was >> } ... and why does a local name only work on the machine running dnsmasq? >> or >>> ... and why doesn't a local name work on the machine running dnsmasq? >> say so. Yes, do put effort in asking a question.[1] >> > Asking for the address of an unqualified name on the machine running > dnsmasq fails:- > > chris@newdns$ host esprimo > Host esprimo not found: 3(NXDOMAIN) > chris@newdns$ host esprimo.zbmc.eu > esprimo.zbmc.eu has address 192.168.1.3 > chris@newdns$ > > Is there any way to fix this? It's not incredibly impoprtant because > I only rarely do anything (as in log in and run programs) on that > machine but it would be nice if it worked the same as the other > machines on the LAN. > > It's presumably down to the order in which it runs its client DHCP > requests versus when dnsmasq starts so that it can answer itself. > You are not using 'dhcp-fqdn' (1)? 1) http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dns-loop-detect doesn't appear to be working
In digging into the source, it looks like loop detect was purposefully coded to only detect loops on upstream servers and not any servers that are for a specific domain. I'm curious why that is, and would it be acceptable to remove the SERV_HAS_DOMAIN in the relevant sections of *src/loop.c*? Line 33: /* Loop through all upstream servers not for particular domains, and send a query to that server which is identifiable, via the uid. If we see that query back again, then the server is looping, and we should not use it. */ for (serv = daemon->servers; serv; serv = serv->next) if (!(serv->flags & (SERV_LITERAL_ADDRESS | SERV_NO_ADDR | SERV_USE_RESOLV | SERV_NO_REBIND | *SERV_HAS_DOMAIN* | SERV_FOR_NODOTS | SERV_LOOP))) Line 106: for (serv = daemon->servers; serv; serv = serv->next) if (!(serv->flags & (SERV_LITERAL_ADDRESS | SERV_NO_ADDR | SERV_USE_RESOLV | SERV_NO_REBIND | *SERV_HAS_DOMAIN* | SERV_FOR_NODOTS | SERV_LOOP)) && uid == serv->uid) Thanks, Jon On 10/16/2019 10:23 AM, Jonathan Knoll wrote: Hey all, Hopefully I am just misconfiguring something, but when I try to test out the dns-loop-detect feature and configure two instances of dnsmasq to forward to each other a loop is formed but is never stopped. Steps to reproduce: Prerequisites: * Two VM based servers on the same network * Both running dnsmasq as a container using the host network. * Each has a configuration line to forward "my.fun.domain" to the other Procedure: * Run the two containers with the described configuration WITHOUT the dns-loop-detect flag. The following startup logs were observed: dnsmasq[10]: started, version 2.80 cachesize 150 dnsmasq[10]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile dnsmasq[10]: using nameserver #53 for domain my.fun.domain dnsmasq[10]: cleared cache * From one of the servers, query using nslookup: "nslookup some.my.fun.domain 127.0.0.1" * Observe both servers forward to each other repeatedly and immediately reach the connection limit. Truncated logs from one server: dnsmasq[9]: query[A] some.my.fun.domain from 10.19.166.12 dnsmasq[9]: forwarded some.my.fun.domain to 10.19.166.12 parsed: ['query[A]', 'some.my.fun.domain', 'from', '10.19.166.12'] dnsmasq[9]: query[A] some.my.fun.domain from 10.19.166.12 dnsmasq[9]: forwarded some.my.fun.domain to 10.19.166.12 dnsmasq[9]: Maximum number of concurrent DNS queries reached (max: 150) Logs from the other server are identical but instead have the opposite server's IP address. - * Stop the two containers, and run again WITH the dns-loop-detect flag in the configuration The same exact startup logs are observed as before. * Perform the same nslookup query from one of the servers "nslookup some.my.fun.domain 127.0.0.1" * Observe both servers show the exact same behavior as before. The configuration used: ``` no-resolv no-hosts dns-loop-detect server=/my.fun.domain/#53 user=root conf-dir=/etc/dnsmasq.d ``` Any suggestions? Thanks, Jon ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.thekelleys.org.uk_mailman_listinfo_dnsmasq-2Ddiscuss&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=p0-OZ-Makpysak8_95uldC4NnpiabeIz_6fATzQwXi8&m=OMQ4X-iUReOJ_tBBMvbO6bq15DXB4IjyZ45RIEVigt4&s=Rur3NBhXRlZUdF5pLkTrUf2G3izQsaCnIO67kKfLPhU&e= ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Removed a stray o from manual page
--- man/dnsmasq.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/dnsmasq.8 b/man/dnsmasq.8 index 9d5d4d0..85c04a1 100644 --- a/man/dnsmasq.8 +++ b/man/dnsmasq.8 @@ -677,7 +677,7 @@ given for \fB--add-subnet\fP applies to \fB--add-mac\fP too. An alternative enco MAC, as base64, is enabled by adding the "base64" parameter and a human-readable encoding of hex-and-colons is enabled by added the "text" parameter. .TP .B --add-cpe-id= -Add an arbitrary identifying string to o DNS queries which are +Add an arbitrary identifying string to DNS queries which are forwarded upstream. .TP .B --add-subnet[[=[/]][,[/]]] -- 2.1.4 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I've lost my ability to resolve local machine names without a domain suffix
On Sun, Oct 20, 2019 at 08:59:03AM +0200, Geert Stappers wrote: > On Sat, Oct 19, 2019 at 10:21:26PM +0100, Chris Green wrote: > > > > So why does my laptop have *two* "search zbmc.eu" lines in > > /etc/resolv.conf whereas other machines only have one? > > Yes, your laptop and your other machines in your network. > Only my laptop gets *two* "search zbmc.eu" lines, all the other machines (well, all two of them that are actual accessible computers running Linux) have only one "search zbmc.eu" which seems more reasonable. > > > Also, how does this line get added to /etc/resolv.conf? > > Welcome to the wonderful world of the server-client-concept. > > The DHCP client does a "DHCP request", DHCP server (Dnsmasq) answers. > In the reply are > https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_configuration_parameters > > > such as code 15 (domain) and code 119 (domain search). > Client uses the recieved configuration parameters (where it seems fit). > OK, yes, I supposed that must be the way it happens. I guess for some reason my laptop is doing something odd/wrong. In fact I've just had a thought, it maybe connects using WiFi sometimes and using a wired connection at other times. It could well be that it sends out a DHCP broadcast request for both wired and WiFi connections. > Check in the manual page of Dnsmasq the section "--domain". It starts > with: "Specifies DNS domains for the DHCP server." and contains > | In addition, when a suffix is set then hostnames without a domain part > | have the suffix added as an optional domain part. Eg on my network I > | can set --domain=thekelleys.org.uk and have a machine whose DHCP > | hostname is "laptop". The IP address for that machine is available > | from dnsmasq both as "laptop" and "laptop.thekelleys.org.uk". > That gives some information about _server_ side. > I don't add any command line options to dnsmasq, my changes to the defaults in /etc/dnsmasq.conf are as follows:- domain-needed bogus-priv expand-hosts domain=zbmc.eu dhcp-range=192.168.1.80,192.168.1.127,12h dhcp-option=3,192.168.1.1 dhcp-authoritative local=/zbmc.eu/ cname=bbb,beaglebone cname=mx201,maxine-X201 cname=ben,DESKTOP-978VD5M cname=oki,MC342-AE529C dhcp-host=00:BB:3A:E9:A3:15,maxineKindle dhcp-host=00:09:B0:C9:CE:81,onkyoTx-nr616 dhcp-host=28:EF:01:2D:EB:07,chrisKindle dhcp-host=08:EB:74:9D:47:53,humaxFreeview dhcp-host=2C:08:8C:CC:9A:9E,humaxYouview dhcp-host=00:1F:E2:4E:8F:CA,maxineStudy dhcp-host=AC:AE:19:2C:3F:5A,roku dhcp-host=10:FE:ED:63:29:74,TL-WA7210 dhcp-host=00:25:36:AE:52:9C,192.168.1.50 So I have a domain= like you. > What happens at _client_ side, actually happens at _client_ side. > Yes, of course, and it seems to be all OK now after restarting everything (but no other changes) so *something* had got out of kilter so that unqualified names weren't working but was fixed by the reboots. It may well be that upgrades (that don't usually require restarts on Linux) had got some systemd bits in a tangle which a restart sorted out. > > > ... and why doesn't a local name only work on the machine running dnsmasq? > > Sorry, can't parse that question. If the question was > } ... and why does a local name only work on the machine running dnsmasq? > or > > ... and why doesn't a local name work on the machine running dnsmasq? > say so. Yes, do put effort in asking a question.[1] > Asking for the address of an unqualified name on the machine running dnsmasq fails:- chris@newdns$ host esprimo Host esprimo not found: 3(NXDOMAIN) chris@newdns$ host esprimo.zbmc.eu esprimo.zbmc.eu has address 192.168.1.3 chris@newdns$ Is there any way to fix this? It's not incredibly impoprtant because I only rarely do anything (as in log in and run programs) on that machine but it would be nice if it worked the same as the other machines on the LAN. It's presumably down to the order in which it runs its client DHCP requests versus when dnsmasq starts so that it can answer itself. Thanks for all the help so far Geert. -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] I've lost my ability to resolve local machine names without a domain suffix
On Sat, Oct 19, 2019 at 10:21:26PM +0100, Chris Green wrote: > On Sat, Oct 19, 2019 at 10:21:21PM +0200, Geert Stappers wrote: > > On Sat, Oct 19, 2019 at 09:02:19PM +0100, Chris Green wrote: > > > > > > > > > > I've suddenly lost the ability to resolve local machine names without > > > > > a domain suffix, e.g.:- > > > > > > > > > > chris$ host t470 > > > > > Host t470 not found: 2(SERVFAIL) > > > > > chris$ host t470.zbmc.eu > > > > > t470.zbmc.eu has address 192.168.1.92 > > > > > chris$ > > > > > > > > > > > > > > > > Strangely I seem to be able to resolve local names without a suffix > > > now. I have rebooted a few machines, maybe something simply got > > > full/misconfigured and a reboot has cleared it up. > > > > OK > > > I'm still a bit worried by all this as everything seemed to be working > well for many months and years and now it's all a bit hit and miss. > > On the Raspberry Pi I can't resolve names without a domain:- > > chris@newdns$ grep -e search -e domain /etc/resolv.conf > chris@newdns$ host esprimo > Host esprimo not found: 3(NXDOMAIN) > chris@newdns$ host esprimo.zbmc.eu > esprimo.zbmc.eu has address 192.168.1.3 > chris@newdns$ > > > On my laptop, running xubuntu 19.04 I see:- > > chris$ grep -e search -e domain /etc/resolv.conf > search zbmc.eu > search zbmc.eu > chris$ more /etc/resolv.conf > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) > # 127.0.0.53 is the systemd-resolved stub resolver. > # run "systemd-resolve --status" to see details about the actual > nameservers. > > search zbmc.eu > nameserver 127.0.0.53 > search zbmc.eu > chris$ host esprimo > esprimo.zbmc.eu has address 192.168.1.3 > > > On my desktop machine (also running xubuntu 19.04) :- > > chris@esprimo$ grep -e search -e domain /etc/resolv.conf > search zbmc.eu > chris@esprimo$ more /etc/resolv.conf > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) > # 127.0.0.53 is the systemd-resolved stub resolver. > # run "systemd-resolve --status" to see details about the actual > nameservers. > > nameserver 127.0.0.53 > search zbmc.eu > chris@esprimo$ > > Other machines (running xubuntu 18.04) look similar to the desktop > machine. > > > So why does my laptop have *two* "search zbmc.eu" lines in > /etc/resolv.conf whereas other machines only have one? Yes, your laptop and your other machines in your network. > Also, how does this line get added to /etc/resolv.conf? Welcome to the wonderful world of the server-client-concept. The DHCP client does a "DHCP request", DHCP server (Dnsmasq) answers. In the reply are https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_configuration_parameters such as code 15 (domain) and code 119 (domain search). Client uses the recieved configuration parameters (where it seems fit). Check in the manual page of Dnsmasq the section "--domain". It starts with: "Specifies DNS domains for the DHCP server." and contains | In addition, when a suffix is set then hostnames without a domain part | have the suffix added as an optional domain part. Eg on my network I | can set --domain=thekelleys.org.uk and have a machine whose DHCP | hostname is "laptop". The IP address for that machine is available | from dnsmasq both as "laptop" and "laptop.thekelleys.org.uk". That gives some information about _server_ side. What happens at _client_ side, actually happens at _client_ side. > ... and why doesn't a local name only work on the machine running dnsmasq? Sorry, can't parse that question. If the question was } ... and why does a local name only work on the machine running dnsmasq? or > ... and why doesn't a local name work on the machine running dnsmasq? say so. Yes, do put effort in asking a question.[1] Groeten Geert Stappers Footnote [1] Read http://www.catb.org/~esr/faqs/smart-questions.html to prevent silence as an answer. -- Leven en laten leven signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
