Re: Securing bind..
Hi Craig,
This BIND vs. djbdns thing has strayed off topic.
It started with a Debian user asking for a solution to a problem. One of
the answers given was that a solution could be achieved by using djbdns,
which is packaged in the testing and unstable distributions of Debian. I
suggested, and still maintain, that the original poster's needs could be
met by using djbdns.
Craig, you make some comments about djbdns which just aren't true. I'll
try my best to rectify these so that anyone following this on debian-user
does not come away with the wrong impression about the capabilities of one
of the packages in Debian. But let's take this elsewhere. You are most
welcome to continue this discussion directly with me. You could also
subscribe to the djbdns users' list at dns@cr.yp.to.
On Thu, 3 Jan 2002, Craig Sanders wrote:
> what's so difficult about bind's zone files or configuration files?
>
> they're simple, straight-forward, and intuitively obvious to anyone with
> a functioning brain. they're also extremely well-documented, with
> numerous books available (_DNS & Bind_ published by ORA being the
> "must-have" book for *any* DNS administrator)
All I said was that djbdns' config and data files are, IMHO, easier to
deal with than the ones for BIND. I never stated or implied that the BIND
files are obscure or incomprehensible. After all, I understood them when
I was using them, which definitely means that they are comprehensible to a
person with a definitely-no-better-than-average, occasionally functioning
brain :) But I wouldn't go as far as "intuitively obvious".
> in other words, it works for the single scenario of one domain and one
> set of IP addresses, with DNS for both hosted on the same server. fine
> for a leafnode site...no use at all for an ISP.
Er, no, it certainly works for setups more complex than that. You can
definitely have more than one subnet, more than one domain and host it all
on more than one server. I know. I do it. I don't run an ISP but my
net is definitely not a "toy" net.
I never claimed that djbdns can handle tens of tousands of domains, or run
an ISP. People who use it in that kind of setup (and they do exist) may
be able to make that claim, but not I. The original poster (remember
him?) wanted to do name resolution for his internal net and host a few
domains, which is exactly what I do, easily, securely and successfully
with djbdns.
> > You don't have to worry about keeping A and PTR records in sync.
>
> frankly, anyone who thinks that this is difficult should not be trusted
> to have anything to do with managing DNS.
No it's not difficult, but it's tedious. What's wrong with having the
option of a single-entry two-way map and making your life simpler?
Deleting files individually is also not difficult, but was that a reason
not to put recursive functionality into the rm command?
> a) the relationship between forward and reverse mapping(s) is completely
> arbitrary,
With djbdns, you can have your arbitrary A and PTR records, and you also
have a choice of a single entry that generates both:
# This maps address to name and name to address (both A and PTR records).
=a-name.my-domain:ipaddress1:TTL
# This maps name to address only (A record only).
+another-name-for-the-same-ip.my-domain:ipaddress1:TTL
# This maps a subdomain of in-addr.arpa to a name only (PTR record only).
^reversenetaddress.in-addr.arpa:another-name.mydomain:TTL
> b) the .in-addrp.arpa zone isn't always hosted on the same server as the
> forward zone(s) - it isn't at all unusual for a NS which is
> authoritative for a domain to NOT be authoritative for any corresponding
> .in-addr.arpa domain(s).
So if the servers are running djbdns, one of them will host the data for
the domain(s), which will consist of forward mappings only (lines in the
data file starting with +), and the other will host the data for the
subdomains of in-addr.arpa, which will consist of reverse mappings only
(lines starting with ^). It can be done. It's simple.
> leafnode sites may have simple configurations which suit djb's
> assumptions but they're also the sites *least* likely to be
> authoritative for the .in-addr.arpa zones for their IP addresses...most
> leafnode sites don't own their own addresses, they rent or borrow them
> from their ISP.
As I illustrate above, djb doesn't assume that the forward domains and the
subdomains of in-addr.arpa are hosted on the same server.
With djbdns, you can have your forward and in-addr.arpa data in separate
places, *if you need to*.
But for domains where both the forward and in-addr.arpa data can be hosted
on the same server, djbdns gives you the option of a single-entry two-way
(A and PTR) map.
> no, it is NOT open source. the source may be available but it doesn't
> meet the criteria of the Open Source Definition, which requires that the
> source code be freely modifiable and redistributable AND that binaries
> compiled from modified sources be redistributable.
Point taken. Sorry, I meant that the source is available so you can make
and distribute patches to it.
> the rest of the unix world got sick of hunting for obscure patches to
> programs ages ago - hunt for the original source, then hunt for half a
> dozen patches to fix various problems or add required features and hope
> that the patches will actually apply cleanly without any conflict. that
> was the way we had to do things back in the bad old days. it sucked
> then, and it still sucks now.
Yes it does suck if you *have* to apply patches. But you only need them
if you need features not included in the core djbdns distribution. I
humbly submit that for the needs of the original poster, and for the
majority of Debian users who need a nameserver, no patches are needed.
Again, let's take this elsewhere.
Best regards,
| George Karaolides 8, Costakis Pantelides St., |
| tel: +357 99 68 08 86 Strovolos, |
| email: george@karaolides.com Nicosia CY 2057, |
| web: www.karaolides.com Republic of Cyprus |
Reply to: