Description of problem: Everything started when i was having strange results with DNS reverse restriction functions in postfix configurations. With some tests we found that postfix was receiving 'unknown' from getnameinfo system function and, so, wasnt being able to 'see' reverse addresses. The discussion can be found here: http://marc.info/?l=postfix-users&m=119973018023513&w=2 So .... we found that the problem isnt with postfix, but with getnameinfo function which returned 'unknown' for ip addresses that DO had correctly setup reverse names. With some further testings, i found that getnameinfo behaves strangely with multiple PTR records that has a LOT of records. In my initial problem, as related on the postfix mailing list threaded linked above, the ip address had 258 PTR records. Version-Release number of selected component (if applicable): [root@correio name-addr-test]# rpm -qf /usr/include/netdb.h glibc-headers-2.3.6-3 [root@correio name-addr-test]# How reproducible: in fedora 7 i tried, apparently always i found this problem in a fedora 5 box, but then i did further tests on a fedora 7 box and found it's already buggy. Unfortunelly i have no fedora 8 box to test. Steps to Reproduce: 1. grab getnameinfo.c which cames with postfix sources (auxiliary/name-addr-test/getnameinfo.c) and compile it. This is a simple plain program to invoke getnameinfo and resolve some name/ip address I have attached the getnameinfo.c file to this bug request to make it easier for those who want test it compile it with: gcc getnameinfo.c -o getnameinfo 2. grab the reverse zone i have attached to this bug request, 192.168.1.rev and load it in some bind with zone "1.168.192.in-addr.arpa" IN { type master; file "192.168.1.rev"; }; 3. make sure your /etc/resolv.conf points to the bind you loaded the reverse zone above and run getnameinfo and try to resolve 192.168.1.1 ./getnameinfo 192.168.1.1 Actual results: host line command shows that this IP address has 197 PTR records: [root@firewall named]# host 192.168.1.1 | grep "domain name pointer" | wc -l 197 [root@firewall named]# but getnameinfo shows the ip address has NO PTR record [root@firewall named]# ./getnameinfo 192.168.1.1 getnameinfo 192.168.1.1: Name or service not known [root@firewall named]# Expected results: i would expect to see getnameinfo returning any of the PTR records, not unknown Please note that if you comment the last line (use ;) of this reverse zone file and reload it, getnameinfo WILL work. [root@firewall named]# host 192.168.1.1 | grep "domain name pointer" | wc -l 196 [root@firewall named]# [root@firewall named]# ./getnameinfo 192.168.1.1 Hostname: ptr160.short.com.br Address: 192.168.1.1 [root@firewall named]# Additional info: it seems that this 196 and 197 number is not exact. If i used a larger domain name different than short.com.br, this work/not work number will change. Using a pretty large name (ptrXXX.thisisnotashortdomainname.com.br), the work/not work number changed to 193 and 194. WORKS with 193 records [root@firewall named]# host 192.168.1.1 | grep "domain name pointer" | wc -l 193 [root@firewall named]# [root@firewall named]# ./getnameinfo 192.168.1.1 Hostname: ptr157.thisisnotashortdomainname.com.br Address: 192.168.1.1 [root@firewall named]# does NOT works with 194 records [root@firewall named]# host 192.168.1.1 | grep "domain name pointer" | wc -l 194 [root@firewall named]# [root@firewall named]# ./getnameinfo 192.168.1.1 getnameinfo 192.168.1.1: Name or service not known [root@firewall named]# other interesting situation is that i tried this in VERY old redhat 9 box and getnameinfo.c correctly resolved IP addresses with 400 PTRs ... [root@aparecida named]# cat /etc/redhat-release Red Hat Linux release 9 (Shrike) [root@aparecida named]# [root@aparecida named]# host 192.168.1.1 | grep "domain name pointer" | wc -l 400 [root@aparecida named]# [root@aparecida named]# ./getnameinfo 192.168.1.1 Hostname: ptr396.short.com.br Address: 192.168.1.1 [root@aparecida named]#
Created attachment 291104 [details] source for getnameinfo program which invokes getnameinfo function
Created attachment 291105 [details] reverse dns zone
Forgot to mention that despite the fact it's VERY weird to have hundreds of PTR records for a single IP, it seems that it's completly RFC-legal to do this.
i have found no RFCs that states that multiple PTR records are illegal, but i couldnt find any that states that it IS legal. But i found a draft, which will probably became RFC soon, that states: It is possible for there to be multiple PTRs at a single reverse tree node. In extreme cases, these multiple PTRs could cause a DNS response to exceed the UDP limit, and fall back to TCP or otherwise exceed the DNS protocol limits. Such a case could be one where the advantages of reverse mapping are exceeded by the disadvantages of the additional burden. This may be of particular significance for "mass virtual hosting" systems, where many hostnames are associated with a single IP. http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-05 this draft discusses the questions related to UDP and TCP responses, given the reply size in the case of several PTRs. But it didnt says it's illegal. It just brings some concerns about this situation which appears to be legal until some RFC says it's not.
do anyone read this ????
sorry if i'm being inconvenient .... but i would like somebody to confirm this, if it's really a bug on libraries, a bug on software or something else ...
I pasted a wrong information on the initial bug description .... i have pasted a glibc version from a Fedora 5 box, as i tested this on several machines. From the Fedora 7 box i tried it would be: Version-Release number of selected component (if applicable): [root@firewall ~]# cat /etc/fedora-release Fedora release 7 (Moonshine) [root@firewall ~]# rpm -qf /usr/include/netdb.h glibc-headers-2.6-4 [root@firewall ~]#
I can reproduce this on rawhide.
Some more testing data from rawhide (x86_64): The original numbers no longer seem to hold true. I altered the zone file so that it stops at ptr050.short.com.br., then restarted bind. I then ran the test client code repeatedly: [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr009.short.com.br Address: 192.168.1.1 [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr007.short.com.br Address: 192.168.1.1 [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr005.short.com.br Address: 192.168.1.1 [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr003.short.com.br Address: 192.168.1.1 [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr001.short.com.br Address: 192.168.1.1 [spot@localhost ~]$ ./getnameinfo 192.168.1.1 Hostname: ptr049.short.com.br Address: 192.168.1.1 Note that the results are cycling in a reverse order through the odd numbered items, iterating by 2. It only returns odd results because of the size of the zone set. When I took out the 50th record (now with 49), it starts on ptr008.short.com.br, then performs the same iteration. Not sure if this is expected behavior or not. With 70 entries in the zone, it starts at ptr029.short.com.br and iterates backward by 2. With 73 entries in the zone, it starts at ptr032.short.com.br and iterates backward by 2. With 74 entries, the getnameinfo() call fails. I also wrote a much simpler test case than what was in postfix (what the original poster attached), it shows the same failure set. I'll attach it next.
Created attachment 296020 [details] simpler test case
http://sources.redhat.com/ml/libc-hacker/2008-02/msg00004.html
I have opened this bug directly to glibc people and seems it's really confirmed. The bug is still going there, but here's the link: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5790
The proposed patch seems to have been applied to glibc sources. Check it on the link i posted in comment #12. The bug is now 'FIXED' on glibc bugzilla.