Re: [Dnsmasq-discuss] Bug while using address=//::
apt remove --purge dnsmasq* fixed the issue. Thanks a lot. https://serverfault.com/questions/826872/return-a-records-but-not--records-on-specific-domain-in-bind9/827217#827217 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] Re: 2.86rc1
Thanks!
I were checking it a bit on test build and found part of file
0013-Fix-coverity-issues-detected-in-domain-match.c.patch avoided
application. domain-match.c:447 still has add_resource_record return
value unchecked, unlike A record above.
Btw, return values shadows truncp pointer. If add_resource_record ever
returns 0, truncp would always be set to 1. It seems trunc =
!add_resource_record() || trunc; Would give the same result without
passing it extra time as a pointer. Perhaps it should set { trunc = 1;
break; } on !add_resource_record() and not return 0 as I proposed first.
Attached alternative fix, which works better and were actually tested by:
for F in {1..40}; do echo "--address=/test/127.0.0.$F"; done | xargs
src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries
for F in {1..20}; do echo "--address=/test/::$F"; done | xargs
src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries
Both create truncated responses to test a/ queries. Current state
would not reply on A truncated query at all.
On 9/12/21 00:05, Simon Kelley wrote:
> Applied in 2.87.
>
> Cheers,
>
> Simon.
>
>
>
> On 03/09/2021 22:47, Petr Menšík wrote:
>> Hi Simon,
>>
>> I have prepared a set of patches applied over 2.86rc3 release. They were
>> made to silent some of reports from Coverity scans we do for our
>> packages. I did include reported parts in commit messages, so commit
>> messages are somehow noisy and contain more bytes that the diffs itself.
>>
>> It should add few safety checks on multiple places. Fix few error paths
>> not releasing allocated memory and retries in case of failed syscall. It
>> is not perfect, but should be good enough.
>>
>> Not heavily tested, compiles without issues or warnings and reduced
>> reported issues. Review would be appreciated.
>>
>> What do you think, can they still be merged?
>>
>> Cheers,
>>
>> Petr
>>
>> On 8/25/21 3:46 PM, Simon Kelley wrote:
>>> I just pushed a few final changes, tagged as dnsmasq-2.86rc1.
>>>
>>> I'm fairly confident that this can be released as 2.86 in the near
>>> future, but if you can, please test it now, to avoid disappointment later.
>>>
>>> https://thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.86rc1.tar.gz
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>
>>> ___
>>> 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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From aaa2de3d8f485d50b1b1d9668f4dd1f07b200f22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Fri, 1 Oct 2021 00:41:18 +0200
Subject: [PATCH] Handle truncated responses better
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes both incomplete and incorrect change from commit
02ea41ddd142bb0989abcf19e6c7ee98a9145774. If too many addresses are put
to message, still send a reply. But instead of relying on ignorance via
truncp variable, break the loop on first truncation.
Signed-off-by: Petr Menšík
---
src/domain-match.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/domain-match.c b/src/domain-match.c
index 3f1cc74..990d056 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -420,7 +420,7 @@ size_t make_local_answer(int flags, int gotname, size_t size, struct dns_header
header->ancount = htons(ntohs(header->ancount) + 1);
if (!add_resource_record(header, limit, , sizeof(struct dns_header), , daemon->local_ttl, NULL, T_A, C_IN, "4", ))
- return 0;
+ break;
log_query((flags | F_CONFIG | F_FORWARD) & ~F_IPV6, name, (union all_addr *), NULL, 0);
}
@@ -435,7 +435,8 @@ size_t make_local_answer(int flags, int gotname, size_t size, struct dns_header
addr.addr6 = srv->addr;
header->ancount = htons(ntohs(header->ancount) + 1);
- add_resource_record(header, limit, , sizeof(struct dns_header), , daemon->local_ttl, NULL, T_, C_IN, "6", );
+ if (!add_resource_record(header, limit, , sizeof(struct dns_header), , daemon->local_ttl, NULL, T_, C_IN, "6", ))
+ break;
log_query((flags | F_CONFIG | F_FORWARD) & ~F_IPV4, name, (union all_addr *), NULL, 0);
}
--
2.31.1
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] IDN parameter enablement & domain_len optimization
Hi,
I am submitting patch enabling IDN usage for input parameters. We have
support for IDN, but because locale is not properly initialized, no
parameters using special characters are accepted.
Patch #1 adds domain_len to more places, quite similar to struct server
and struct serv_local. It computes length of saved domain only once and
uses it on various processing. Just small optimization on not critical
bits, since main lookup_domain already uses it. I think it should be
used on more places.
I think we could define someting like struct binstring { char *str, u16
len }; and use it more in code. Pairs of string and its length are
common and handled different way. Because just basic char * is used on
many places, strlen is called again and again, often not required.
Especially might be useful for DHCP binary strings processing.
Patch #2 enables --address=/münchen.de/háčkyčárky.cz/ on input even on
builds without defined LOCALEDIR. Which is missing on Fedora and it
seems IDN support is effectively inactive that way. Adds --auth-zone
support for IDN too.
Patch #3 disables IDN_TRANSITIONAL mode. I wanted to try some refused
IDN name, but transitional mode accepts almost any character. It accepts
also --address=/.test/. I think there is no need to support such
obscure names, but we should accept normal names supported by browsers.
Since I think IDN 2003 support were not properly enabled before, I think
we should start just from IDN 2008 standard.
I think there is still something weird, because --address=/испытание./
is accepted but --address=/испытание/ is not. Improvement anyway.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From f1a6dca099305128ab5304a89748a96932f32256 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Thu, 30 Sep 2021 22:19:45 +0200
Subject: [PATCH 3/4] Disable transitional IDN rules, accept only sane names
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Transitional encoding accepts every emoticon you can think about.
Because setlocale were not enabled before, IDN 2003 input was not
accepted by dnsmasq. It makes no sense therefore to maintain backward
compatibility. Accept only proper encoded unicode names and reject
random unicode characters.
Signed-off-by: Petr Menšík
---
src/util.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/util.c b/src/util.c
index e641905..7bef630 100644
--- a/src/util.c
+++ b/src/util.c
@@ -233,8 +233,6 @@ char *canonicalise(char *in, int *nomem)
{
# ifdef HAVE_LIBIDN2
rc = idn2_to_ascii_lz(in, , IDN2_NONTRANSITIONAL);
- if (rc == IDN2_DISALLOWED)
- rc = idn2_to_ascii_lz(in, , IDN2_TRANSITIONAL);
# else
rc = idna_to_ascii_lz(in, , 0);
# endif
--
2.31.1
From c079c47803029f620c51d16b807d9c48a23c99dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Thu, 30 Sep 2021 22:15:39 +0200
Subject: [PATCH 2/4] Enable locale support for IDN at startup
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
--address=/münchen.de/ is not accepted unless LOCALEDIR is defined on
build. It is not by default. If LIBIDN1 or 2 is defined, call setlocale
to initialize locale required to translate domains to ascii form.
Signed-off-by: Petr Menšík
---
src/dnsmasq.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index c7fa024..cfbbbf1 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -17,6 +17,9 @@
/* Declare static char *compiler_opts in config.h */
#define DNSMASQ_COMPILE_OPTS
+#if defined(HAVE_IDN) || defined(HAVE_LIBIDN2) || defined(LOCALEDIR)
+#include
+#endif
#include "dnsmasq.h"
struct daemon *daemon;
@@ -69,8 +72,10 @@ int main (int argc, char **argv)
int tftp_prefix_missing = 0;
#endif
-#ifdef LOCALEDIR
+#if defined(HAVE_IDN) || defined(HAVE_LIBIDN2) || defined(LOCALEDIR)
setlocale(LC_ALL, "");
+#endif
+#ifdef LOCALEDIR
bindtextdomain("dnsmasq", LOCALEDIR);
textdomain("dnsmasq");
#endif
--
2.31.1
From 31b925efc54161ccee41defa132270d8bac801ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Thu, 30 Sep 2021 17:30:40 +0200
Subject: [PATCH 1/4] Add domain_len to domain parameters in several structures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Similar to serv_local structure, there is multiple structures with
domain stored from configuration. Compute and store domain length in
structure and avoid re-computing it on each use.
Add also IDN support to auth-zone.
Signed-off-by: Petr Menšík
---
src/auth.c| 15 +++
src/dnsmasq.h | 3 +++
src/forward.c | 6 +++---
src/loop.c| 4 ++--
src/network.c | 6 +++---
src/option.c | 15 +--
6 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/src/auth.c b/src/auth.c
Re: [Dnsmasq-discuss] Bug while using address=//::
On 9/30/21 09:42, john doe wrote: > On 9/30/2021 7:17 AM, Geert Stappers via Dnsmasq-discuss wrote: >> On Wed, Sep 29, 2021 at 09:15:15PM -0700, E wrote: IPv6 connectivity >>> >>> Why dnsmasq can't drop , >>> when the server has no IPv6 connectivity at all? >>> This doesn't make sense. I have no connectivity but still would like to know, which servers have public IPv6 addresses and which don't. Connectivity is not directly related to type of queries forwarded. >> >> No sense to those would don't understand what DNS is. >> (DNS is a key value database (which is distributed)) >> >> >>> Something like "no-ipv6" or "ipv4-only" switch >>> would be really nice here... >> >> Nice is how people should behave. >> >> Computers and other tools are blunt, rude, straight down and such. >> >> >> Please understand that querying an record >> is the very same as querying an TXT, MX or A record. >> It doesn't mather if the request travels >> over IPv6 or IPv4. >> > > A '' record is for IPv6 and a 'A' record is for IPv4. Understood. But filtering all records of single type is not usually required and not helping. BIND has moved similar functionality to plugin [1]. But they recommend in its own documentation it should not be used *unless absolutely necessary*. Fetching records is not usually the problem to solve, but some corner cases exists. Partial modification of contents is not considered good practice by DNS community. I think Geert tried to note I can request via IPv4 and it is safe. Likewise I can request A record over IPv6 and there is no problem with that. I would like to know why is fetching records bad on host without IPv6 connectivity. Dominik already pointed to valid cases on IPv6 connected host with limited IPv6 link. Dnsmasq relies on forwarders configured explicitly or read from /etc/resolv.conf. If there is no IPv6 address in resolv.conf, no IPv6 would be used. Isn't that enough? Cheers, Petr 1. https://manpages.debian.org/unstable/bind9/filter-.8.en.html > > -- > John Doe > -- 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 while using address=//::, Configuration regressions
Okay, confirming this works on 2.86 release, but does not with 2.85 or 2.81. I am afraid it could be requested via bugs reported to distribution only. It does not work with root domain /./ on previous versions. It seems --address=/./:: is now equivalent to --address=/#/:: What seems more important, the behaviour of --address changed significantly. --address=/com/:: on 2.85 and lower sends :: for queries and NOERROR without response on A queries. While I like current behaviour more, I think we should revert to previous behaviour to keep systems behaving the same after upgrades and allow new behaviour with modified configuration. --address=/com/#/ now behaves like --address=/com/# behaved before, but no backward compatible version for specified address exists. I think it should be modified to previous mode by default. And a way to make new behaviour possible also with given address. --address=/#/ is accepted, but does nothing. Similar to --server=/ Also --local=/com/:: changed its behaviour. It now behaves like --address=/com/::, not as --server=/com/:: as it should and used to in 2.85. Should we ensure address part is empty perhaps to prevent misusing --local instead of --server? On 9/30/21 06:09, E wrote: >> Which dnsmasq version are you using? > Latest on Debian 11. > > ii dnsmasq 2.85-1 > all Small caching DNS proxy and DHCP/TFTP server > ii dnsmasq-base 2.85-1 > amd64Small caching DNS proxy and DHCP/TFTP server > > >> src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries > --address=/./:: >> This seems to do what you wanted > Is it? Nope. still not blocked at all! > > 1. edit dnsmasq.conf, add "address=/./::" > 2. restart service > 3. > dig .com @127.0.0.1 --- still responds results > dig .com A @127.0.0.1 --- works (returning A results) > > > My question is simple, > a. How can I block certain ranges? > b. Or, How can I block all ? > > ___ > 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] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
> 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers menu items from 2. archive with custom pxe-services. Apologies, there was definitely some mistake. We have applied the patch and tried with and without dhcp-no-override but it still fails to boot. Herein are the pcap and the logs for this case. https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing Additionally, also included is the qemu pcap wherein it does boot successfully. On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > It is somehow hard to guess described results for each configuration (1. > 2. 3.). It is unclear to me, what you saw for each variant printed by the > computer. > > 1. seems to have wrong pcap file or it does not use configuration attached > in linked archive. It seems it offers menu items from 2. archive with > custom pxe-services. > > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) > > Above is not present in config file presented for it, but in 2. Are you > sure you have killed dnsmasq and started it again? > > I think it might be difference between pxe-service served file chosen via > menuboot. I have noticed there are two way to specify file to boot in DHCP > for IPv4. One is in fixed header and first try chosen from menu is in that. > pxe-service options makes it to request direct query to DHCP server, marked > proxyDHCP in wireshark. This proxy ACK is followed by TFTP. > > I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" > > However following DHCP offers boot file path ONLY in option 67 value. > Fixed header boot file is all zeroed. It seems to me this is the part the > snponly.efi firmware does not understand. It does not try to use path in > option, but may insist only on file. Since option #52 overload is not in > packet, I guess dnsmasq should have used mess->file for path and not option > 67. But rules of rfc2131.c:2476 are simple. If client have requested option > 67, it should handle it as option 67. I guess it is bug in snponly.efi. > Either it should not include option 67 between requested options or it > should actually handle the option. Dnsmasq would offer boot path in both > cases. > > Interesting enough, dnsmasq is inconsistent with itself. It behaves a bit > different way in PXE proxy mode, where file header part is always used. In > normal mode unless --dhcp-no-override is used, option is used if requested. > > Can you please try if dhcp-no-override option would fix your issues? I > think it should behave the same way in both situations. > > I attached patch, which would set boot file on pxe-service the same way as > dhcp-boot. It may require dhcp-no-override where it did not before. Could > you please try it? > On 9/28/21 11:54, Shrenik Bhura wrote: > > Hi Petr, > > As per your guidance, we have enabled logging (LOG_ALL in > config/consolle.h) and recompiled the ipxe binaries. Below are the latest > observations. > > Taking down the scenarios from the previous post for ease of reference - > 1. Default dnsmasq config with default ltsp's pxe-service entries - > https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing > 2. Custom pxe-service entries (just to prove that pxe-service and > dhcp-boot do seem to successfully co-exist) - > https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing > 3. Without pxe-service entries - > https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing > > I'll try to summarise the understanding and prevailing ambiguities thus > far to help allot responsibility of multiple things that may be going wrong > here : > > Between scenario (1) and (2), we see that ltsp.ipxe is being served in (2) > which doesn't happen in (1). > In (1), the primary issue is that EFI clients do not receive snponly.efi, > thus they do not advertise option 175 and hence are not sent the ltsp.ipxe. > Since it has not got to the iPXE stage as yet, there are no logs available > from ipxe. All that is visible momentarily on the client side is these two > lines - > > *Station IP address is 192.168.67.134 * > *PXE-E21: Remote boot cancelled.* > Quoting from an explanation herein [1] for "Remote boot cancelled" - > *" This message is also displayed when a DHCP/proxyDHCP server sends a > menu that auto-selects Local Boot and when a bootserver sends a bootstrap > program that returns control to the PXE LoadFile protocol. "* > > In scenario (2), PXE boot menu is displayed as defined in the pxe-service > lines, option 175 is received back from the client, ltsp.ipxe is sent but > is not "downloaded" by the client. There is nothing reported
Re: [Dnsmasq-discuss] Bug while using address=//::
On 9/30/2021 7:17 AM, Geert Stappers via Dnsmasq-discuss wrote: On Wed, Sep 29, 2021 at 09:15:15PM -0700, E wrote: IPv6 connectivity Why dnsmasq can't drop , when the server has no IPv6 connectivity at all? This doesn't make sense. No sense to those would don't understand what DNS is. (DNS is a key value database (which is distributed)) Something like "no-ipv6" or "ipv4-only" switch would be really nice here... Nice is how people should behave. Computers and other tools are blunt, rude, straight down and such. Please understand that querying an record is the very same as querying an TXT, MX or A record. It doesn't mather if the request travels over IPv6 or IPv4. A '' record is for IPv6 and a 'A' record is for IPv4. -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
