Talk:Reverse DNS lookup

Adding external Link

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)

I didn't notice the other one. Wikipedia not being a link directory, these are not the kinds of links to put in EL sections. Haakon 15:22, 31 May 2006 (UTC)

Somebody did add a couple of obviously commercial links recently, but excising tools like his: [1] degrade this article's utility considerably. I think that WP:not doesn't apply to a few, non-commercial, links. See WP:not#Wikipedia is not a mirror or a repository of links, images, or media files, item 1. MARussellPESE 18:40, 31 May 2006 (UTC)

dnsstuff.com (link) was a usefull free tool. It now appears to be a pay-for service. Upon closer inspection, you can scroll down from the "login / purchase service" top of the page to a small set of dns lookup tools lower on the page. In my opinion, dnsstuff.com should be removed as a link only because it is likely to appear to others as a pay service only. Perhaps a better page could be located to take it's place. 208.20.195.155 16:42, 5 February 2007 (UTC)

The first external link, "FREE Reverse DNS Lookup Tool from BairesTools.com ", strikes me as an advertisement. The link also fails to mention that the site is in Spanish. While it may be a good (albeit common) resource, the link could be more descriptive and less promotional. --209.251.145.252 19:57, 17 August 2007 (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)

should I expect any responses here? —The preceding unsigned comment was added by 201.216.206.221 (talk) 17:44, August 22, 2007 (UTC)

Ideally, there should be more responses. Well, if noone else objects, just add the link. Erik Warmelink 19:52, 24 August 2007 (UTC)

Hell no! I'm not that kind of people :). Anyway, I will wait for some weeks for someone else to write something regarding this matter, and I'll do the english version which was my plan, and then I will re-add the link if nobody objects the contrary. thank you! Paul 201.216.206.221 21:56, 30 August 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 ?

Link spam ?!?

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)

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)

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)

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)

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)

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)

Regarding spam and webmail services

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)

The existence of Reverse DNS

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)

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)

Control of in-addr.arpa and spoofed addresses

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)

• Yes - anyone can fake a PTR address. However they couldn't fake a Forward Confirmed reverse DNS. So if someone created a PTR record of mail.google.com - mail.google.com wouldn't poinr back to the spammer's IP. So if you look up the PTR record and resolve the name returned back to the same IP address, that would be very difficult to spoof. Marcperkel (talk) 17:01, 1 May 2009 (UTC)

Server in-addr.arpa

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)

Exactly as any other domain. This is not a help forum, btw. Kbrose (talk) 22:33, 2 December 2009 (UTC)

Hi Abdul the ISP in control of the ip address block operates the name server that does the reverse mapping, however an ISP may delegate reverse mapping zones to its customers.

Administration

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)

Multiple records

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)

External links modified

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:

• 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 {{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: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:59, 12 November 2016 (UTC)

Mainstream rDNS usage

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)