Bug 428067 - strange behavior of getnameinfo with multiple PTR record
strange behavior of getnameinfo with multiple PTR record
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
7
i686 Linux
low Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-08 19:26 EST by Leonardo Rodrigues
Modified: 2008-04-10 07:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-10 07:19:32 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)
source for getnameinfo program which invokes getnameinfo function (2.09 KB, text/plain)
2008-01-08 19:26 EST, Leonardo Rodrigues
no flags Details
reverse dns zone (6.71 KB, text/plain)
2008-01-08 19:27 EST, Leonardo Rodrigues
no flags Details
simpler test case (1.12 KB, text/plain)
2008-02-26 22:34 EST, Tom "spot" Callaway
no flags Details

  None (edit)
Description Leonardo Rodrigues 2008-01-08 19:26:35 EST
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]#
Comment 1 Leonardo Rodrigues 2008-01-08 19:26:35 EST
Created attachment 291104 [details]
source for getnameinfo program which invokes getnameinfo function
Comment 2 Leonardo Rodrigues 2008-01-08 19:27:32 EST
Created attachment 291105 [details]
reverse dns zone
Comment 3 Leonardo Rodrigues 2008-01-08 19:31:56 EST
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.

Comment 4 Leonardo Rodrigues 2008-01-09 08:59:04 EST
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.
Comment 5 Leonardo Rodrigues 2008-01-16 16:39:34 EST
do anyone read this ????
Comment 6 Leonardo Rodrigues 2008-01-29 05:42:20 EST
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 ...

Comment 7 Leonardo Rodrigues 2008-02-24 18:35:37 EST
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 ~]# 
Comment 8 Tom "spot" Callaway 2008-02-26 21:25:41 EST
I can reproduce this on rawhide.
Comment 9 Tom "spot" Callaway 2008-02-26 22:34:11 EST
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.
Comment 10 Tom "spot" Callaway 2008-02-26 22:34:55 EST
Created attachment 296020 [details]
simpler test case
Comment 12 Leonardo Rodrigues 2008-02-27 06:10:51 EST
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

Comment 13 Leonardo Rodrigues 2008-03-04 22:07:55 EST
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.

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