This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Just a simple question about consistency and valueability: Why does a link to a huge (54M entries) reversedns database gets removed and a link to a tiny one (800k) is tolerated? isn't it more useful to have both or the bigger one? TheSash 15:17, 31 May 2006 (UTC)
Hello guys, I am the developer for bairestools. I basicly think the same and I would like to know what would be a 0 promotional link. My intention on developing bairestools was the reason you said before, all webpage tools are not payable services, so I think listing them at a free enciclopedia is not accurate.
I would like to be added, as I received good comments on this, and since it's free and will be free forever, I would like you guys support me and let me include it.
Again, apologizes for my poor english and thanks for your time. Paul —The preceding unsigned comment was added by 201.216.206.221 ( talk) 00:38, August 21, 2007 (UTC)
Well most of the links mentioned here are broken and only 2/12 sites in the dmoz directory list provide this functionality. What about adding this ipduh.com/ip/reverse ?
Why is
DNS Lookup Tool with IPv6 and rDNS support regarded as linkspam ?
It doesn't have ads, it's free and has more features than
Reverse DNS Lookup Tool from Open RBL —Preceding
unsigned comment added by
84.195.241.5 (
talk) 23:53, 14 February 2008 (UTC)
Using my own SMTP from a non-registered IP, I got the following results. Gmail doesn't filter the messages at all, assuming your IP is not in their records as a spammer. Yahoo will send the message to the Bulk folder. Hotmail will silently kill the message. This is not to imply a real-world spam filtering effectiveness, though -- my own experiences for example would imply otherwise. Ham Pastrami ( talk) 12:36, 23 February 2008 (UTC)
I hope that an author will take into account that "Reverse DNS" doesn't really exist, and is a misnomer used by those who don't understand DNS. One won't find this term used anywhere in the standards. The draft-ietf-dnsop-reverse-mapping-considerations will likely never be approved as its written by a layman that doesn't understand that "rDNS" doesn't exist. This wikipedia article needs to be rewritten by someone that is not a layman. This article should cite the DNS standards rather than working papers. The documents that are cited are cited incorrectly. bitserve ( talk) 20:00, 21 January 2009 (UTC)
Is it possible for spammers to add fake entries to in-addr.arpa, making the PTR record for their server return "gmail.com" or some valid hostname even if they are not affiliated with google? 24.4.205.24 ( talk) 15:34, 10 April 2009 (UTC)
At which server is the name in-addr.arpa hosted? Or put in another way: if I start an nslookup for some reverse IP address within in-addr.arpa, how is the name resolved? Thanks, -- Abdull ( talk) 22:30, 2 December 2009 (UTC)
Should we not write something about the administration of the space below in-addr.arpa (and its IPV6 equivalent)? Anyone able to contribute? CecilWard ( talk) 11:18, 27 April 2010 (UTC)
Statemens like "having multiple PTR records for the same IP address is generally not recommended" are subjective personal opinion unless citation to a reliable source will be added. Of course, there may be an application with described bug, although currently there is no known commonly used application with such bug. If legitimate (e.g. not buggy) application request's PTR then it probably want to obtain list of canonical names of such IP (for some purpose know to application itself only). As Internet standards documents (RFC 1033, RFC 1912 Section 2.1) specify that Every Internet-reachable host should have a name and that such names match with a reverse pointer record, such application may expect that list will be completed. Violating the requirements may be cause for problems - and in this case - even the application is not buggy. Also argument about packet size should not be overestimated. At the first the application will receive truncated response with as many records as can be delivered with one just packet. If application doesn't want to know all names then all is done. Yes - if application want to know all names, then request needs to be retried using TCP. So application can decide. But if you violate requirements and omit some records, then application can't obtain information even they should be available upon request.
The "multiple PTR records ... are not recommended" needs to be carefully reevaluated. Really. My experience is - buggy application confused by multiple records are rare and even in the case a application triggered such bug it's mostly quickly patched in next version. And size of response is not important issue because application either require the information and should receive it, or has choice to accept partial response or not to ask for unnecessary information at all.
Dan 193.179.199.50 ( talk) 01:20, 24 July 2010 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on Reverse DNS lookup. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 03:59, 12 November 2016 (UTC)
In my opinion, RFC1035 section 3.5 is very vague about rDNS/in-addr.arpa usage, and obviously suffers from from a clear structure the internet might have had back in 1987. And this doesn't get any better with ip6 defined to use the same mechanism.
For example, the questions about how delegation of subnets work was left open. For ip4, attempts to manually resolve addresses using query type NS from roots on (except for a final PTR query) often appear to work, but for ip6, it seems that we often have missing responses (and my guess is, to resolve a full ip6 number to a name, it is required to assume empty response means "query that DNS server again for the next, lower significant part"(!) ). 2A02:8109:323F:E8CA:B817:46B9:1E91:D2D ( talk) 15:43, 22 April 2024 (UTC)
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Just a simple question about consistency and valueability: Why does a link to a huge (54M entries) reversedns database gets removed and a link to a tiny one (800k) is tolerated? isn't it more useful to have both or the bigger one? TheSash 15:17, 31 May 2006 (UTC)
Hello guys, I am the developer for bairestools. I basicly think the same and I would like to know what would be a 0 promotional link. My intention on developing bairestools was the reason you said before, all webpage tools are not payable services, so I think listing them at a free enciclopedia is not accurate.
I would like to be added, as I received good comments on this, and since it's free and will be free forever, I would like you guys support me and let me include it.
Again, apologizes for my poor english and thanks for your time. Paul —The preceding unsigned comment was added by 201.216.206.221 ( talk) 00:38, August 21, 2007 (UTC)
Well most of the links mentioned here are broken and only 2/12 sites in the dmoz directory list provide this functionality. What about adding this ipduh.com/ip/reverse ?
Why is
DNS Lookup Tool with IPv6 and rDNS support regarded as linkspam ?
It doesn't have ads, it's free and has more features than
Reverse DNS Lookup Tool from Open RBL —Preceding
unsigned comment added by
84.195.241.5 (
talk) 23:53, 14 February 2008 (UTC)
Using my own SMTP from a non-registered IP, I got the following results. Gmail doesn't filter the messages at all, assuming your IP is not in their records as a spammer. Yahoo will send the message to the Bulk folder. Hotmail will silently kill the message. This is not to imply a real-world spam filtering effectiveness, though -- my own experiences for example would imply otherwise. Ham Pastrami ( talk) 12:36, 23 February 2008 (UTC)
I hope that an author will take into account that "Reverse DNS" doesn't really exist, and is a misnomer used by those who don't understand DNS. One won't find this term used anywhere in the standards. The draft-ietf-dnsop-reverse-mapping-considerations will likely never be approved as its written by a layman that doesn't understand that "rDNS" doesn't exist. This wikipedia article needs to be rewritten by someone that is not a layman. This article should cite the DNS standards rather than working papers. The documents that are cited are cited incorrectly. bitserve ( talk) 20:00, 21 January 2009 (UTC)
Is it possible for spammers to add fake entries to in-addr.arpa, making the PTR record for their server return "gmail.com" or some valid hostname even if they are not affiliated with google? 24.4.205.24 ( talk) 15:34, 10 April 2009 (UTC)
At which server is the name in-addr.arpa hosted? Or put in another way: if I start an nslookup for some reverse IP address within in-addr.arpa, how is the name resolved? Thanks, -- Abdull ( talk) 22:30, 2 December 2009 (UTC)
Should we not write something about the administration of the space below in-addr.arpa (and its IPV6 equivalent)? Anyone able to contribute? CecilWard ( talk) 11:18, 27 April 2010 (UTC)
Statemens like "having multiple PTR records for the same IP address is generally not recommended" are subjective personal opinion unless citation to a reliable source will be added. Of course, there may be an application with described bug, although currently there is no known commonly used application with such bug. If legitimate (e.g. not buggy) application request's PTR then it probably want to obtain list of canonical names of such IP (for some purpose know to application itself only). As Internet standards documents (RFC 1033, RFC 1912 Section 2.1) specify that Every Internet-reachable host should have a name and that such names match with a reverse pointer record, such application may expect that list will be completed. Violating the requirements may be cause for problems - and in this case - even the application is not buggy. Also argument about packet size should not be overestimated. At the first the application will receive truncated response with as many records as can be delivered with one just packet. If application doesn't want to know all names then all is done. Yes - if application want to know all names, then request needs to be retried using TCP. So application can decide. But if you violate requirements and omit some records, then application can't obtain information even they should be available upon request.
The "multiple PTR records ... are not recommended" needs to be carefully reevaluated. Really. My experience is - buggy application confused by multiple records are rare and even in the case a application triggered such bug it's mostly quickly patched in next version. And size of response is not important issue because application either require the information and should receive it, or has choice to accept partial response or not to ask for unnecessary information at all.
Dan 193.179.199.50 ( talk) 01:20, 24 July 2010 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on Reverse DNS lookup. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 03:59, 12 November 2016 (UTC)
In my opinion, RFC1035 section 3.5 is very vague about rDNS/in-addr.arpa usage, and obviously suffers from from a clear structure the internet might have had back in 1987. And this doesn't get any better with ip6 defined to use the same mechanism.
For example, the questions about how delegation of subnets work was left open. For ip4, attempts to manually resolve addresses using query type NS from roots on (except for a final PTR query) often appear to work, but for ip6, it seems that we often have missing responses (and my guess is, to resolve a full ip6 number to a name, it is required to assume empty response means "query that DNS server again for the next, lower significant part"(!) ). 2A02:8109:323F:E8CA:B817:46B9:1E91:D2D ( talk) 15:43, 22 April 2024 (UTC)