Re: [RRG] Consensus? End-user networks need their own portable address space

["William Herrin" <bill@herrin.us>]

On Fri, Jun 20, 2008 at 12:49 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> It's been clear for a long time that use of IPvN addresses outside of a site
> as part of configuration elsewhere, as opposed to using DNS names, introduces
> brittleness into the system.
>
> So what I'm curious about is why people are doing that (using IPvN
> addresses). Is it because there is some perceived robustness or security
> issue with DNS? Or is it something where the fact that IPvN addresses and DNS
> names aren't a 1:1 match is important? Or is it simply because it's 'easier'
> to use IPvN addresses (no need to build in DNS resolution, etc)? (Or all of
> the above, in differing cases?)

Hi Noel,

In my own encounters, it has pretty much always been a question of,
"What works?"

Email reputation? Hundreds of ideas were thrown at the problem by
thousands of people working independently. Several stuck because they
were useful for identifying spam. Those included bayessian
classification and source IP address use history. Nobody planned it
that way and there was nothing dogmatic about it. It was just an
organic response to, "What the heck can we do to get an edge on the
spammers?"

IPSec VPNs? The most widely deployed product is the Cisco PIX/ASA. You
configure the cryptomaps with IP addresses and netmasks and if they
don't match on both sides, it doesn't work. It simply isn't possible
to configure them with something other than bare addresses. Is it even
practical to build an IPSec VPN appliance that configures and
reconfigures tunnels dynamically based on hostnames? Hostnames work
fine for SSL VPNs, but IPSec's function is so arcane that I'm not sure
it's possible to work with it in any other way besides bare IP
addresses.

I don't think perception of security plays a major role any more. It's
still waiting in the wings, but the major concerns at this point are
all practical: we have to operate in a manner compatible with what
that other guy is doing or our stuff won't work. The bottom line is
that our stuff has to work.


>    > Placing your customer web servers behind a NAT box ...
>    > They can't avoid that problem up front with CNAMEs to your DNS because
>    > they often desire the same name that holds the NS and SOA records to
>    > reach the web site.
>
> Another place where the architecture has too few namespaces.
> "somecompany.com" is overloaded as i) the website's secondary DNS name (after
> www.somecompany.com), and ii) the NS/SOA name... (at least, if I understood
> your point correctly).

The point I was making is that DNS has no concept of, "this name has
the same IP address as that name over there." Instead it has CNAMEs
which mean, "the answer to this record is the same as the answer to
that record over there."

The difference is that no name which is a delegation component can
reference another name's IP address because the delegation components
have SOA and NS records which are unique to them. Www.mycompany.com
can have a CNAME but Mycompany.com can't. Since everybody wants
http://mycompany.com/ to go to their web site, this DNS CNAMEs don't
ease address renumbering.

Regards,
Bill



-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg