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

From: [email-masked] (George Michaelson)
Date: Wed, 8 Aug 2001 01:22 EST

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.

cheers
	-George

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 07 Aug 2001 16:31:28 -0400

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

---

From: "Ray Plzak" <[email-masked]>
Date: Tue, 7 Aug 2001 17:29:10 -0400

Providing servers for in-addr service is not the same as setting ptr records
for hosts.  I agree that the managers of space on bit boundaries, ie, /8,
/16, and /24 should provide servers for those below them.  The shorter the
prefix, the more important it is that the server be available.  However,
this in no way obligates the end host to use the service, it merely gives
that host the option of using it.

Ray

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> George Michaelson
> Sent: Wednesday, August 08, 2001 2:22 AM
> To: [email-masked]
> Subject: comment on draft-ietf-dnsop-inaddr-required-02.txt
>
>
>
>

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Aug 2001 17:45:15 -0400

>that host the option of using it.

And this is really a key point. End users should be allowed to use INADDR, 
if they want to use it. I've been wrestling with this for a while, in terms 
of what the draft needs to say here. I think a reasonable set of statements 
might be somthing along the lines of:

- those providing the address space MUST provide INADDR service, either 
themselves or by delegating zones to those using the space.

- those responsible for the end systems SHOULD set up PTR records for their 
hosts (or ask their provider to do it for them). The user is not required 
to have PTR records, if they so choose.

The draft already points out that using INADDR as a security mechanism is a 
bad idea. The general consensus in the room in Minneapolis was that we 
discourage any notion that there's security to be found in looking up PTR 
records followed by A records.

Thoughts?

> > distributed places to attempt in-addr lookup.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 8 Aug 2001 13:07:50 +1000 (EST)

> themselves or by delegating zones to those using the space.

In the case of the Registries, this means delegating the appropriate /16
or /24s to the organisation which has just received a CIDR allocation from
the Registry; all RIRs have polices for this already in place.

These policies generally allow the RIR to revoke a delegation in order to
protect the RIR's infrastructure.  Can this be expressly stated in the
draft as well, ie:

	Regional Internet Registries and any Local Registries to whom they
	delegate SHOULD establish and convey a policy to those to whom
	they delegate blocks that require IN-ADDR mappings.  These
	policies MAY be used by the Registry to revoke or reject a
	delegation that does not meet these stated policies.  

( the rest of the original paragraph is then best stated in an additional
  paragraph. )

-- 
  Bruce Campbell <[email-masked]>                +61-7-3367-0490
                      Systems Administrator     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region
                    Unix means never having to live hand-to-mouse.

---

From: George Michaelson <[email-masked]>
Date: Wed, 08 Aug 2001 23:41:06 +1000

> that host the option of using it.

Yep. thats fair. The problem is that for the case where the /24 doesn't do it
the /16 holder cops the problem: so it an indirect effect on somebody else
and usually a small number of somebody else! (and obviously the same
for the /8 holder for a /16 not running server)

So if you modify the sense of my comment to be that bit-boundary aligned
space-owners SHOULD provide servers, I strongly agree.

-George