Performance Issues - PTR Records

Mark Andrews marka at isc.org
Tue Nov 8 11:05:12 UTC 2011


In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
> On 7-11-2011 14:46, sthaug at nethelp.no wrote:
> >>> The practice of filling out the reverse zone with fake PTR record
> >>> started before there was wide spread support for UPDATE/DNS.  There
> >>> isn't any need for this to be done anymore.  Machines are capable
> >>> of adding records for themselves.
> >>
> >> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
> >> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
> >>
> >> Or is it the CPEs responibility to dynamically add records for whatever
> >> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
> >> doing this?
> >>
> >> Or will the end systems themselves do the update against my DNS server?
> >> If so, how do I authenticate that?
> > 
> > With my ISP hat on, I find the idea of customer CPEs updating their
> > own PTR records to be completely unacceptable. So I guess I'll either
> > live without the reverse DNS, or use a name server that can synthesize
> > answers on the fly.
> 
> That seems like a really nice feature, create a reverse record to spoof
> a mail server and the reverse DNS will match up.
> 
> If the domain does not employ SPF it will look legit, forward and
> reverse won't match up ofcourse. Not sure how many mailservers have
> issues with that if the reverse matches up.
> 
> Sounds like a fine way to employ a spam botnet.

Sounds like FUD.  Who has trusted the contents of a PTR record in the
last 2 decades?

> Regards,
> 
> Seth
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list