Talk:Reverse DNS lookup

message: 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)
replies: text: because you're obviously trying to direct traffic to "Garo's shells Shell accounts for everyone". your user contribution history makes this plainly clear. please stop. wikipedia is not a collection of links, it's not a promotional tool. Anastrophe (talk) 00:07, 15 February 2008 (UTC)
replies: text: If I would add a site to promote it, wouldn't I add a site that contains ads or a site that sells something ?  —Preceding unsigned comment added by 84.195.241.5 (talk) 23:42, 15 February 2008 (UTC)
replies: text: please stop the pretense. you have a conflict of interest in adding the links. the site linked to does not exist for the sole purpose of providing the dns lookup facility. nor, for that matter, is this article intended to be an advice or how-to article. links should be associated with more information about rDNS, not links to sites to help you do them. all one needs do is type a few words into their favorite search engine to find a site that does this. based, again, upon your user contribution history, you are determined to drive traffic to your site. that's reason enough to preclude it.Anastrophe (talk) 01:23, 16 February 2008 (UTC)
replies: text: You are right, the site linked also provides other services, but the same thing can be said about openrbl.org  —Preceding unsigned comment added by 84.195.241.5 (talk) 13:23, 16 February 2008 (UTC)
replies: text: there are differences: the openrbl site doesn't have a huge banner inviting people to investigate their other services, the other services they do provide are all intimately associated with the purpose of the tool they provide, whereas free shell accounts have absolutely nothing to do with reverse dns lookups, and, most importantly, the link was added by an editor in good faith, not by the person who runs the site and is trying to drive traffic to his site by using wikipedia for free advertising. Anastrophe (talk) 19:35, 16 February 2008 (UTC)
thread_title:  Link spam ?!? 

message: 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)
thread_title:  Regarding spam and webmail services 

message: 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)
replies: text: The "reverse" portion of the DNS tree is mentioned in lots of RFCs, including RFC 1033 as reference early in the article.  The referse-mapping I-D is written by well known people in the DNS area of the IETF.  I guess "reverse mapping" may be slightly more correct and popular within the DNS related RFCs, but I don't see the current name seems fine to me.  Wrs1864 (talk) 00:02, 22 January 2009 (UTC)
thread_title:  The existence of Reverse DNS 

message: 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)
thread_title:  Control of in-addr.arpa and spoofed addresses 

message: 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)
thread_title:  Administration 

message: 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)
thread_title:  Multiple records 

message: Hello fellow Wikipedians,
I have just modified  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:
*Added archive https://web.archive.org/web/20061210223820/http://postmaster.aol.com:80/info/rdns.html to http://postmaster.aol.com/info/rdns.html
*Added archive https://web.archive.org/web/20121106162649/http://postmaster.aol.com:80/Postmaster.Errors.php#554rlyb1 to http://postmaster.aol.com/Postmaster.Errors.php#whatisrdns
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 03:59, 12 November 2016 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Mainstream rDNS usage