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