Re: comment on draft-ietf-dnsop-inaddr-required-02.txt

[Kevin Darcy <kcd@daimlerchrysler.com>]

I agree that if people use reverse DNS at all, they should use it
consistently, to avoid bottlenecks.

But, why use reverse DNS at all? It leads to all sorts of bad security
practices, half-solutions to real problems (like the spam problem) and a
*false* sense of security.

I can appreciate that network devices, such as hubs, routers, switches, etc.
might warrant reverse DNS entries, for the benefit of troubleshooting tools
like ping or traceroute. And I can appreciate that organizations may choose to
implement reverse DNS for their own purposes, like providing a consistency
cross-check of their forward DNS. But I strongly oppose any attempt to make
reverse DNS *mandatory* across the board. The decision whether or not to use
reverse DNS is one that each organization should be free to make for
themselves.


- Kevin

ggm@apnic.net wrote:

> One non-security (well almost)  reason is that RIR and other
> allocatiors of large address space are required to list in-addr
> for the parent block, because thats how they delegate down to those
> who do chose to provide in-addr.
>
> So a consequence of not having in-addr for a given /prefix is
> that the parent /prefix-1 has to wear repeated requests for in-addr
> which it can't answer, and while this is not a big deal inside small
> allocations, for shorter prefix owners (or registries) the load
> can be excessive.
>
> Its a non-deliberate DoS effect that chokes semi-core DNS servers.
>
> We wind up doing nasty things like pretend-revoking the delegation
> so we can answer the much shorter NXDOMAIN instead of ourselves spinlocking
> to find an answer and timing out.
>
> So, I would welcome a requirement because it has the effect of reducing
> load on central infrastructure, and risks of DoS or service-quality loss
> to a third party when a large network space is live, and causing widley
> distributed places to attempt in-addr lookup.