Subject: Request for review of DNS related draft

From: Ed Warnicke <[email-masked]>
Date: Thu, 27 Feb 2003 12:56:11 -0500

I have published a draft defining a method for using DNS given
an IP address to resolve the subnet that contains that IP address,
the netmask of that network, and the gateway(s) on that network.
It is very similar in purpose the RFC 1101, but allows for
variable length subnets, and the delegation of zones on
non-octet boundaries.

The draft is available here:
http://www.ietf.org/internet-drafts/draft-warnicke-network-dns-resolution-00.txt

My intention is to pursue having this published as an informational
RFC.  I would very much appreciate any comments or criticism
of the draft.

Thank you for your time,
Ed Warnicke

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Kenneth Porter <[email-masked]>
Date: Thu, 27 Feb 2003 12:28:00 -0800

> the netmask of that network, and the gateway(s) on that network.

I'm curious to know why one would use this instead of DHCP, which is also
commonly provided in routers.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Ed Warnicke <[email-masked]>
Date: Thu, 27 Feb 2003 16:01:03 -0500

For configuring endpoints I would agree that DHCP would perform
this task more effectively.  But DHCP will not allow a device which
is not the endpoint ( or the DHCP server ) to discover the network which 
contains
an IP address and the first hop gateway(s) which service that network.

Ed

---

From: Kenneth Porter <[email-masked]>
Date: Thu, 27 Feb 2003 13:10:38 -0800

--On Thursday, February 27, 2003 4:01 PM -0500 Ed Warnicke <[email-masked]>
wrote:

> contains an IP address and the first hop gateway(s) which service that
> network.

Can you give an example of a device like that? I'm having trouble getting
the motivation here.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Feb 2003 18:07:00 +0700

Date:        Thu, 27 Feb 2003 16:01:03 -0500
    From:        Ed Warnicke <[email-masked]>
    Message-ID:  <[email-masked]>

  | But DHCP will not allow a device which
  | is not the endpoint ( or the DHCP server ) to discover the network which 
  | contains
  | an IP address and the first hop gateway(s) which service that network.

Rather than how, perhaps the question should be why would anyone care?

That's largely why 1101 never got used - the nodes for which it might
have provided information that could didn't already know it via other
means, never had much of a reason to care.

Why would my nodes care what the network that contains some random IP
address might happen to be (or why would I ever care more than the
routing tables will tell me) ?

kre

---

From: Edward Warnicke <[email-masked]>
Date: Fri, 28 Feb 2003 07:31:31 -0500 (EST)

Not everyone is privy to the routing tables.

For example.  Imagine an MGCP call agent which wishes to
perform a maintenance activity that requires the cooperation
of the first hop gateway for an MGCP gateway.  I'm aware
of no MGCP call agent which participates in the IGP for
the networks containing those endpoints.  Additionally
almost all IGPs will allow for some route summarization
which would prevent me from actually knowing who the
first hop gateway is in some circumstances.

So in this example I would either have to provision the MGCP
call agent with information about where the first hop gateway
for each endpoint was, or allow it to use the method of the
draft to resolve it.

Since many of the environments where MGCP is seeing deployment
have a very large number of endpoints, and an unusually large
churn of first hop gateway changes ( think splitting a cable
node ), as well as a tendency toward hierarchical distibution
of control of the network, DNS resolution of this information
seemed to make sense.

The reason RFC 1101 doesn't get used for these sorts of
purposes is that it doesn't support features in common use
in these networks ( variable length subnet masks ).

Ed

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Feb 2003 16:37:50 +0200 (EET)

[...]
> routing tables will tell me) ?

Being able to do something like this would have quite a few security
considerations, besides -- in addition to operational reluctance to take
it to use.

Finding your *own* info could be useful, but you really need most of that 
information before you can make the DNS query..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Edward Warnicke <[email-masked]>
Date: Fri, 28 Feb 2003 11:15:12 -0500 (EST)

Could you be more specific about what security considerations
you see?

In terms of operational resistance to use, I'd expect it to
be about on par with the use of rp and hinfo records.  Organizations
which find utility in having those records populated use them,
organizations that don't see value don't use them.  I've been
in organizations which break both ways on hinfo and rp records.
If an organization finds value in deploying this scheme, they
will.  It's a question of applications.

Ed

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Feb 2003 12:43:42 -0500 (EST)

This seems the wrong way to go about MGCP management activity. What makes
you think the first hop router will have anything to do with VOIP or MGCP?

In the VOIP networks that I've worked with (a number of large voip
installations since 1998), the first hop routers were never VOIP-aware at
all.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Feb 2003 12:44:24 -0500 (EST)

Not to mention that it would be quite useful to smurfers.

		--Dean

---

From: Edward Warnicke <[email-masked]>
Date: Fri, 28 Feb 2003 16:38:16 -0500 (EST)

True, if directed broadcasts for a network implementing
this draft have not been disabled, but no more so than
any information about the structure of the network would
help a smurfer.  So it does reduce security through obscurity
by reducing obscurity.

However, if an organization is concerned they can limit which
zones/domainnames they expose to the outside world.  I would
expect it to be handled in the same way that organization handle
the question of which A records they choose to make visible to
the internet ( split DNS, bind9 views, etc ).

Would folks feel better about this if I were to put a paragraph
in the "security considerations" section noting that availability
to the outside world of information about the network structure
of a network may be used for DOS attacks like smurphing, and
recommending that organizations consider carefully the
acceptable visibility of such records?

Ed