cTLD and DNS upgrade

[Kevin Darcy]

Peter Dambier wrote:

>Kevin Darcy wrote:
>  
>
>>Stephane Bortzmeyer wrote:
>>
>>
>>    
>>
>>>On Wed, Jul 06, 2005 at 10:24:04AM +1000,
>>>Mark Andrews <Mark_Andrews at isc.org> wrote 
>>>a message of 55 lines which said:
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>	That doesn't require a configure option.  I just requires a
>>>>	little reading.
>>>>  
>>>>
>>>>        
>>>>
>>>I know these options and I'm fairly certain that the other
>>>participants in that discussion know them too. I may not be able to
>>>rewrite BIND from scratch but I can read the ARM.
>>>
>>>The issue is security: as long as the code is there, in the running
>>>instance of BIND, a cracker may find a way to exploit it. If the code
>>>is not even there, it cannot be exploited. That's why a run-time
>>>option is not a substitute for a compile-time option. That's why
>>>authoritative-only name servers like nsd are nice, security-speaking:
>>>they have much less code.
>>>
>>>      
>>>
>>Stephane,
>>Think through what you're saying here. You say you want the ability to 
>>compile BIND with some sort of "authoritative-only" flag. Fine. But 
>>you're still going to want something to resolve Internet DNS names 
>>right? After you've built your "authoritative-only" executable, are you 
>>then going to compile BIND *again* with some sort of "resolver-only" 
>>flag? So now you have two different executables that you need to manage 
>>(probably with the same name, which could be very confusing). Now, let's 
>>say a CERT warning comes out for a vulnerability in one of the common 
>>routines that is linked into *both* of your executables. Now you have 
>>two rounds of patching to do instead of just one, and if you happen to 
>>miss one of those executables on one of those machines, you could be 
>>open to attack. Twice as many chances to fail, twice as many chances to 
>>get hacked. How is this better, from a security standpoint, than having 
>>a single executable in the first place?
>>
>>    
>>
>
>Locally you could use /etc/hosts. No need to query any other system.
>
>And you could use that second system who is a resolver.
>
>I have seen many nameservers running bind authoritativly but letting
>their resolver lib query other nameservers not their local bind.
>
I think you're being a little short-sighted. I'm not just talking about 
security for a particular *machine*, I'm talking about security for the 
*entire*organization*. Most organizations do a lot of Internet lookups. 
They use software to do those lookups. That software has to be 
maintained, patched, etc. If the organization has two different products 
or packages to perform authoritative nameservice versus iterative 
resolution, then that's more workload to maintain those disparate 
products or packages. Now, maybe an organization looks at its DNS 
infrastructure *as*a*whole* and makes that calculation and decides that 
it's worth it to spend the extra money in manpower and (potentially) 
software costs, in order to benefit from the (alleged) performance 
benefits of DNS-role-specialization, and/or the alleged security 
benefits of "software diversity". But I would venture to say *most* 
organizations would rather economize on the manpower side, and don't 
care that much about eking out a few cycles of performance from their 
DNS infrastructure. For that mainstream, running a single package, e.g. 
BIND, which is free, can perform both functions, and is relatively easy 
to maintain, makes perfect sense.

(For the sake of argument, let's assume that any organization that cares 
about securing its DNS servers is already running its DNS services 
chroot'ed and unprivileged, since those things by themselves give far 
more "bang for the buck" -- since you just set it up and forget it, 
basically -- for a given investment of manpower, than most of the other 
things we're talking about).

>>I agree, if you *only* serve authoritative zones, or if that's your 
>>primary line of business, then it might make sense to have a specialized 
>>program to do that. But for most of us, BIND is a general-purpose tool, 
>>something we use more or less equally to *resolve* DNS names as to 
>>*serve* them to outside clients. When used that way, it makes little 
>>sense to have different compile-time options for different "flavors" of 
>>named that you intend to run simultaneously in your infrastructure. That 
>>just complicates the job of building, installing and maintaining BIND.
>>    
>>
>
>Others have already had the idea and have split authoritative and
>resolving servers in different programmes that cannot run on the same ip.
>
>Have a look at
>
>http://www.shub-internet.org/brad/papers/dnscomparison/
>
>Brad has done the best nameserver comparison I know of.
>
Yeah, I'm well aware of the fact that many folks have had this "bright 
idea" in the past. And I'm sure they'll continue to have it well into 
the future too.

>Why not use an existing one?
>
>If really somebody hackes Bind as they have done several times in
>history they will hack Bind again because everybody uses it.
>
>On your alternative server you can leave doors open. Nobody will
>knock when they see 'Dr. Bernstein' at your door. It is cheaper
>to hack Bind. There are more of them.
>
I've never been one for the "security through obscurity" argument. 
Sorry. Nor am I willing to give up a bunch of functionality (e.g. TSIG, 
UPDATE, IXFR, sortlist, rndc) just for the theoretical security benefits 
of something like djbdns.

- Kevin