[ale] more reverse DNS questions
Bob Toxen
transam at VerySecureLinux.com
Sat Jan 7 12:42:08 EST 2012
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
More information about the Ale
mailing list