From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31124 invoked by alias); 25 Feb 2008 14:16:06 -0000 Received: (qmail 30630 invoked by uid 48); 25 Feb 2008 14:15:21 -0000 Date: Mon, 25 Feb 2008 14:16:00 -0000 From: "leolistas at solutti dot com dot br" To: glibc-bugs@sources.redhat.com Message-ID: <20080225141520.5790.leolistas@solutti.com.br> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/5790] New: strange behavior of getnameinfo on multiple PTR records X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00108.txt.bz2 Hi Guys, First of all i really dont have the ability and skills to build and check this which seems to be a bug against CVS glibc. I really would like to, but i cant. I have already filled this to fedora bugzilla system. Fedora devels are very busy because of a major recompile with new GCC packages, so bug had no replies yet. But i got some replies on fedora-devel mailing lists and, because of them, i was asked to direct this bug report direct to glibc people. Fedora bugzilla is here https://bugzilla.redhat.com/show_bug.cgi?id=428067 and contain some important informations i will be reproducing in this bug report here I hope i can provide enough informations which would help you to possibly confirm and, if confirmed, fix this which seems to be a bug to me. Let's go ... Everything started when i got abnormal results with postfix reverse DNS restriction parameters. Wietse, postfix maintener, pointed that postfix wasn't the problem, the problem is that postfix was getting wrong results from system libraries, in this case getnameinfo functions. Wietse asked me to do some testings against getnameinfo function, with a getnameinfo.c simple software provided with postfix sources, and we confirmed that getnameinfo was really behaving strange in some situations where an IP address had LOTS of PTR records. The problem wasnt with multiple PTR records, those worked fine. But when i hit some IP that had multiples and LOTS of PTRs, getnameinfo was behaving strangely (returning unknown when it's supposed to return any of those multiple PTRs). In my case, my mail server hit an ip address with 258 PTRs. The postfix discussion is here: http://marc.info/?l=postfix-users&m=119973018023513&w=2 So, in situations where getnameinfo is called against an ip address with LOTS of PTRs, the function seems to return unknown, when it's supposed to return anyone of those LOTS of PTRs. As i told, i'm not able of providing test results against CVS glibc. But i can test against different versions on different Fedora boxes i have. With Fedora 3, 4, 5, 6 and 8 (dont have 7 to test) the results are the same: getnameinfo returns unknown when it should return something. --> Fedora Core 8 fully updated [root@f8 tmp]# cat /etc/fedora-release Fedora release 8 (Werewolf) [root@f8 tmp]# rpm -qi glibc Name: glibc Version: 2.7 Vendor: Fedora Project Release: 2 Build Date: Thu 18 Oct 2007 06:49:18 AM BRST --> running host and getnameinfo against some ip with multiple (but NOT lots of) PTR records [root@f8 tmp]# host 201.34.255.57 | grep "domain name pointer" | wc -l 11 [root@f8 tmp]# ./getnameinfo 201.34.255.57 Hostname: mail.egiro.com.br Address: 201.34.255.57 [root@f8 tmp]# --> running host and getnameinfo against some ip with multiple and LOTS of PTR records [root@f8 tmp]# host 201.34.255.58 | grep "domain name pointer" | wc -l 258 [root@f8 tmp]# ./getnameinfo 201.34.255.58 getnameinfo 201.34.255.58: Name or service not known [root@f8 tmp]# Despite the fact having 258 PTRs to a single ip address is very weird, it seems to be legal, RFC-speaking. I havent found RFC saying it's illegal, but i found this draft, which sometime will probably become RFC, which says: 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. And at last, the final information .... this, which i believe to be a bug, doesnt happen with the oldest glibc which i still have access, a redhat 9 box: [root@aparecida tmp]# cat /etc/redhat-release Red Hat Linux release 9 (Shrike) [root@aparecida tmp]# rpm -qi glibc Name: glibc Version: 2.3.2 Vendor: Red Hat, Inc. Release: 27.9 Build Date: Mon 07 Apr 2003 08:29:45 PM BRT [root@aparecida tmp]# host 201.34.255.58 | grep "domain name pointer" | wc -l 258 [root@aparecida tmp]# ./getnameinfo 201.34.255.58 Hostname: webmail.alexandreabreu.com Address: 201.34.255.58 [root@aparecida tmp]# [root@aparecida tmp]# host 201.34.255.70 | grep "domain name pointer" | wc -l 387 [root@aparecida tmp]# ./getnameinfo 201.34.255.70 Hostname: www.sobrapgoias.com.br Address: 201.34.255.70 [root@aparecida tmp]# The IP addresses which i used for testing here (201.34.255.58 and .70) are still returning 258 and 387 PTRs at the time i'm writing this bug report. So i believe any of you can easily test this, just calling getnameinfo and pointing those IPs. The getnameinfo.c program, for postfix sources, are attached to the fedora bugzilla i created. It can be simply downloaded from here: https://bugzilla.redhat.com/attachment.cgi?id=291104 -- Summary: strange behavior of getnameinfo on multiple PTR records Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: leolistas at solutti dot com dot br CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=5790 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.