Talk:Reverse DNS lookup
|WikiProject Computing / Networking||(Rated Start-class, Low-importance)|
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:  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. 126.96.36.199 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. --188.8.131.52 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.
- should I expect any responses here? —The preceding unsigned comment was added by 184.108.40.206 (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 220.127.116.11 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 18.104.22.168 (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)
- 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)
- 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? 22.214.171.124 (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)
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.
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.