[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Performance Issues - PTR Records
- Subject: Performance Issues - PTR Records
- From: list-nanog2 at dragon.net (Paul Ebersman)
- Date: Fri, 04 Nov 2011 09:28:14 -0700
- In-reply-to: <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
- References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com> <[email protected]> <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
paul4004> It is entirely possible they have it pointed to their
paul4004> non-existent or broken DNS. Given current best practices, I
paul4004> see no reason not to assign a generic
paul4004> x.x.x.x-dynamic.customer.isp.com DNS across their netblock.
It's already been pointed out that lame delegations are more likely
problems for many. But the "we'll just pre-fill in-addr to avoid
problems" isn't going to work for ip6.arpa. If anyone has enough
hardware to serve the zone for a /48 (64k * 4bil * 4bil *
bytes-in-record), I'd love to see it. :)
We need to get web and app folks to stop counting on
ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some
sense for validating servers, MTAs, etc. and it's handy for traceroute
but it was never a great tool and it's getting less useful with time.