[ale] more reverse DNS questions
Michael H. Warfield
mhw at WittsEnd.com
Mon Jan 9 10:57:17 EST 2012
On Mon, 2012-01-09 at 15:00 +0000, Lightner, Jeff wrote:
> There are even some places (Paypal I think is one) that will reject
> email if they consider the reverse to be "generic". (i.e. some folks
> will put in a reverse range like xx.xx.xx.xx.arpa.domain and this is
> considered "generic")
Well, it's not exactly "generic". I think Paypal and others are looking
for patterns that indicate broadband or dsl or dialup ranges. They'll
look for static names (like ppp or dialup or dsl or broadband) where the
simple host name is some common constant or autogenerated names where it
appears the simple host name contains either some form of the address
(like replacing dots with dashes or underscores) or has the last octet
of the address.
That's actually more common than the "must have a reverse and the
reverse result must resolve back to the original" consistency check that
Bob was mentioning. The later requires a second DNS lookup. I've seen
a variety of spoofing and broadband checks in various packages like
MailScanner and such and we've seen problems from various providers like
AT&T, Yahoo, and PayPal / EBay. I've actually seen circumstances where
a pattern name indicating a home connecting gets you rejected more often
than if you have no reverse lookup.
Best circumstance is if you have a valid reverse lookup that points back
to your server AND the RRs for your server also includes and MX record
that points at your server (not required but some sites are checking and
adding to scoring +- and it's recommended as a best practice). Best
circumstances are not common circumstances in practice. In the real
world, they still accept things pretty commonly.
An example is a site I take care of there near Emory, Callanwolde Fine
Arts Center. Their primary E-Mail server gryphon.callanwolde.org on
65.15.91.131. Forward and reverse lookups are as follows...
[mhw at canyon ~]$ host gryphon.callanwolde.org
gryphon.callanwolde.org has address 65.15.91.131
gryphon.callanwolde.org mail is handled by 10 gryphon.callanwolde.org.
[mhw at canyon ~]$ host 65.15.91.131
131.91.15.65.in-addr.arpa domain name pointer adsl-065-015-091-131.sip.asm.bellsouth.net.
[mhw at canyon ~]$ host adsl-065-015-091-131.sip.asm.bellsouth.net.
adsl-065-015-091-131.sip.asm.bellsouth.net has address 65.15.91.131
So that fits Bob's comments and still would identify it as a common dsl
range. Yet, we very rarely have any problems. There have been problems
with AT&T and Yahoo both, but they were unrelated to the reverse DNS and
quickly resolved through their support contacts.
BUT! I also have them set up with DKIM Domain Keys and their outbound
E-Mail gets signed with their DKIM keys which can be validated under
DNS. I can't say if the sites and services which validate and accept
them now with a recognizable DSL based address would accept them if that
level of verification didn't exist. Several of the antispam packages
include DKIM in their scoring as well.
Regards,
Mike
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Bob Toxen
> Sent: Saturday, January 07, 2012 12:42 PM
> To: mhw at wittsend.com; Atlanta Linux Enthusiasts
> Subject: Re: [ale] more reverse DNS questions
>
> The important thing, if you are sending email out, is that there IS a
> Reverse DNS record pointing to some Fully Qualified Host Name and that
> there is a normal DNS record for that Fully Qualified Host Name that
> points back to the IP of the original system.
>
> Many good spam filters will (and should) dump email without those two
> DNS records!
>
> Thanks to MikeW for his detailed analysis!
>
> Bob Toxen
> bob at verysecurelinux.com [Please use for email to me]
> http://www.verysecurelinux.com [Network&Linux security consulting]
> http://www.realworldlinuxsecurity.com [My book:"Real World Linux Security 2/e"]
> Quality Linux & UNIX security and SysAdmin & software consulting since 1990.
> Quality spam and virus filters.
>
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond where
> the shadows lie...and the Eye is everwatching"
> -- The Silicon Valley Tarot Henrique Holschuh with ... Bob
>
> On Fri, Jan 06, 2012 at 05:03:55PM -0500, Michael H. Warfield wrote:
> > On Fri, 2012-01-06 at 15:00 -0600, John Heim wrote:
> > > Last week I was asking about using godaddy for DNS. Well, I finally figured
> > > out how to get godaddy to let us run our own DNS server. Toward the bottom
> > > of the page for setting nameservers is a button called "Host summary". You
> > > have to enter the names and IP addresses of your nameservers on that page
> > > before you can enter them onto the list of nameservers for your domain. So I
> > > did that and now we are up and running.
> >
> > > Well, except for one thing. you can't do a reverse lookup on the IP address
> > > of our virtual machine. There is nothing I can do about that, right?
> >
> > Probably not.
> >
> > > This is
> > > a vm that is donated to us by a local web services company.
> >
> > It's doubtful they even control their own reverse DNS.
> >
> > > Its one thing
> > > to tell the world that www.iavit.org goes to 66.170.20.226. That can't mess
> > > anything up. But you can't have just anybody doing it the other way around.
> > > If that was something anybody could do, the internet could be severaly
> > > messed up.
> >
> > No, that's not quite the situation. In fact, the reverse DNS is MORE
> > often thoroughly messed it. In general, it's a morass. It's an
> > entirely separate hierarchy and structure under the .arpa. TLD
> > (in-addr.arpa. for IPv4 and ip6.arpa. for IPv6).
> >
> > No, the problem is in its structure and how it's organized and
> > delegated. I have a large enough block of addresses that I have my own
> > delegated nameservers for that namespace that are actually registered
> > with ARIN.
> >
> > If you do a lookup on my web server you'll get this forward:
> >
> > [mhw at canyon ~]$ host www.wittsend.com
> > www.wittsend.com has address 130.205.32.81
> >
> > If you do the reverse, you get this:
> >
> > [mhw at canyon ~]$ host 130.205.32.81
> > 81.32.205.130.in-addr.arpa domain name pointer amethyst.wittsend.com.
> >
> > (You'll notice they don't match - Amethyst is the canonical name of that
> > server - they don't have to match).
> >
> > Now you see what was actually looked up was "81.32.205.130.in-addr.arpa"
> > looking for a pointer (PTR) record. But that record has to exist as an
> > individual resource record in the "32.205.130.in-addr.arpa" zone (drop
> > the 81. on the left). So I have a zone file for that entire block of
> > 256 addresses. Here are a few of the records from that file:
> >
> > $ORIGIN 32.205.130.in-addr.arpa.
> > ;
> >
> > ;
> > 74 IN PTR slate.wittsend.com.
> > 75 IN PTR ruby.wittsend.com.
> > 76 IN PTR emerald.wittsend.com.
> > 77 IN PTR perl.wittsend.com.
> > 78 IN PTR basalt.wittsend.com.
> > 79 IN PTR granite.wittsend.com.
> > 80 IN PTR mercury.wittsend.com.
> > 81 IN PTR amethyst.wittsend.com.
> > 82 IN PTR mica.wittsend.com.
> > 83 IN PTR dark-tower.wittsend.com.
> >
> > So, you see, that's all being managed in one spot under one zone shared
> > for all those addresses. That would normally be delegated from the zone
> > above it, 205.130.in-addr.arpa in this case, either by using NS
> > delegation records in the parent zone or having the parent do zone
> > transfers and be authoritative for the child, or reside on the same name
> > server and have the child essentially inherit the parent's delegation.
> > There are standards and ways of delegation out partial zones that don't
> > fall on an 8 bit boundary but not all ISPs and block owners support that
> > (I don't need to :-P).
> >
> > If you had a cooperative ISP, they could either update the PTR record
> > for you (most common, if they are willing at all) OR change the PTR
> > record to one or more NS records pointing at your name server like this:
> >
> > 81 IN NS ns1.wittsend.com.
> > IN NS ns2.wittsend.com.
> >
> > Then you would have a zone file containing just the 81 PTR record and
> > could update it to your hearts content. BUT! If you use that same name
> > server as your caching name server (poor but very common practice) it
> > won't know to refer the OTHER reverse records back to the parent and you
> > could create a mess for yourself. Not a good idea and you probably
> > couldn't get the ISP to agree to it without a very good reason and proof
> > you had a good grasp on DNS configurations and gotchas.
> >
> > > So if I understand the way the internet works, I'm going to have to go to
> > > the company that donated the virtual machine and get them to contact their
> > > ISP on our behalf. Is that correct?
> >
> > More or less, correct. You have to go to the owner of that netblock,
> > most likely the ISP, and possibly have to chase down who is responsible
> > for the nameserver that is authoritative for the /24 containing your
> > address. Most people will just shrug and go "why bother".
> >
> > Based on the address you listed in your A records below, I did a quick
> > check on the SOA for the parent zone like this:
> >
> > [mhw at canyon ~]$ dig -t SOA 20.170.66.in-addr.arpa
> >
> > ; <<>> DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 <<>> -t SOA 20.170.66.in-addr.arpa
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37261
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;20.170.66.in-addr.arpa. IN SOA
> >
> > ;; ANSWER SECTION:
> > 20.170.66.in-addr.arpa. 3600 IN SOA dns1.supranet.net. hostmaster.supranet.net. 2012010300 1800 900 604800 300
> >
> > ;; AUTHORITY SECTION:
> > 20.170.66.in-addr.arpa. 86380 IN NS dns2.supranet.net.
> > 20.170.66.in-addr.arpa. 86380 IN NS dns1.supranet.net.
> >
> > ;; Query time: 85 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Fri Jan 6 16:45:03 2012
> > ;; MSG SIZE rcvd: 137
> >
> > Now... What you are REALLY interested in is in the "AUTHORITY SECTION"
> > where you see two NS records. Those are the nameservers that have to be
> > updated for the reverse DNS to be changed. You would have to contact
> > Supranet.net. In the "ANSWER SECTION" also shows dns1.supranet.net. as
> > the "primary" authoritative name server (but it can also be some slave
> > off of a hidden master). You need to get to someone who can update the
> > master authoritative nameserver for that zone.
> >
> > Doing a "whois 66.170.20.226" confirms Supranet as controlling that
> > block and returns some contact information like this E-Mail address:
> >
> > hostmaster at supranet.net
> >
> > Which agrees with the pseudo E-Mail address in the SOA (the '@' is
> > replaced by a '.' in the SOA).
> >
> > Honestly... Good luck with that. That block is a delegated /19. So,
> > basically 32 of the /24 zone blocks like I was describing. Some ISPs
> > will do it and some of the just couldn't be bothered, especially if it's
> > an automatically generated zone and this would require manual
> > intervention (not saying it is, not saying it's not).
> >
> > In you're particular case, they don't even have a PTR record in place
> > for you:
> >
> > [mhw at canyon ~]$ host 66.170.20.226
> > Host 226.20.170.66.in-addr.arpa. not found: 3(NXDOMAIN)
> >
> > So they would have to add a record and they may not even have a zone
> > file for that /24 block to begin with.
> >
> > > PS: Here is my forward lookup zone file. Can anybody tell me if I've done
> > > anything wrong?
> > >
> > > $TTL 86400 ; 24 hours could have been written as 24h or 1d
> > > $ORIGIN iavit.org.
> > > @ IN SOA iavit.iavit.org. hostmaster at iavit.org. (
> > > 2011062601 ; serial
> > > 3H ; refresh
> > > 15 ; retry
> > > 1w ; expire
> > > 3h ; minimum
> > > )
> > > ;define name servers on domain
> > > IN NS ns1
> > > iavit.org. IN TXT "v=spf1 mx ~all"
> > > IN MX 10 mailhost
> > > IN A 66.170.20.226
> > > iavit IN A 66.170.20.226
> > > lists IN A 66.170.20.226
> > > ns1 IN A 66.170.20.226
> > > ns2 IN A 66.170.20.226
> > > mailhost IN CNAME iavit
> > > wiki IN CNAME iavit
> > > www IN CNAME iavit
> > >
> >
> > That "minimum" parameter really serves a different purpose than what it
> > was originally defined for. In the distant past it was the default or
> > minimum TTL applied to resource records (RR) but that is now handled by
> > the $TTL directive, which you have there set to 1 day. Since every RR
> > that is contained in a reply has a TTL specified, it wasn't necessary to
> > also have a minimum TTL in the SOA. That was redefined years ago to be
> > the negative TTL. That comes into play if someone requests a
> > non-existent record and get an NXDOMAIN (no such domain or FQDN) error
> > and basically returns no resource records for the query. The negative
> > TTL in the SOA tells the cachers how long to remember that there was no
> > records returned in the response. 3 hours is a rather low value for
> > that unless you're planning on adding a lot of records as time goes on
> > which may get queried and NX cached before you have them ready. I would
> > set that to a day as well.
> >
> > Regards,
> > Mike
> > --
> > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
> > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
>
>
>
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> Athena(r), Created for the Cause(tm)
> Making a Difference in the Fight Against Breast Cancer
>
> ---------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120109/caed3027/attachment.bin
More information about the Ale
mailing list