NS record question

[Brad Knowles]

At 10:28 AM -0800 3/27/01, Doug Barton wrote:

>  	Blah blah blah. I'm actually pretty tired of this argument. I realize that
>  bind 8 has some ugly spots, but it's still the bugs we know, vs. the bugs
>  we don't know in bind 9. I'm also a little suspicious of all the people who
>  claim that there is this or that present in the bind 8 source, but haven't
>  actually submitted any fixes.

	You can get as tired of this argument as you want.  But this is 
the sort of thing being said by the guys who are actually maintaining 
the code, or who have maintained the code -- Paul Vixie has been 
saying this for years.

	I understand that Mark is either the sole person remaining that 
is supporting "legacy" code like BIND 8, or one of damn few people 
doing so, while everyone else in the Universe who is working on BIND 
is doing so with BINDv9.  Now, while I have the greatest of respect 
for Mark, I also know when it's time to put that horse down, and that 
time is rapidly approaching.


	You can either listen to these arguments or not, but if you 
choose to ignore them, you do so at your own peril.

	You may be hearing these arguments from me, but while I am 
phrasing them my own way, the original concepts and ideas are most 
certainly not my own.

>  	Ummm... how do you make the leap of logic that says that new features
>  added to a new code base are better or more stable than new features added
>  to an established code base?

	Go back and re-read your CERT Alerts.  It's the TSIG code in BIND 
8 that made it subject to a root compromise, and is the reason that 
8.2.3 was released.

	BINDv9 does not have this security problem, and in fact the code 
is designed in such a manner that if there are any as-yet-undetected 
security problems, they should result in BIND simply crashing (with 
at least an attempt at logging something semi-useful just before it 
commits suicide) instead of leading to a root compromise.

>  	Once again, I have nothing but respect for the people at nominum, and the
>  herculean task that faces them. However, as I pointed out previously the
>  migration path still has too many hurdles (and unseen pitfalls) for most
>  people, IMO.

	A properly configured BIND 8 nameserver should have very little 
work to do in order to be converted to BINDv9.  The real problem is 
that BIND has been far too lax in letting people get away with all 
sorts of illegal crap in the past, and simply logging something but 
continuing anyway, which causes most people to simply turn off 
logging.

	BINDv9 instead chooses to simply not run (or not load that zone), 
so that people are *forced* to fix their effluent.


	This is an extremely conscious design decision.

	If you have issue with that, then you have issue with that.  But 
that's a totally different matter from any opinion that BINDv9 is 
"broken" in some sense, or simply "Not Ready For Prime Time".

>                                                 Also, the mere fact that
>  most of the code in bind 9 is produced "by contract," doesn't really enter
>  into this discussion. I am a proffesional programmer and I know the
>  problems associated with this kind of project. Thus my concerns.

	Uh, no.  You don't understand the term "programming by contract". 
I'm not sure I do either, but my understanding that this means there 
are certain magic cookies that have to get passed in each function or 
subroutine call, and they have to match up on the other end with what 
the called function/procedure is expecting.

	If these two don't match, then the called function/procedure 
knows that something funky is going on (e.g., a stack-smashing 
attack, etc...), and it logs as much useful information it can, and 
then promptly commits suicide.


	I think the idea is very much like a PGP signature, but at a 
function/procedure call level.  This should make it virtually 
impossible to cause an undetected compromise, and in the face of a 
detected compromise, the called routine can print out as much 
information as it has, and then quietly commit suicide -- it 
obviously can't trust anything it was called with, and therefore 
can't even trust the routine that called it to do whatever the 
correct thing might be with the information it might be able to 
provide.

>  	On this point I agree with you. However I don't see any point in
>  encouraging people to upgrade exclusively for the purpose of getting them
>  to use bind 9. Since this entire e-mail basically restated points made
>  previously, I think I'll leave it at that.

	BIND 8 is dead.  Get over it.  The future is BINDv9, and the day 
is very, very rapidly approaching when BIND 8 will officially be put 
out to pasture.

-- 
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,$_)}'