Users Want *Seamless* Solutions, Not Patchwork (was Re: Users want solutions, not buzzwords)

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > No, named just got a *referral*, remember?
>
> No, it didn't. I'm not sure whether your continued lack of understanding
> comes from a failure to read or a failure to think, so I'll spell out
> the situation in excruciating detail:
>
>    * You have an internal domain, local.chrysler.com, on an internal
>      server. The chrysler.com servers don't know anything about this
>      domain, and they don't have delegations to the internal server.
>
>    * You tell your BIND cache to forward local.chrysler.com to the
>      internal server. You make the mistake of using ``forward first.''
>
>    * You start BIND. It looks up the root servers but otherwise has an
>      empty cache.
>
>    * Your mail server asks for the address of www.local.chrysler.com.
>      BIND tries contacting the internal server. There is no response.
>      (The server's network connection is temporarily overloaded.)
>
>    * Because you made the mistake of using ``forward first,'' BIND now
>      contacts the root servers, then the .com servers, and finally the
>      chrysler.com servers. The chrysler.com servers say that the domain
>      www.local.chrysler.com does not exist.
>
>    * BIND returns this information to your mail server. The mail server
>      bounces the mail.
>
> You are wrong when you claim that ``forward first'' is a safe way to
> handle internal domains.

Okay, in that particular, contrived scenario (i.e. named is just starting
up at the same time coincidentally that all of the nameservers for the zone
are unavailable), "forward first" does not fare very well. But that still
leaves the "stub" alternative. Also, in practical terms, if one had such
unreliability problems with that particular zone, one might consider
becoming a stealth slave for it. Remember that BIND offers the flexibility
of mixing caching-resolver and authoritative-server functions at will.
Stealth slaves are a great way to deal with unreliability problems.

>   [ BIND accepting local.chrysler.com information from .com servers ]
> > Anyone who is concerned about such things should upgrade to BIND 9.2;
> > it has a "minimal-responses" feature which should moot the problem
>
> You are continuing to make a fool of yourself. Minimal responses (which,
> btw, dnscache has had since 1999) are from caches to clients. They have
> no relevance to your internal names being subverted by the .com servers.

My understanding is that "minimal-responses" affects any responses named
gives. I was envisioning the internal caches/resolvers using an
intermediate instance of named (a "forwarder") to resolve Internet names.
Configured with "minimal-responses", the forwarder would filter out
possibly malicious Additional Section contents so that the internal
caches/resolvers would never see them. Now it may be true that the
forwarder itself might be spoofable with malicious Additional Section
contents. But now we're starting to drift far away from "ease of use" into
security issues. This is just one variety of spoofing that DNSSEC was
created to prevent.

> > Note that if worse comes to worst, the forwarder could perhaps be
> > configured as a slave for the internal "local.chrysler.com" zone.
>
> For large sites, with large internal zones and many internal caches,
> that's unusably slow.

Inefficient, yes, but not "unusable". In certain parts of this corporation,
a forwarding hierarchy is in effect, and to facilitate this, they slave
*every* internal zone (many hundreds if not thousands of them). So it _can_
be done. (I'm not saying it's recommended. In fact, I'm trying to get them
to switch over to using my internal root zone).


- Kevin