Bug 428067
Summary: | strange behavior of getnameinfo with multiple PTR record | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Leonardo Rodrigues <leolistas> | ||||||||
Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 7 | CC: | tcallawa | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i686 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-04-10 11:19:32 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Leonardo Rodrigues
2008-01-09 00:26:35 UTC
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
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. |