[Bug libc/5790] New: strange behavior of getnameinfo on multiple PTR records

["leolistas at solutti dot com dot br" <sourceware-bugzilla at sourceware dot org>]

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.