Red Hat Bugzilla – Bug 101261
getnameinfo fails to to reverse lookup on IPv6 addresses
Last modified: 2016-11-24 10:21:58 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: I have a simple program which uses getaddrinfo and getnameinfo to do reverse DNS lookups. This works for IPv4 addresses, but fails on IPv6 addresses. However, the 'dig -x' and 'nslookup' programs both successfully do the reverse lookup, so I don't believe it's a BIND config issue. I have done a couple of tcp dumps. 1) Here's a dump of a successful lookup of an IPv4 address: ------------------------- 10:29:55.782132 tux.inanna.omnimark.com.32828 > worldtree.inanna.omnimark.com.domain: 23674+ PTR? 10.1.67.10.in-addr.arpa. (41) (DF) 10:29:55.782791 worldtree.inanna.omnimark.com.domain > tux.inanna.omnimark.com.32828: 23674* 1/1/1 PTR[|domain] (DF) -------------------------- 2) Here's a dump of an unsuccessful lookup of an IPv6 address: -------------------------- 10:31:11.583885 tux.inanna.omnimark.com.32828 > worldtree.inanna.omnimark.com.domain: 21794+[|domain] (DF) 10:31:11.584916 worldtree.inanna.omnimark.com.domain > tux.inanna.omnimark.com.32828: 21794 NXDomain[|domain] (DF) 10:31:11.589952 tux.inanna.omnimark.com.32828 > worldtree.inanna.omnimark.com.domain: 21795+[|domain] (DF) 10:31:11.590559 worldtree.inanna.omnimark.com.domain > tux.inanna.omnimark.com.32828: 21795 NXDomain[|domain] (DF) --------------------------- 3) Here's a dump of a successful lookup of the same IPv6 address via the 'dig' program: --------------------------- 10:32:03.617626 tux.inanna.omnimark.com.32828 > worldtree.inanna.omnimark.com.domain: 49243+ PTR? \[xfec00000000000000000000000000005/128][|domain] (DF) 10:32:03.618389 worldtree.inanna.omnimark.com.domain > tux.inanna.omnimark.com.32828: 49243* 1/1/1 (148) (DF) --------------------------- It appears that the getnameinfo call isn't sending the proper query to the DNS server to do the reverse lookup, unless there's a configuration issue somewhere? Version-Release number of selected component (if applicable): glibc-2.3.2-27.9 How reproducible: Always Steps to Reproduce: 1. compile above program 2. use it to do an IPv6 reverse lookup 3. Actual Results: Lookup fails with error 'Name or service not known' Expected Results: The hostname associated with the IPv6 address should be printed. Additional info: #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> #include <string.h> #include <stdio.h> int main (int argc, char **argv) { char buf[NI_MAXHOST]; struct addrinfo *p_Addrs; struct addrinfo Hints; int ret; if (argc < 2) { fprintf (stderr, "Syntax: gethostbyaddr <ip>\n"); return 1; } memset (&Hints, 0, sizeof (Hints)); Hints.ai_family = PF_UNSPEC; Hints.ai_socktype = SOCK_STREAM; ret = getaddrinfo (argv[1], NULL, &Hints, &p_Addrs); if (ret != 0) { fprintf (stderr, "getaddrinfo failed: %s\n", gai_strerror (ret)); freeaddrinfo (p_Addrs); return 1; } ret = getnameinfo (p_Addrs->ai_addr, p_Addrs->ai_addrlen, buf, sizeof (buf), NULL, 0, NI_NAMEREQD); freeaddrinfo (p_Addrs); if (ret != 0) { fprintf (stderr, "getnameinfo failed: %s\n", gai_strerror (ret)); return 1; } printf ("Host name: '%s'\n", buf); return 0; }
I've dug into this further, and managed to track it down. The issue is that glibc generates two sorts of reverse lookup queries for IPv6 addresses: nibble format with ip6.arpa, and nibble format with ip6.int. ip6.int is deprecated, and ip6.arpa is to be used with bitstring format instead of nibble format. Thus, as I'd set up bind9 with bitstring format with ip6.arpa (as now recommended), reverse lookups were failing. Specifically, resolv/nss_dns/dns-host.c in _nss_dns_gethostbyaddr_r needs to use the bitstring format for the first attempt with ip6.arpa, and then fall back to nibble format with ip6.int on failure.
I did look at the RFC and yes, it requires the bitlabel representation. But I failed to find an implementation doing this so far. FreeBSD and NetBSD seem to do exactly what we currently do, namely using the nibble representation. So I assume that the bitlabel representation is either still in the planning phase or has been canceled. What server do you use? Can you share the configuration so that I can reproduce it locally? I haven't set up an IPv6 server myself so far.
Sorry for the delay in response, I've been off for a while on leave. I'm using bind 9.2.1-1.7x.2 on RedHat 7.3, and, if I recall correctly, reproduced with bind 9.2.1-16 on RedHat 9 (as I compiled a debug version of bind so I could step through the resolution code to figure out what was going on). In named.conf, I added 'listen-on-v6 {any;};' to enable IPv6 support. I then added: ------------- zone "\[xfec0000000000000/64].ip6.arpa" IN { type master; file "fec0.zone"; }; ------------- Then fec0.zone is as follows: ------------- $ORIGIN . $TTL 86400 ; 1 day \[xfec0000000000000/64].ip6.arpa IN SOA worldtree.ipv6-inanna.omnimark.com. root.worldtree.ipc6-inanna.omnimark.com. ( 2003101285 ; serial 28800 ; refresh (8 hours) 14400 ; retry (4 hours) 3600 ; expire (1 hour) 3600 ; minimum (1 hour) ) NS worldtree.ipv6-inanna.omnimark.com. $ORIGIN \[xfec0000000000000/64].ip6.arpa. \[x0000000000000001/64] IN PTR worldtree.ipv6-inanna.omnimark.com. ---------------- With this setup, the output of a reverse lookup using 'dig' is: ---------------- [root@worldtree named]# dig -x fec0::1 ; <<>> DiG 9.2.1 <<>> -x fec0::1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47044 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;\[xFEC00000000000000000000000000001/128].ip6.arpa. IN PTR ;; ANSWER SECTION: \[xFEC00000000000000000000000000001/128].ip6.arpa. 86400 IN PTR worldtree.ipv6-inanna.omnimark.com. ;; AUTHORITY SECTION: \[xFEC0000000000000/64].ip6.arpa. 86400 IN NS worldtree.ipv6-inanna.omnimark.com. ;; ADDITIONAL SECTION: worldtree.ipv6-inanna.omnimark.com. 86400 IN AAAA fec0::1 ;; Query time: 3 msec ;; SERVER: 10.67.1.1#53(10.67.1.1) ;; WHEN: Wed Oct 22 11:47:42 2003 ;; MSG SIZE rcvd: 144 -------------- If there's any more info I can provide to assist, just let me know. //Mark
I have checked in a patch to use bitfields in the .ip6.arpa lookup. I can now successfully query the local bind9 I'm running. I expect there will be a glibc version with this patch soon. Once this is done we'll have to wait and see how many people complain since their named is only accepting the nibble format. There seem to be some systems like this since even the host/dig programs in the bind9 distribution can query in this format.
Try the new code in ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.4/ It should fix this problem among several others.
Yes indeed, that does the trick here. Thank you for looking into this; I look forward to seeing the fix released.
Fedora Core 1 and the test release for the next RHL9 errata at ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.4/ contain the changes. Closing the bug now.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-334.html
bitstring format ip6.arpa lookups have been move to experimental status (RFC 3363), and bind 9.2.3 has since revert back to nibble format ip6.arpa and nibble format ip6.int. This is related to bug 111059. Since bitstring format ip6.arpa is not supported, and nibbled format ip6.int is not widely used, maybe reverse lookups are failling. glibc should be updated to reflect the change in both RedHat9 and FC1.
Reopening. Actually, Hong-Gunn is right and glibc should change back to nibble format PTR lookup. And actually, it SHOULD also do an ip6.int query in case the ip6.arpa query fails. Which it currently does not, testing on an up-to-date FC1 system.