Bug 169546 - host and dig should use libidn
host and dig should use libidn
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
Ben Levenson
: FutureFeature
: 232850 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-29 11:17 EDT by Ola Thoresen
Modified: 2013-04-30 19:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-04 09:49:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ola Thoresen 2005-09-29 11:17:58 EDT
Description of problem:
(These binaries are actually part of bind-utils, not bind, but hopefully the bug
will be resolved anyway).
The utilities dig and host should use libidn to translate localized domain names.

Version-Release number of selected component (if applicable):
bind-utils-9.3.1-14

How reproducible:
Always

Steps to Reproduce:
1. Try to resolv a localized domain name with dig or host
  
Actual results:
host øl.no
Host \195\184l.no not found: 3(NXDOMAIN)


Expected results:
xn--l-4ga.no has address 62.70.14.45
xn--l-4ga.no mail is handled by 10 mail4.servetheworld.net.


Additional info:
There is apparently a patch here that should fix this problem:
http://www.nic.ad.jp/ja/idn/mdnkit/download/documents/mdnkit-2.4-doc/en/spec/bind9.html
Comment 1 Jason Vas Dias 2005-09-29 12:01:07 EDT
The idnkit is shipped in the "contrib/" subdirectory of the ISC BIND source
tarball, in the SRPM. It appears the link above contains an updated version
of this.

I will investigate making internationalized domain name (IDN) support 
available in a future bind release.

Since all BIND tools must currently link with modified libraries, and the server
must be patched to provide IDN support, I do not think it is suitable to make
IDN support the default .  Also the BIND server patched with IDN support is 
much less tested than the server without IDN support .

If we enable IDN support in the default release, it should be provided as an 
option that needs to be explicitly enabled, and which when not enabled, has
no effect on the standard server, which is currently not the case - I will 
investigate making this so for a future release.
Comment 2 Ola Thoresen 2005-09-29 14:41:13 EDT
Note that I am not requesting (at least for now) that _bind_ is internationalized.
I am merely requesting that the tools "dig" and "host" should use the idn-format
when "encoding" localized domain names.

So that a "host øl.no" will ask for the domain xn--l-4ga.no (IDN-format), not
\195\184l.no (encoded UTF-8)
Comment 3 Adam Tkac 2007-02-19 08:39:11 EST
Could you look into BIND's source to contrib/idn/idnkit-1.0-src/README file?
This is component of bind and this could solve your problem. I'm against
enabling idn by default because it isn't tested much yet. But if you really want
it you could simply compile your idn tools (see
contrib/idn/idnkit-1.0-src/INSTALL). idn could be enabled after testing in
future releases...
Comment 4 Ola Thoresen 2007-02-19 13:03:23 EST
I am slightly confused by you saying "idn is not much tested yet".
In all of Europe at least idn is in use by all the national registrars, and has
ben so for years now. Also tools such as traceroute supports it out of the box.

$ traceroute øl.no
traceroute to øl.no (83.143.81.86), 30 hops max, 40 byte packets
 1  hades.nytt.no (195.159.132.65)  0.424 ms  0.193 ms  0.146 ms
 2  s33i21.no.powertech.net (195.159.156.105)  5.702 ms  6.812 ms  7.883 ms
(...)

And both Firefox and Thunderbird supports idn, so I can browse and send mail to
national domains.


But still:

$ host øl.no
Host \195\184l.no not found: 3(NXDOMAIN)

And

$ ping øl.no
ping: unknown host øl.no

Whereas

$ idn --quiet øl.no
xn--l-4ga.no

$ host xn--l-4ga.no
xn--l-4ga.no has address 83.143.81.86


Comment 5 Adam Tkac 2007-03-13 14:22:24 EDT
I experimentally enabled idn support in latest bind. Please test it and send me
your impressions :) (http://people.redhat.com/atkac/bind/bind-9.4.0-3.fc7.src.rpm)

Regards, Adam
Comment 6 Ola Thoresen 2007-03-13 15:17:07 EDT
Great.
However, the build fails:

$ rpmbuild --rebuild bind-9.4.0-3.fc7.src.rpm

<snip>

dighost.c:41:24: error: idn/result.h: No such file or directory
dighost.c:42:21: error: idn/log.h: No such file or directory
dighost.c:43:25: error: idn/resconf.h: No such file or directory
dighost.c:44:21: error: idn/api.h: No such file or directory

(...)

Please let me know if you need any more info.
Comment 7 Adam Tkac 2007-03-14 07:12:00 EDT
I've forgot include one directory :) . Could you download improved version,
please? (same link)

-A-
Comment 8 Ola Thoresen 2007-03-14 16:31:01 EDT
Close(r) but still no cigar..

dighost.o: In function `output_filter':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:3472: undefined reference to
`idn_decodename'
dighost.o: In function `setup_lookup':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1775: undefined reference to
`idn_encodename'
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1811: undefined reference to
`idn_encodename'
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1819: undefined reference to
`idn_encodename'
dighost.o: In function `initialize_idn':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:3434: undefined reference to
`idn_nameinit'
collect2: ld returned 1 exit status
make[2]: *** [dig] Error 1
make[2]: *** Waiting for unfinished jobs....
dighost.o: In function `output_filter':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:3472: undefined reference to
`idn_decodename'
dighost.o: In function `setup_lookup':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1775: undefined reference to
`idn_encodename'
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1811: undefined reference to
`idn_encodename'
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:1819: undefined reference to
`idn_encodename'
dighost.o: In function `initialize_idn':
/usr/src/redhat/BUILD/bind-9.4.0/bin/dig/dighost.c:3434: undefined reference to
`idn_nameinit'
collect2: ld returned 1 exit status
make[2]: *** [host] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/bind-9.4.0/bin/dig'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/bind-9.4.0/bin'
make: *** [subdirs] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.96747 (%build)

Rgds.
Comment 9 Adam Tkac 2007-03-22 12:20:32 EDT
*** Bug 232850 has been marked as a duplicate of this bug. ***
Comment 10 Robert Scheck 2007-03-22 17:20:03 EDT
Currently, IDN support at BIND is broken and I don't believe that it's possible 
to use libidn, because this would require modifications to the BIND code, which 
depends on idnkit. Asked otherwise: Why not using the native glibc IDN support 
we're shipping for years now? Setting hints.ai_flags = AI_IDN if getaddrinfo() 
is used would make things easy - but notice, I never had a look to the code of 
host and dig.
Comment 11 Adam Tkac 2007-04-10 13:05:27 EDT
(In reply to comment #10)
I did investigations about your idea but it's quite hard to implement it. idnkit
which is shipped in bind package is very obsolete and I don't want rewrite
configure + Makefiles. I'm going to discuss replacement of idnkit by glibc's idn
with upstream or update idnkit library. But this feature won't be ready in fc7
:(. Go ahead to fc8

Regards, -A-

Comment 12 Adam Tkac 2007-04-16 11:00:19 EDT
I've build new bind-9.4.0-6.fc7 right now. This package could have idn support
but disabled by default because I've started discuss with upstream about better
solutions to support idn than current idnkit's solution. If you want idn, enable
IDN in specfile and rebuild your own bind. You could also download + rebuild
http://people.redhat.com/atkac/bind/bind-9.4.0-6.fc7.src.rpm

Adam
Comment 13 Adam Tkac 2007-06-04 09:49:04 EDT
In the end IDN support has been enabled by default. Avaliable in bind >= 9.4.1-5
(also on http://people.redhat.com/atkac/bind/).

Regards, Adam

Note You need to log in before you can comment on or make changes to this bug.