Bug #7820
closed
2.4: dnsmasq can no longer handle punycode, compile time options change?
0%
Description
I've used dnsmasq with a custom hosts file for years, with mappings including the following:
0.0.0.0 r7---sn-vgqsen7z.c.2mdn.net
0.0.0.0 r7---sn-vgqsenee.c.2mdn.net
Up through 2.3.4, this worked fine. Starting in 2.4, it spews errors for each punycode entry when reading in the file:
dnsmasq76042: bad name at /usr/local/etc/dnsmasq.d/hosts.txt line 28011
I found in the changelog for dnsmasq when punycode support was added way back in dnsmasq 2.51:
Add support for internationalised DNS. Non-ASCII charactersin domain names found in /etc/hosts, /etc/ethers and /etc/dnsmasq.conf will be correctly handled by translation topunycode, as specified in RFC3490. This function is onlyavailable if dnsmasq is compiled with internationalisationsupport, and adds a dependency on GNU libidn.
I noticed two differences between dnsmasq in 2.3.4 and 2.4. 2.3.4 ships with dnsmasq 2.76, and 2.4 ships with 2.77. The second and possibly relevant difference is that the compile time options between the two differ in one regard. 2.76 was compiled with "IDN" and 2.77 was compiled with "IDN2."
I'm guessing that this change has something to do with punycode regressing.
Updated by Paul Tarsus about 8 years ago
Just noticed this change in dnsmasq 2.77, new in 2.4:
Remove historic automatic inclusion of IDN support when building internationalisation support. This doesn't fit now there is a choice of IDN libraries. Be sure to include either -DHAVE_IDN or -DHAVE_LIBIDN2 for IDN support.
Updated by Jim Pingle about 8 years ago
- Status changed from New to Feedback
dnsmasq on 2.4 is compiled with NLS enabled, which in turn sets up a dependency for IDN2 and uses -DHAVE_LIBIDN2. It looks like we're doing everything we're supposed to do.
Is there a way you can try with dnsmasq 2.77 on a different platform (e.g. Linux) to see if it throws the same error?
Updated by Paul Tarsus about 8 years ago
Jim Pingle wrote:
dnsmasq on 2.4 is compiled with NLS enabled, which in turn sets up a dependency for IDN2 and uses -DHAVE_LIBIDN2. It looks like we're doing everything we're supposed to do.
Is there a way you can try with dnsmasq 2.77 on a different platform (e.g. Linux) to see if it throws the same error?
Afraid not
Updated by Kill Bill about 8 years ago
Jim Pingle wrote:
dnsmasq on 2.4 is compiled with NLS enabled
Hmmmm...
# dnsmasq -v Dnsmasq version 2.77 Copyright (c) 2000-2016 Simon Kelley Compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect no-inotify
Updated by Paul Tarsus about 8 years ago
So I take it 2.4 will ship with this regression?
Updated by Jim Pingle about 8 years ago
We are compiling everything the way it should be, there isn't anything for us to change or fix. If you can replicate it on FreeBSD, feel free to raise the bug upstream with the port maintainer or with dnsmasq itself.
Updated by Paul Tarsus almost 8 years ago
Jim Pingle wrote:
We are compiling everything the way it should be, there isn't anything for us to change or fix. If you can replicate it on FreeBSD, feel free to raise the bug upstream with the port maintainer or with dnsmasq itself.
So that's a yes.