[CALUG] CALUG Digest, Vol 47, Issue 10, help with DNS PTR record

[Duane Tucker]

Thanks to everyone who responded with advice and offers to help! 
Unfortunately I just got home from work and have to leave in an hour for 
class. Same tomorrow night. Wednesday I should be able to work on this 
some more and I'll have time to carefully review comments and reply 
individually.

It looks like a couple of folks have suggested that my PTR record needs 
to be set by my ISP. I neglected in my original post to say that tech 
support at godaddy said the same thing. But because my ISP (GTB) has 
been such a pain to deal with, I was hoping I could fix this myself, 
possibly by hosting my own DNS server. At any rate, however, I thank you 
all again for your help and look forward to applying myself Wednesday to 
the suggestions.

Sincerely,
Duane Tucker


On 11/29/10 12:00 PM, calug-request at unknownlamer.org wrote:
> Send CALUG mailing list submissions to
> 	calug at unknownlamer.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.unknownlamer.org/listinfo/calug
> or, via email, send a message with subject or body 'help' to
> 	calug-request at unknownlamer.org
>
> You can reach the person managing the list at
> 	calug-owner at unknownlamer.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CALUG digest..."
>
>
> Today's Topics:
>
>     1. help with dns reverse PTR record problem (Duane Tucker)
>     2. Re: help with dns reverse PTR record problem (Daniel Deighton)
>     3. Re: help with dns reverse PTR record problem (Jim Bauer)
>     4. Inventory programs (Gavin H. Watson)
>     5. Zenoss;Open Source Monitoring  December 6th (Kristianova Martina)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Nov 2010 21:08:18 -0500
> From: Duane Tucker<duane_tucker at verizon.net>
> Subject: [CALUG] help with dns reverse PTR record problem
> To: calug at unknownlamer.org
> Message-ID:<4CF30B12.20407 at verizon.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Hi all,
>
> I'm looking for someone who would be willing to help me with a DNS
> problem. I'm willing to pay for your time.
>
> Background: I administer the network and servers for a small company. I
> have a linux server running postfix for outgoing smtp email. The domain
> is registered with godaddy and I use the godaddy DNS Manager tool for
> dns control.
>
> The problem is this: when someone inside the network attempts to email
> anyone at a comcast.net address,  Comcast rejects the emails with the
> following message:
>
> Nov 28 20:18:17 mailserver postfix/smtp[10207]: 4F0E36FD08:
> to=<teset at comcast.net>, relay=mx1b.comcast.net[76.96.62.116]:25,
> delay=19637, delays=19636/0.08/1/0, dsn=4.0.0, status=deferred (host
> mx1b.comcast.net[76.96.62.116] refused to talk to me: 554
> imta04.westchester.pa.mail.comcast.net comcast 69.85.36.83 Comcast
> requires that all mail servers must have a PTR record with a valid
> Reverse DNS entry. Currently your mail server does not fill that
> requirement. For more information, refer to:
> http://help.comcast.net/content/faq/PTR)
>
>
> Comcast is the ONLY domain in almost 2 years that we have this problem
> with. Luckily, we almost never need to email anyone with a Comcast
> address. This problem has reared its ugly head only 3 or 4 times. It
> drives me nuts, however, that I can't figure out how to fix the problem.
> This weekend I even stumbled through setting up my own DNS server, using
> bind, but then couldn't figure out how to implement it. The reason for
> my confusion here is that in the godaddy dns manager, it requires me to
> enter a FQDN for the name servers, not an IP address. Well, if the
> purpose of the DNS server is to resolve names, and the DNS server is
> running within the same domain that your trying to resolve, how in the
> world would it ever get there for resolution?!?
>
> Now you would think that the answer would be easy. Since I'm managing
> dns entries with the godaddy dns manager, why not just put a reverse PTR
> record there? But no, that's just too easy. Godaddy doesn't allow you to
> enter PTR records. They do have some perverted way to enter TXT records
> with a PTR embedded, but I can't figure that out either. When I called
> godaddy tech support, they politely informed me that since I don't use
> their hosts, they can't provide support for the dns entries. Sigh. By
> the way, here is a link to a godaddy support page discussing the
> TXT/PTR/SPF "thing".
>
> http://community.godaddy.com/help/article/680
>
> So if anyone reading this thinks they can help, please do let me know.
> I'm tired of spending weekends now and then chasing my tail. I know just
> enough about all this to be dangerous. The answer could be just one
> small step away and I simply can't see it.
>
> Many thanks,
> Duane Tucker
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 29 Nov 2010 06:50:43 -0500
> From: Daniel Deighton<ddeighton at aplura.com>
> Subject: Re: [CALUG] help with dns reverse PTR record problem
> To: calug at unknownlamer.org
> Message-ID:<1291031443.15407.149.camel at namu.deightime.net>
> Content-Type: text/plain; charset="UTF-8"
>
> Duane,
>
> Requiring the PTR record to match the A record is an often-used
> technique to reduce SPAM. You will likely run into it again, so it is
> best to correct the problem as soon as possible.
>
> With godaddy, you are controlling the records for your domain (i.e.
> example.com). As you know, you can set any record you like for
> example.com. These are the forward lookups to translate from name to IP
> address.
>
> The problem is that you need to enter records for the reverse lookups or
> in-addr.arpa domain. These records resolve IP addresses back to names.
> You don't control these records. Since you aren't using godaddy hosts,
> they don't control these records either -- as you found out, they won't
> be able to help you. You will need to contact your ISP for help in
> setting the PTR record.
>
> As a real-world example, you can take one of our MX records,
> mx1.aplura.com. mx1.aplura.com resolves to 205.134.167.68. We set that
> up in our DNS servers, which takes care of the forward lookup. The block
> of IP addresses that includes 205.134.167.68 is "owned" by AINet, our
> ISP in this case. We had to submit a request to AINet to add the PTR
> record into their DNS table. Once completed, the PTR record matched the
> A record.
>
> Hopefully this makes sense. Let us know if you need more information.
>
>   -Dan
>