Hello Evan, Hello Tomas.
I reworked IDN support of dig to better support (recent) libidn2.
First motivation was always failing test in tests/system/nslookup.
I think there was many differences and duplicate code when handling
relative_domain+origin with and without IDN. I am not 100% confident,
but I think both IDNA 2003 and IDN 2008 do parse each label separately.
I could not find a reason why would relative textname and origin be
first converted to utf-8, then put together. And as a last step
converted into ACE encoding. There is only single reason I found,
checking of lengths of labels and wire length of domain name. Idnkit
checks that, libidn does not and libidn2 checks that again. However
there is already checking for this in dns_name_fromtext. Because it was
handled in different way, the mentioned test was failing.
Libidn2 since v2.0 supports also punny code decoding. I separated idn
support for input processing and output translation of responses. It
supports libidn2 before 2.0, where punny code will not be decoded.
Supported versions would enable output decoding auto-magically from
configure. Because libidn2 already implements decoding from locale, I
left it to libidn2 and removed iconv calls from dighost.c.
I made input decoding errors fatal to help display relevant error
message from idn library.
Because in master is already support for +idnout option, I removed
support for original environment variable IDN_DISABLED.
I thought there is no reason to implement turning off IDN support for
input names at first. There was a bug in libidn2 fixed only in recently
released 2.0.3 however, which stripped any invalid characters from
domain names. But because in such versions name
"_kerberos.fedoraproject.org." is silently transformed into
"kerberos.fedoraproject.org.", I think +noidnin still has some use
cases, so I added new option. It is now possible to turn off both input
and output IDN handling runtime in dig. nslookup and host will always
use defaults.
Attached patch applies on top of both patches from Tomas. Included are
modified patches that applies cleanly on current master.
Could you please review it?
Thank you in advance!
Dne 28.3.2017 v 10:54 Tomas Hozza napsal(a):
> On 24.09.2015 09:34, Tomas Hozza via RT wrote:
>> On 23.09.2015 19:10, Evan Hunt via RT wrote:
>>>
>>> On Wed, Sep 23, 2015 at 04:10:42PM +0000, Tomas Hozza via RT wrote:
>>>> Works the same way also in the current patch set. However I was
>>>> not able to transfer the root zone. So if you can test this,
>>>> it would be great.
>>>
>>> If you use "dig @f.root-servers.net" it should work, it's configured
>>> to allow transfer for anyone.
>>>
>>> (More detailed response to follow when I have a bit more time.)
>>
>> Thank you for the hint. I retested the code.
>>
>> With libidn:
>> dig @f.root-servers.net axfr . --> there are domains with Unicode characters in the output
>> IDN_DISABLE="" dig @f.root-servers.net axfr . --> there are no domains with Unicode characters, only xn--
>>
>> With libidn2:
>> dig @f.root-servers.net axfr . --> there are no domains with Unicode characters, only xn--
>> IDN_DISABLE="" dig @f.root-servers.net axfr . --> there are no domains with Unicode characters, only xn--
>>
>> As noted before, the behavior with libidn2 is expected, since
>> libidn2 does not support translation from punycode to Unicode.
>>
>> Thanks!
>>
>> Regards,
>>
>
> Hello.
>
> Fedora plans to move to libidn2 and get completely rid of libidn since Fedora 27 (
https://fedoraproject.org/wiki/Changes/IDNA2008).
>
> Rather than carrying another downstream patch in Fedora, we would like to work with you on the inclusion of the functionality into BIND.
>
> Can you please review the last version of patch set we sent to you and let us know in case you need anything from us?
>
> Thank you in advance!
>
> Regards,
>
Regards,
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik@redhat.com PGP: 65C6C973