Performance Issues - PTR Records

Robert Bonomi bonomi at mail.r-bonomi.com
Mon Nov 7 07:09:19 UTC 2011


Tom Lanyon <tom+nanog at oneshoeco.com> opined:
> >> OK.. let's say you're a DSL provider.   Are you going to have your
> >> DHCP server populating the forward and reverse DNS?   With what,  the
> >> account holder's  name?    somename.example.com ?
> > 
> > I'll suggest that (a) IF the addresses do migrate among different customers
> > of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> > CPE has to 'authenticate' itself to the head-end, then it is _very_ useful 
> > *to*the*ISP* to have dynamically-assigned DNS records of the form: 
> >   cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> > or something of the sort.
> > 
> > Something of that sort can save a -lot- of time/effort in identifying the
> > customer involved in a complaint.
>
> Surely that's only useful if they're still allocated the address at the time 
> of investigating said complaint;  a dynamically updating DNS record like thi
> s is really no substitution for accurate accounting records in your RADIUS s
> ystem.

You're missing some 'obvious' considerations.  Consider a spam complaint
sent with 'full headers' included.  The rDNS _at_the_time_of_the_crime_
is present in the complaint.  Yes, you need to confirm that -that- customer
was on that IP at that time -- but having an identifier for the customer
makes the verification check much quicker/simpler, and requires less skils
on the part of the front-line person dealing with the complaint.

No, it doesn't *always* provide a short-cut to identification, but it is
useful "often enough' to be well worth considering.






More information about the NANOG mailing list