forwarding to a child zone is different!!
Brad Knowles
brad.knowles at skynet.be
Wed Apr 25 22:43:24 UTC 2001
At 5:41 PM -0400 4/25/01, Kevin Darcy wrote:
> Huh? I don't follow. You seem to be implying that being
>authoritative makes cache
> pollution more likely. Seems like it should be the other way
>around, i.e. if you're
> authoritative for a zone, then all of that data is of high
>"credibility" and thus
> less subject to poisoning.
Unfortunately, that's not the way it works. The reality is that
it is possible to successfully lie to any caching nameserver, and get
it to believe that the answer is correct.
If the server in question is caching-only (i.e., not
authoritative for any zones), while this "lie" may be propagated to
other servers, at the very least it shouldn't be handed out as an
authoritative answer, so they can choose to believe it or not. The
cache may be polluted, but it doesn't get propagated.
If the server in question is authoritative, and the successful
lie is for an answer within the authoritative zone (yes, it will be
cached), then when this answer is handed out to other servers, it
will be handed out and marked as authoritative, and other servers are
largely forced to actually believe it. The cache is now polluted,
and because the server is authoritative for the zone in question, it
is also getting propagated.
Moreover, if you're sneaky about how you lie and to which
servers, this can be used to insert whatever information you want
into their DNS, and if they used purely name-based authentication,
this becomes a method by which you can much more easily break into
their servers.
The solution to this problem is to *ENSURE* that authoritative
and caching servers are implemented on totally separate machines.
This avoids the operational problems that cache pollution can cause,
and avoids the increased security risk.
> From a query-latency standpoint, you really can't beat having all
>of the data for a
> zone resident in memory at all times. So if you have the memory (my
>boxes have 2Gb
> RAM apiece) and the zone-transfer overhead doesn't bring the box to
>its knees (it
> doesn't), then being a slave for the most frequently-used zones
>makes a lot of
> sense. Besides, I have to do it anyway for purposes of redundancy.
From the perspective of the overall latency to any one query, you
may be right. However, if your TTLs are set properly and your
caching servers are operating correctly, then averaged over the life
of a typical record, a caching server should give you 99.99...99% of
the overall average latency performance that you'd get with the same
server also being authoritative.
Moreover, if you set up a local authoritative secondary on a
separate machine (or a separate process on the same machine), the
caching server will automatically prefer it for virtually all
queries, and you avoid the risks of cache pollution. This also makes
it easier to scale the system in the future, should the load reach a
level that exceeds what a single machine could handle.
> Agreed. All of my external-facing nameservers have recursion
>disabled or limited to
> our own networks. In network-boundary situations, I agree that
>separation between
> the two types of nameserver functions is generally recommended. But
>outside of such
> environments, hybrid configurations are often optimal.
In theory, you might be right. But in practice, even BIND
9.1.1-REL is subject to cache pollution attacks, and if at all
possible you should run authoritative services on a totally separate
machine from recursive/caching services, and ensure that you keep a
full and proper split between them.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list