Subject: [renum] No longer hard-coded IP addresses?

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Dec 2010 21:04:02 +0100

[Sent on the int-area mailing list two weeks ago and resent here with
a fex typos fixed, because, I think, it is relevant.]

On Thu, Nov 11, 2010 at 03:59:40AM -0700,
 Shane Amante <[email-masked]> wrote
 a message of 67 lines which said:

> To pick on one example, we all know (or, should know?) that we need
> to *stop* the well-worn practice of 'hard-coding' IP addresses and
> IP prefixes into various device and service configuration.

This is too strict a principle. If IP addresses are stored in one
place and then automatically integrated into configurations and then
pushed to devices via automatic means (Rancid, Chef, Puppet, etc),
then, it is not too big a problem for renumbering.

My concern with the current Most Common Practice is not the use of IP
addresses per se but the lack of decent, high-level, etc,
configuration management tools. This is what makes renumbering a
painful and dangerous operation.

> Along those
> lines there exists:
> a)  DNS Service Discovery;
> b)  RFC 3123, DNS RR Type for lists of Address Prefixes -- but, it's
> experimental; and,
> c)  DNSSEC to secure (a) and (b).

DNSSEC deployment only started seriously to be deployed two years ago
and, in many places, it is far from being over. At of today, you
certainly cannot suggest DNS+DNSSEC as a general solution to replace
hard-coded IP addresses in configurations, specially for
security-related devices (ACL in a firewall).

To seriously promote DNS+DNSSEC as a credible alternative to
hard-coded IP addresses, we would need (note that not all these points
depend on IETF):

* a standard API for applications to get the result of DNSSEC
validation (a firewall configured with names would certainly love to
use it),

* most DNS zones signed,

* a majority of DNS registrars (for TLD with registrars) which accept
DS records (today, they are only a small minority),

* better working relationships between network people and DNS people
(may be the hardest problem: in many places, people who configure the
firewall simply distrust/do not understand the DNS).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2010 10:58:50 +1300

> painful and dangerous operation.

Maybe we should start by trying to complete the list of places where
people embed addresses and prefixes? There is a first list in Appendix A
of RFC 5887, pasted from earlier work by Tim Chown et al.

The reason to have such a list is to figure out which of them can be
fixed by more reliance on DNS, which of them need config management
tools of some kind, and which of them are hopeless cases.

   Brian

---

From: Shane Amante <[email-masked]>
Date: Thu, 2 Dec 2010 20:35:20 -0700

Well, since we're fwd'ing messages from other mailing lists, here was my reply to your message on the intarea list for those who are interested:

---cut here---
Stephane,

On Nov 13, 2010, at 01:52 MST, Stephane Bortzmeyer wrote:
> My concerne with the current Most Common Practice is not the use of IP

I agree with your above points; however, I think it should be fairly clear that we need a range of solutions depending on the size of the end-site.  For large-ish sites, the tools you mention above are invaluable[1]; however, what about small- to medium sites that have 'standalone' devices?  In that case, I don't believe tools like rancid, chef, etc. are applicable, mainly because there aren't full-time administrators to wrangle with them.  Alternatively, tools like rancid, chef, etc. could certainly benefit from using DNS + DNSSEC as a means to validate elements in configs (FQDN's, services, etc.) they generate on behalf of "legacy" devices in medium- to large-sites and push down to those devices, correct?

> security-related devices (ACL in a firewall).

Agreed; however, I think you're strengthening my point.  Specifically, if DNS is the "right tool" for this job and it requires new RR's or other modifications, it would be good to get those baked into DNS sooner rather than later in order that as new SW for DNSSEC gets deployed these new modifications/enhancements in DNS, to ease the burden of renumbering, also get deployed at the same time.  I would also note that there will be incremental deployment benefits for those early sites that start to use these enhancements (at least, internally) and could "encourage" (or, force) other external sites to use it as well.

> DS records (today, they are only a small minority),

Sure, but (again) I don't think we should "wait" until we think DNS + DNSSEC is fully/mostly deployed, before working _toward_ offering it as a credible solution for the renumbering problem at some point in the near future. 

> firewall simply distrust/do not understand the DNS).

I think this speaks to another point, which is that we need to remove the obstacles for consumers of information in the DNS from exclusively going through the "gatekeepers" of the DNS zones running on DNS servers to 'write' or update information they are responsible for in those zones.  IOW, we have RFC 3007, Secure DNS Dynamic Update, wh/ is already supported in Windows, Mac OS X and Linux.  IMHO, this needs to be mandated as the means to maintain these new RR's in order to reduce the barriers that currently separate these groups.

-shane

[1] I'm not sure how much NETCONF/NETMOD would help in relation to tools like chef, puppet, etc. other than avoiding the need for those tools (or, others like them in the future) from inventing new methods/languages/syntax to represent a device's config and/or interact with that device's config 'over the wire'.  Regardless, this is something else that we should probably look at in parallel and I'd be happy to participate in that effort too.