Content-Transfer-Encoding: quoted-printable X-RT-Original-Encoding: utf-8 content-type: text/plain; charset="utf-8" Content-Length: 3982 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