Re: Securing bind..
[ The quoted email is dated last December... I hope nobody minds me ]
[ reviving the conversation. I'm catching up on a few mail groups. ]
Russell == Russell Coker [EMAIL PROTECTED] writes:
Russell On Sun, 30 Dec 2001 16:17, Jor-el wrote:
On Sun, 30 Dec 2001, Russell Coker wrote:
Also don't allow recursion from outside machines.
Why does this help?
Russell When someone sends a recursive query to your server then they know
(with a
Russell good degree of accuracy) what requests are going to be made by
that server
Russell and what responses will be expected. So you can send a recursive
query for
Russell www.microsoft.com, then send a dozen packets appearing to be
responses from
Russell the Microsoft DNS servers giving an IP address of one of your
servers. While
Russell you're at it you make sure that the false packets you sent had
long TTL
Russell entries so that they stay in the cache for a while. Then suddenly
you have
Russell all clients of that DNS server thinking that the MS servers are on
your IP
Russell addresses (with lots of potential for abuse).
{Internal network}[firewall/gateway router]-+{Internet}
|
+---[Nameserver]
The nameserver is configured to allow recursive queries only from
hosts coming from inside, through the firewall/gateway router (Linux
2.4 w/iptables). What if someone on the internal network trys to
poison the DNS like this? They could be a student on a school
network, a contract employee, a misbehaving full timer, or whatever.
To prevent that, you should have some sort of egress filtering on
the firewall router, to prevent DNS replies (spoofed) from being
sent out through the gateway.
That still does not prevent them from logging into an outside host
they own -- their home computer, a co-located machine someplace out
on the net -- and sending the spoofed responses from there.
My question is; is this scenario possible, and is there any way to
prevent it from occuring?
Russell Recursive requests go to port 53 (getting a DNS client to even
talk to
Russell another port is difficult or impossible depending on the client).
Russell iptables/ipchains blocks access to port 53 from untrusted IPs (IE
everything
Russell outside your LAN or dialup pool).
But then how will anyone on the network access your domain's primary
name server?
Russell Bind will not be expecting any data other than replies to it's
requests on
Russell port 54 (the port that is open to the outside world) so even if
you screw up
Russell in your configuration of bind to not allow recursion from the
outside world
Russell you're still protected.
But it's an inside job. By an expert. How do I win the chess game
then?
Russell Smart people NEVER rely on only one layer of protection if they
can avoid it.
And they never rely solely on their OWN knowledge and experience.
--
mailto: (Karl M. Hegbloom) [EMAIL PROTECTED]
Free the Software http://www.debian.org/social_contract
http://www.microsharp.com
phone://USA/WA/360-260-2066
Re: Securing bind..
On Wed, 6 Mar 2002 19:04, Karl M. Hegbloom wrote:
[ The quoted email is dated last December... I hope nobody minds me ]
[ reviving the conversation. I'm catching up on a few mail groups. ]
OK, but I've trimmed the CC list.
Russell == Russell Coker [EMAIL PROTECTED] writes:
Russell On Sun, 30 Dec 2001 16:17, Jor-el wrote:
On Sun, 30 Dec 2001, Russell Coker wrote:
Also don't allow recursion from outside machines.
Why does this help?
[snip my description of the classic cache poisoning attack]
{Internal network}[firewall/gateway router]-+{Internet}
+---[Nameserver]
The nameserver is configured to allow recursive queries only from
hosts coming from inside, through the firewall/gateway router (Linux
2.4 w/iptables). What if someone on the internal network trys to
poison the DNS like this? They could be a student on a school
network, a contract employee, a misbehaving full timer, or whatever.
That is a problem. Also there's a problem if they send you email and doing a
reverse lookup of the origin IP address, resolving the header address as part
of spam filtering, or looking up the MX record for a bounce results in a DNS
query to a poisoning server.
To prevent that, you should have some sort of egress filtering on
the firewall router, to prevent DNS replies (spoofed) from being
sent out through the gateway.
That still does not prevent them from logging into an outside host
they own -- their home computer, a co-located machine someplace out
on the net -- and sending the spoofed responses from there.
That's right.
My question is; is this scenario possible, and is there any way to
prevent it from occuring?
Get your name server to only accept replies to your exact queries and no
extra data.
I'm not sure which DNS servers support this.
Russell iptables/ipchains blocks access to port 53 from untrusted IPs
(IE everything Russell outside your LAN or dialup pool).
But then how will anyone on the network access your domain's primary
name server?
Have a different instance of your name server process for primary zones than
the one used for caching. That's standard policy on most large installations
anyway, for performance if for nothing else.
But it's an inside job. By an expert. How do I win the chess game
then?
Get a better name server that doesn'thave this flaw.
--
If you send email to me or to a mailing list that I use which has 4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.
Re: Securing bind..
quote who=Karl M. Hegbloom
[ The quoted email is dated last December... I hope nobody minds me
] [ reviving the conversation. I'm catching up on a few mail
groups. ]
{Internal network}[firewall/gateway router]-+{Internet}
|
+---[Nameserver]
The nameserver is configured to allow recursive queries only from
hosts coming from inside, through the firewall/gateway router
I don't know about others, I run about maybe 15 or 20 nameservers,
and in all cases, if there is a firewall, I run a dedicated nameserver
for public queries and another for private. My home network
is the most basic setup, my firewall (P3-800 1GB), is also many
other things including NAT/SMTP/IMAP/DNS/ETC. I have 2 copies
of bind running, 1 I have set to bind to 127.0.0.1 and 10.10.10.1 (my
internal addresses), and another copy set to bind to 216.39.174.24(my
external address). Most of this is because there is stuff I have
resolvingon my internal LAN (including stuff that goes accross a vpn to my
work) that I do not want outsiders to resolve.
so, its just easier for me then trying to setup something based
on query source to just bind to an IP that is not routable
past the firewall ..
on my networks at work, I have all machines operating behind
static (1:1) NAT. So if i wanted to i could put a buncha stuff out
there in the wild, but I don't have to route the IP from the internet
to the machine if I don't want to. Cisco's ipnat functions work
quite well. Though they take up a lot of CPU, my 2500s can
just barely keep up with a single t1 going full blast in and out
full duplex, cpu goes to 100%. if its full blast in one direction cpu
is at 50%.
nate
Re: Securing bind..
On Thu, Jan 03, 2002 at 03:34:32PM +0100, martin f krafft wrote: (...) but more importantly, if the question was how to secure bind, then let's not secure it by substituting... bind is still the #1 nameserver, and a thread like this (even though argued a million times) can be quite informative. The way to avoid this kind of threads over and over again is to *document* them. I find that there are quite a number of people willing to answer emails in the list but not willing to take some time and *write* about it. If anyone feels like writting a few paragraphs on how to secure BIND, improving the existing documentation (of course, the Debian Security HOWTO), feel free to send me any material worth adding. Regards Javi
Re: Securing bind..
BIND should be treated with the utmost caution, as CERT has listed it as the #1 way to break into a computer and Im sure some of us have had k1dd13z on our systems because of it. I know I have seen this discussion before in old USENET posts, but I do think it would be a good idea to maybe include a debconf option that lets the user choose whether or not BIND would run as root. That way, upgrades of BIND could respect the setup and users could have safer defaults on their system. Even if that doesn't happen, I think that should be in the Security HOWTO. -A. Dave Javier Fernández-Sanguino Peña wrote: On Thu, Jan 03, 2002 at 03:34:32PM +0100, martin f krafft wrote: (...) but more importantly, if the question was how to secure bind, then let's not secure it by substituting... bind is still the #1 nameserver, and a thread like this (even though argued a million times) can be quite informative. The way to avoid this kind of threads over and over again is to *document* them. I find that there are quite a number of people willing to answer emails in the list but not willing to take some time and *write* about it. If anyone feels like writting a few paragraphs on how to secure BIND, improving the existing documentation (of course, the Debian Security HOWTO), feel free to send me any material worth adding. Regards Javi
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 [EMAIL PROTECTED] 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
Re: Securing bind..
Hi Martin, On Thu, 3 Jan 2002, martin f krafft wrote: snip djbdns data example i find this horrible. BIND zonefiles at least allow for usage of tabs to organize your zone into tabular data. Everyone has their favourite wokrkign techniques. You like your tabular BIND zone files. I like my line-based djbdns data files. Fine. I know there are management tools that automate synchronisation of forward and reverse mappings in BIND zone files, but why should the reverse-mapping information be in a file separate from the forward information? why does the DNS protocol even allow this? keeping them in sync is really what you should do, but there are cases, where they may need to be out of sync. for instance, domain.com and mail.domain.com for small domains usually get the same A record on my servers, if what i delegate to mydomain.com is a single IP address. that's not a CNAME, that's an A record. but what does the IP map to? *not* mail.domain.com. i find it very handy to have explicit control over the mappings. As I've written to Craig, you can do all this with djbdns. But where you can keep the foward and reverse data on the same server, djbdns allows you to make a single entry that takes care of both the A nd PTR record. I like the convenience of that, and the reduction of the potential for mistakes. priorities or preferences. i find BIND does it's job. it might not be optimal, but it's free, and it works. No arguments there. BIND is free. BIND works. But I suggested that with djbdns, you get the security by default that you have to configure into BIND, and that for a setup as needed by the original poster, djbdns could be easier to administer. djbdns might even be better, smaller, faster, more secure. but my nameservers are not going to be running a piece of software because of either of two reasons: (a) the author is braindead in many aspects; and (b) it's non-free. I use djbdns. It works. I can administer it. I didn't need to read a HOWTO about how to run it securely. It's packaged in Debian, and the above benefits are available to Debian users. Issues to do with its license and the brain-deadedness or otherwise of its author are off-topic so I agree with you; this discussion is best continued elsewhere. we'd like to package it, not require the end-user to download the -source package, which includes voodoo magic to compile djbdns without the user ever knowing what gcc is. the problem is that this is an aweful job for the maintainer, and that it requires some -dev libraries on the target system, as well as the entire gcc family, which might not be needed otherwise... This too finds me in perfect agreement. I would love it if djb would GPL his software. let's take this discussion somewhere else. As stated above, agreed. Best regards, | George Karaolides 8, Costakis Pantelides St., | | tel: +357 99 68 08 86 Strovolos, | | email: [EMAIL PROTECTED] Nicosia CY 2057, | | web: www.karaolides.com Republic of Cyprus |
Re: Securing bind..
also sprach P Prince [EMAIL PROTECTED] [2001.12.31.0652 +0100]: Perhaps, but BIND invented its own zonefiles too. What you fail to realize is how bad BIND zone files suck. why? sure, you have to understand them, and discipline is needed to maintain one, but they are so much more powerful than djb's files... they are explicit, and that's important. i tried djbdns and had to give up simply because it *couldn't* do a lot of the things that i need my BINDs to do... unfortunately, bernstein's software is severely limited by his views. he's a fairly good programmerbut a lousy systems administrator, with no concept of how real world sysadmins use tools or how they automate them. I hope you don't consider youself a good systems administrator, i hope you aren't always as negative. If conformance to standards is interesting to you, then check this out. djbdns does not conform to standards. he proudly ignored any aspects of the standards that were inconvenient to him. There is no RFC BIND!!! Christ, man... dude, noone ever spoke of a BIND RFC. but there are numerous RFCs around DNS, IXFR, and AXFR. kind of relevant to a nameserver, don't you think? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i am willing to make the mistakes if someone else is willing to learn from them. pgpQd9GLJr05U.pgp Description: PGP signature
Re: Securing bind..
also sprach P Prince [EMAIL PROTECTED] [2001.12.30.1846 +0100]: The eaisest and most failsafe way to secure bind is to install djbdns. you are kidding me, right? the question was how to secure bind. the asker wasn't in need of other religious beliefs. while i strongly believe that djb is a real pain and a man with many problems, his software is good. despite the license. and despite the configuration. qmail or djbdns, i find configuring postfix and bind9 to be a lot more straight forward than using djb's paradigm of touched files... but more importantly, if the question was how to secure bind, then let's not secure it by substituting... bind is still the #1 nameserver, and a thread like this (even though argued a million times) can be quite informative. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/IT d- s: a-- C++() UL+++() P+ L+++ E--- W- N+ o? K? !w O- M- V PS+(+++) PE-- Y+ PGP++ t- !5 !X R-(+) !tv b+(++) DI--(++) D++(+++) G(++) e++ h* r+++ :) y++(++) --END GEEK CODE BLOCK-- pgp4DnWqUcSeH.pgp Description: PGP signature
Re: Securing bind..
also sprach Russell Coker [EMAIL PROTECTED] [2001.12.30.2258 +0100]: Perhaps a discussion of the relative merits of djbdns and bind is in order. no, not on debian-user and not on debian-* either. djbdns might be fine software, but his author is a negative representative of the software industry in general, open source specifically. and he's probably the most arrogant and egocentric person i shall ever meet. don't discuss nameservers here. I disagree with the supposed security benefits of disabling zone transfers, it's just security by obscurity. Also when idiots read such advice and take it to heart it gets in the way when you have a genuine need for zone transfers. uhm. so are password. security through obscurity. what's your point? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i'd give my right arm to be ambidextrous. pgpB6MkQtIDRf.pgp Description: PGP signature
Re: Securing bind..
also sprach George Karaolides [EMAIL PROTECTED] [2002.01.02.1423 +0100]: # Nameserver for my network addesses... .my-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for addresses in my other network... .my-other-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for names in my domain... .my-domain:my-nameserver-ip-address:TTL # ... and for names in my other domain... .my-other-domain:my-nameserver-ip-address:TTL # Now to get on with mapping names to addresses, and vice versa =i-want-this-to-map-both-reverse-and-forward.my-domain:ipaddress1:TTL +i-only-want-this-to-map-forward-cos-its-an-alias.my-domain:ipaddess1:TTL =another-bothways-map.my-domain:ipaddress2:TTL +and-this-too-has-an-alias.my-domain:ipaddress2:TTL =a-bothways-map.my-other-domain:ipaddress3:TTL +an-alias.my-other-domain:ipaddress3:TTL Surely that's not all bad? i find this horrible. BIND zonefiles at least allow for usage of tabs to organize your zone into tabular data. sure, it requires a little thought at first, but in the end, you have aligned columns that are easy to search and modify. with djbdns, you are left with /bin/ls unless you provide a new tool that sort of abstracts above that structure... You don't have to worry about keeping A and PTR records in sync. how often do you worry about that in a productive environment? how often do you move your subnets around??? and aside, there are many tools that write BIND config files for you. i wrote one myself, which really just allows me to have 120 byte config files for a complete zone, and it's all in sync. i still maintain that BIND's zonefiles are much easier to read and understand than a directory with inode entries named in such a way so as to represent the most information in the least amount of space, and making sure that noone can understand what's going on by glancing at it. I know there are management tools that automate synchronisation of forward and reverse mappings in BIND zone files, but why should the reverse-mapping information be in a file separate from the forward information? Once the three conditions above areet, why should we need to administer the forward and reverse mappings separately? BTW these are not rhetorical questions; I'd love to hear input on this. why does the DNS protocol even allow this? keeping them in sync is really what you should do, but there are cases, where they may need to be out of sync. for instance, domain.com and mail.domain.com for small domains usually get the same A record on my servers, if what i delegate to mydomain.com is a single IP address. that's not a CNAME, that's an A record. but what does the IP map to? *not* mail.domain.com. i find it very handy to have explicit control over the mappings. In the end, it's all a question of priorities. If compatibility with existing config. and zone files is an issue, then djbdns may well be a non-starter, my recall that there's a way to get it to read BIND zone files notwithstanding. If managing a DNS name space painlessly, securely and reliably is, then it could well be. It was for me. priorities or preferences. i find BIND does it's job. it might not be optimal, but it's free, and it works. djbdns might even be better, smaller, faster, more secure. but my nameservers are not going to be running a piece of software because of either of two reasons: (a) the author is braindead in many aspects; and (b) it's non-free. For all the arguments against djb's attitude re. development and licensing, it must be acknowledged that his keeping tight control of the software has prevented it from suffering from feature bloat. well, as opposed to postfix, for instance, you are right. wietse dared to put RBL support into postfix. djb simply writes another program and then tells you how to integrate that. sure, it's unix philosophy... nevertheless, between postfix and qmail, i'd say i'll install postfix from source in a fifth of the time as i'd need for qmail with all it's features. and i can't really see how that could change for BIND/djbdns... And since it's open-source and you can distribute patches to it, there's no shortage of patches to get it to do what you want. we'd like to package it, not require the end-user to download the -source package, which includes voodoo magic to compile djbdns without the user ever knowing what gcc is. the problem is that this is an aweful job for the maintainer, and that it requires some -dev libraries on the target system, as well as the entire gcc family, which might not be needed otherwise... let's take this discussion somewhere else. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] the only real advantage to punk music is that nobody can whistle it. pgp05BeBwxuCk.pgp Description: PGP signature
Re: Securing bind..
also sprach P Prince [EMAIL PROTECTED] [2001.12.30.2314 +0100]: I strongly *strongly* suggest that anyone considering setting up DNS, be it BIND or djbdns, check out Daniel Bernstein's site on the subject, http://cr.yp.to/djbdns.html or just subscribe to bind-users or bind9-users, where bernstein will sit and reply to every problem someone asks about: this would not be the case with djbdns, or see how easy this is with djbdns... sorry, but that form of behaviour, IMHO, belongs into kindergarten. look at his site, how he compares why djbdns is better than BIND. and then compare how he and wietse venema go about their functionally equivalent and absolutely comptetive products qmail and postfix. djb has more than simple problems with his ego... 2.4.x kernels support the --bind option to mount which avoids the syslogd hackery described in this URL. Also the authbind method supported by Debian is much more powerful and useful than using the chuid() functionality in bind. Both these things aren't mentioned. because 2.4.x kernels are far from stable, no real sysadmin would use them on a productive nameserver, and because the paper isn't about debian. but do tell about authbind. where do i get info? I disagree with the supposed security benefits of disabling zone transfers, it's just security by obscurity. Also when idiots read such advice and take it to heart it gets in the way when you have a genuine need for zone transfers. What is wrong with security by obscurity? It's an excellent strategy, albeit not a complete one. yes, precisely. it's not a universal security method, but it's also wrong to believe what the rest of the world seems to believe: that security through obscurity is bad because unsafe. bollocks. you must not rely on it ever, but it's always a nice addition. or else, seriously, we'll have to make way without one-time passwords... now *that* would suck. zone transfers are not that much of a deal, i find, unless of course you have a huge zone and want to minimize volume. i stand behind the opinion that you should be able to post a complete topology of your company network, along with all DMZs, server configurations, firewall rules, and other information onto the net. that's zero security by obscurity then, but your network must still be able to withstand all attacks. once you reached that status, it doesn't hurt to hide information from others. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] you grabbed my hand and we fell into it, like a daydream - or a fever. -- godspeed you black emperor pgpClzO006yGm.pgp Description: PGP signature
Re: Securing bind..
Hi, On Tue, 1 Jan 2002, Craig Sanders wrote: someday soon, someone's going to take the good ideas from djbdns, combine it with the good stuff from bind (including backwards compatibility with bind config zonefile formats), add a few useful new ideas (e.g. an RXFR protocol that embedded the rsync protocol directly) to produce a fast, secure DNS daemon, and release it with a GPL-compatible license. this will blow both bind djbdns out of the water. Roll on the day! When such a godsend appears, I'll grab it with both hands, provided of course that besides reverse compatibility with BIND config. files, it also gives you a new, simpler config. scheme. In the meantime, I submit that djbdns is OK unless you really, really want to stick to the BIND zonefile format, though I seem to recall hearing it can be made to read BIND zone files. IMHO once you're used to it, the djbdns data file format is actually quite nice. I've worked on both BIND and djbdns and I find the latter easier to use. For example, the following ten entries would require four entries in named.conf and four zone files: # Nameserver for my network addesses... .my-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for addresses in my other network... .my-other-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for names in my domain... .my-domain:my-nameserver-ip-address:TTL # ... and for names in my other domain... .my-other-domain:my-nameserver-ip-address:TTL # Now to get on with mapping names to addresses, and vice versa =i-want-this-to-map-both-reverse-and-forward.my-domain:ipaddress1:TTL +i-only-want-this-to-map-forward-cos-its-an-alias.my-domain:ipaddess1:TTL =another-bothways-map.my-domain:ipaddress2:TTL +and-this-too-has-an-alias.my-domain:ipaddress2:TTL =a-bothways-map.my-other-domain:ipaddress3:TTL +an-alias.my-other-domain:ipaddress3:TTL Surely that's not all bad? You don't have to worry about keeping A and PTR records in sync. In fact, you don't have to worry about subdomains of in-addr.arpa at all, beyond making sure that your clients are querying the right servers (which you'd do anyway), that any delegations to your server are done correctly by your parent (ditto) and that your data includes a nameserver entry for the appropriate in-addr.arpa subdomains (again ditto). I know there are management tools that automate synchronisation of forward and reverse mappings in BIND zone files, but why should the reverse-mapping information be in a file separate from the forward information? Once the three conditions above are met, why should we need to administer the forward and reverse mappings separately? BTW these are not rhetorical questions; I'd love to hear input on this. Myself, I haven't thought about any subdomain of in-addr.arpa since installing djbdns, besides the three points mentioned above. In the end, it's all a question of priorities. If compatibility with existing config. and zone files is an issue, then djbdns may well be a non-starter, my recall that there's a way to get it to read BIND zone files notwithstanding. If managing a DNS name space painlessly, securely and reliably is, then it could well be. It was for me. For all the arguments against djb's attitude re. development and licensing, it must be acknowledged that his keeping tight control of the software has prevented it from suffering from feature bloat. And since it's open-source and you can distribute patches to it, there's no shortage of patches to get it to do what you want. Heppy new year, | George Karaolides 8, Costakis Pantelides St., | | tel: +357 99 68 08 86 Strovolos, | | email: [EMAIL PROTECTED] Nicosia CY 2057, | | web: www.karaolides.com Republic of Cyprus |
Re: Securing bind..
On Wed, Jan 02, 2002 at 03:23:01PM +0200, George Karaolides wrote: On Tue, 1 Jan 2002, Craig Sanders wrote: someday soon, someone's going to take the good ideas from djbdns, combine it with the good stuff from bind (including backwards compatibility with bind config zonefile formats), add a few useful new ideas (e.g. an RXFR protocol that embedded the rsync protocol directly) to produce a fast, secure DNS daemon, and release it with a GPL-compatible license. this will blow both bind djbdns out of the water. Roll on the day! When such a godsend appears, I'll grab it with both hands, provided of course that besides reverse compatibility with BIND config. files, it also gives you a new, simpler config. scheme. 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) In the meantime, I submit that djbdns is OK unless you really, really want to stick to the BIND zonefile format, or unless you need something more than what djbdns's simplistic limitations can provide. though I seem to recall hearing it can be made to read BIND zone files. IMHO once you're used to it, the djbdns data file format is actually quite nice. I've worked on both BIND and djbdns and I find the latter easier to use. For example, the following ten entries would require four entries in named.conf and four zone files: that would be because there's actually four different zones involved. four zones == four config entries, four zone filesnot one file and a bunch of half-arsed assumptions. # Nameserver for my network addesses... [djbdns config example deleted] Surely that's not all bad? yes. there's too much magic - i.e. fixed assumptions that may or may not actually correspond to what you need. in other words, if what you need is *exactly* what DJB in his infinite wisdom has catered for then you'll have no problem. if you need something even slightly different then you're screwed...and don't bother complaining or asking to be accomodated because that's just evidence that you're an idiot. 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. i.e. djbdns is only a toy, and something that works fine at the toy end of the scale doesn't necessarily work at all when you need to scale it up to a professional system catering for hundreds or thousands of domains. 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. I know there are management tools that automate synchronisation of forward and reverse mappings in BIND zone files, but why should the reverse-mapping information be in a file separate from the forward information? Once the three conditions above are met, why should we need to administer the forward and reverse mappings separately? because : a) the relationship between forward and reverse mapping(s) is completely arbitrary, and 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). 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. For all the arguments against djb's attitude re. development and licensing, it must be acknowledged that his keeping tight control of the software has prevented it from suffering from feature bloat. prevents it from suffering from features too. even worse, it prevents anyone other than djb from fixing or enhancing it. And since it's open-source 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. and you can distribute patches to it, there's no shortage of patches to get it to do what you want. 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. OTOH, djb thinks
Re: Securing bind..
On Mon, Dec 31, 2001 at 12:52:23AM -0500, P Prince wrote: there are two major problems with all of bernstein's software. the first is that it requires you to throw away your existing configuration...no big deal for a caching only name-server or if you only have one or two domains to serve. a severe pain in the arse if you have hundreds or thousands of domains. This is crazy. Anytime you change software packages, you must rewrite your configuration. it's not at all crazy to expect a new package which is supposed to replace an existing service to provide some level of backwards compatibility in order to facilitate the migration. if not compatibility with the config or zonefile format, then at the very least it should provide a 100% accurate automated translator. djb refuses to understand that software migrations need to be planned, they need to work smoothly with minimum fuss and minimum downtime, and that backwards-compatibility with existing standards (de-facto or otherwise) is mandatory. what he thinks of as legacy crap that should be thrown away is actually working configuration that is serving the needs of hundreds or thousands of users, all of whom will be extremely pissed off if it stops working for a few days because of migration difficulties. until he understands this, most professional systems administrators are going to ignore his code no matter how superior it is theoretically. theoretical superiority is completely worthless in the face of practical inability to use it. i won't use his software for this reason, and because it's non-free. both issues are show-stoppers as far as i'm concerned. And, if you or anyone you know manages thousands of domains, I'll mail you a crisp, clean 20 dollar bill. (In order to be eligible, you must provide the name of your employer, so that I can avoid their service.) i manage hundreds of domains myself. around 700 primary domains and around 950 secondaries. i know several people who manage thousands of domains. not everyone has tiny toy systems to design, develop, and manage. some people have real systems to look after. and you know what? even though i don't personally look after tens of thousands of domains, or know anyone who does, i'm still able to recognise that someone, somewhere might do exactly that and not dismiss the idea as crazy or ridiculous. i can actually imagine a world bigger than my current immediate needs. named.conf doesn't work with djbdns - a minor problem. This is a stupid argument. httpd.conf doesn't work well with thttpd, and proftpd.conf doesn't work well at all with wu-ftpd. as i said, named.conf is only a minor problem. it doesn't matter much. the real problem is that bind's zone files don't work with djbdns. that's beyond a mere problem, that's idiotic. more importantly, bind style zonefiles don't work with djbdns - the idiot invented his own stupid format for zone files. if djbdns had been backwards-compatible with bind zonefiles then it might have had some vague chance of replacing bind. Perhaps, but BIND invented its own zonefiles too. What you fail to realize is how bad BIND zone files suck. yes, i do fail to realise that because they don't suck. what, exactly, is wrong with them? unfortunately, bernstein's software is severely limited by his views. he's a fairly good programmerbut a lousy systems administrator, with no concept of how real world sysadmins use tools or how they automate them. I hope you don't consider youself a good systems administrator, i do, actually. i'm only a mediocre programmer, but i'm a damn good systems admin - which requires a completely different set of skills and aptitudes than programming. i've only met a few people who are as good as me at systems admin stuff, and even fewer who are better. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Securing bind..
quote who=P Prince This is crazy. Anytime you change software packages, you must rewrite your configuration. And, if you or anyone you know manages thousands of domains, I'll mail you a crisp, clean 20 dollar bill. (In order to be eligible, you must provide the name of your employer, so that I can avoid their service.) even if you don't change software packages you may have to rewrite the config. i remember now when bind 8.2.3 or 8.3.2 or whatever came out about 2 years ago and they started enforcing a new configuration change, was it the $TTL at the top of the zone file? argh it caused so many problems. i would not expect such a change to be required in such a minor revision of the software. i know it broke several dozen of my domains for about a week while i tried to track down what was wrong with it. and i think the kicker to upgrade was a security problem in the previous version so i rushed to upgrade, only to later find it break almost everything :( besides that though, bind has been pretty good to me. it can be a chore to setup securely though.(at least under debian 2.2) nate
Re: Securing bind..
Russell Coker wrote: DNS cache machine sents out requests from source port 54 (not obscure - every administrator of every DNS server on the net can easily discover this). Recursive requests go to port 53 (getting a DNS client to even talk to another port is difficult or impossible depending on the client). By forcing the source port for recursive requests to a given fixed one, do you not make yourself more vulnerable to the spoofing attacks you were talking about, because the attacker does not have to predict the source port of the query ? -- Thomas Seyrat.
Re: Securing bind..
On Mon, 31 Dec 2001 05:31, Jor-el wrote: DNS cache machine sents out requests from source port 54 (not obscure - every administrator of every DNS server on the net can easily discover this). Not sure I follow what you are saying here. Are you saying that it is pretty easy for a DNS admin to figure out what port you are running the DNS server on (if so how?) or are you saying that port 54 is a well agreed upon port for this purpose. I doubt very much that it is the latter, since http://www.iana.org/assignments/port-numbers states that port 54 is assigned to XNS (whatever that is). When a request has a source port of 54 the reply MUST have a destination port of 54. A DNS request is allowed to have any address as a source address (as the client program may be a non-root application which gets the first UDP port it can find which will be somewhat random). The ability to configure which source port is used for queries is a newer feature in bind (wasn't there in 4.x at least - not sure when it was added). Having the same port used for sending out queries and receiving queries from other machines (pretty much a default setup) just makes things more difficult to manage, secure, and analyse. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
On Mon, 31 Dec 2001 01:20, jernej horvat wrote: On Sunday 30 December 2001 22:58, Russell Coker wrote: 2.4.x kernels support the --bind option to mount which avoids the syslogd yep. linux v2.4.x and bind v9.x are easier to set up. debian has almost out-of-the box chroot solution. Are the root servers using bind9 yet? I disagree with the supposed security benefits of disabling zone transfers, Why? Do you need the whole zone when you just need to resolve one host or IP ? Sometimes getting a copy of the zone helps to discover problems. Do you give away all your personal data when someone asks you for your name ? I give away data that's publically available anyway. If data isn't public then it shouldn't be in a public place such as a DNS zone file. Knowing which IP addresses are in use is no secret, you can always check on IP address block assignments and scan them all. And this is what djb has to say for zone transfers :-) Zone transfers are an archaic alternative mechanism for copying DNS information. When djb starts releasing his software under better license agreements that make it realistically possible to use it, and when he makes his software interoperate better with the rest of the world then people will take more notice of him. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
On Mon, 31 Dec 2001 06:52, P Prince wrote: there are two major problems with all of bernstein's software. the first is that it requires you to throw away your existing configuration...no big deal for a caching only name-server or if you only have one or two domains to serve. a severe pain in the arse if you have hundreds or thousands of domains. This is crazy. Anytime you change software packages, you must rewrite your configuration. If two programs perform the same task then why can't they use the same config file? Writing a program to support two different formats of config file isn't so difficult. And, if you or anyone you know manages thousands of domains, I'll mail you a crisp, clean 20 dollar bill. (In order to be eligible, you must provide the name of your employer, so that I can avoid their service.) Please mail a $20 bill to Craig and one to me as well. While working for Versatel Telecom BV in Amsterdam I was running the 24hoursnet service. That service had over 4000 domains setup in bind (with scripts to create bind zone files from LDAP). Why would you want to avoid such a service? It doesn't make sense for every small company that wants a web site to have to run their own DNS etc. It makes sense for a telco to run the sites for thousands of small companies, telcos can afford to pay people such as Craig and myself to run their servers in a reliable and secure fashion instead of having the secretary try to setup a set of ISP servers (with all the security and reliability problems you'd expect). Broken as many of them are, they still work quite well with djbdns, thank you. named.conf doesn't work with djbdns - a minor problem. This is a stupid argument. httpd.conf doesn't work well with thttpd, and proftpd.conf doesn't work well at all with wu-ftpd. Consider mail servers. Currently there is a range of mail servers that can deliver to /var/mail/user-name or ~/Maildir/ storage and which honour .forward files, Postfix being a good example. I can change a Postfix installation to use Procmail for delivery and it'll deliver mail in the same way. If I choose to switch from Postfix to another server then it's not difficult to find another server using .forward files and /etc/aliases etc (NB Qmail does not do this). Then there's about 6 POP servers and about 3 IMAP servers I can choose from (actually there's probably more, I'm just thinking of ones I've used or heard good reports about) which all use the same data store. Contrast this to using Cyrus, Netscape iPlanet mail server, Exchange, Notes, or another mail server which has it's own strange and unique format for everything. an additional part of the price you pay is djb's moronic non-free software license Really? http://cr.yp.to/distributors.html yes, really. non-free. if you don't understand WHY it's non-free then read the DFSG again. This doesn't deserve a response. There is no response. DJB software is not in Debian for a reason... To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] PS When quoting messages please trim out the .sig lines etc. It just wastes bandwidth and doesn't gain anything. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
On Mon, 31 Dec 2001, Petre Daniel wrote: thank you all very much. you're right.if one doesn't have anything useful to say i'll recommand him to let others help.. thx guys. Hi Petre, Maybe the initial suggestion to use djbdns wasn't worded in the best possible way, but might I suggest that you consider the possibilities djbdns, which could perhaps make your life a bit simpler? Your requirement was for a DNS server which does name resolution for clients on your internal net and serves out names for a few .ro domains to the Internet at large. So here are my points: - djbdns comes with the security features you require out of the box. - Yours does not sound like a large and complex setup with years of BIND configuration development behind it, so you have little to lose if you do try djbdns. - In my experience, it is very easy to set up a system like the one you describe using djbdns. - It also sounds like you're busy enough, so In My Humble Opinion(tm) you will save time administering djbdns. Sources of djbdns debs: potato: Gerrit Pape has some unofficial debs at the following apt source: deb ftp://ftp.innominate.org/pub/pape/Debian potato unofficial innominate apt-get install djbdns woody or sid: There are official installer packages: apt-get install djbdns-installer If you do decide to try it out, then I am at your disposal to help with any setup queries you may have. Best regards and a happy new year, | George Karaolides 8, Costakis Pantelides St., | | tel: +357 99 68 08 86 Strovolos, | | email: [EMAIL PROTECTED] Nicosia CY 2057, | | web: www.karaolides.com Republic of Cyprus |
Re: Securing bind..
* Craig Sanders ([EMAIL PROTECTED]) spake thusly: ... unfortunately, bernstein's software is severely limited by his views. he's a fairly good programmerbut a lousy systems administrator, with no concept of how real world sysadmins use tools or how they automate them. Did he finally figure out how to use subdirectories in his source tree? Dima (just curious) -- The wombat is a mixture of chalk and clay used for respiration. -- MegaHal
Re: Securing bind..
On Mon, Dec 31, 2001 at 04:15:18AM +0100, jernej horvat wrote: On Monday 31 December 2001 03:34, Michael D. Schleif wrote: http://cr.yp.to/distributors.html Because of that policy there are no precompiled packages of djbdns, because: You may distribute a precompiled package if - installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above etc. Free? If you are pleased with chasing the complexities inherent in overly complex tools, then, please, keep them uptodate . . . compiling the whole package [1], installing it in paths that djb thinks are ok. complex? [...] there is an alternative = http://dnrd.nevalabs.org/ An interesting thing about djb is he does have knack for identifying real problems with existing defacto standard software and re-inventing it. What then follows is fierce flamewars about the relative merits of the old vs djb software/licence/etc. In summary the djb implementation is full of good ideas and raises valid concerns about the original implementation, but is crippled by a crappy licence, disrespect for standards, and wierd configuration paradigm. Eventually, this leads to yet another implementation or three that takes djb's ideas and addresses the licence, standards, and configuration issues. sendmail - qmail - postfix,exim,etc bind - djbdns - ?? The sad thing is if djb stopped using his crappy licence, there would be no need for the n+1 implementations his re-invention spawns, because the community could adopt his software and resolve the other issues to their own satisfaction. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Securing bind..
On Tue, Jan 01, 2002 at 01:18:43PM +1100, Donovan Baarda wrote: An interesting thing about djb is he does have knack for identifying real problems with existing defacto standard software and re-inventing it. he also reinvents things that don't have any significant problems, sometimes just because he won't admit that a particular programmer has ever done anything of worth. ucspi-tcp, for example...this abomination is a clumsy mess compared to the inetd + tcpd that everyone else uses. What then follows is fierce flamewars about the relative merits of the old vs djb software/licence/etc. In summary the djb implementation is full of good ideas and raises valid concerns about the original implementation, but is crippled by a crappy licence, disrespect for standards, and wierd configuration paradigm. well said! Eventually, this leads to yet another implementation or three that takes djb's ideas and addresses the licence, standards, and configuration issues. while it's true that he's sometimes the first to actually write code to provide alternative implementations (and action is worth a lot more than mere talk), it's not true that they're solely his ideas. people had been bitching about sendmail for many years before qmail came along, many of the flaws (both implementation detail AND design) were well known. The sad thing is if djb stopped using his crappy licence, there would be no need for the n+1 implementations his re-invention spawns, because the community could adopt his software and resolve the other issues to their own satisfaction. well said, again. you've hit the nail right on the head. while his stuff can often be used as a sign-post pointing out directions to take (and to avoid), but it can't be used unless you're willing to trap yourself into a dead-end...i almost fell into that trap with qmail (actually did on a few servers), but won't fall for it again. djb's software isn't free, and can't/won't evolve to meet future needs. someday soon, someone's going to take the good ideas from djbdns, combine it with the good stuff from bind (including backwards compatibility with bind config zonefile formats), add a few useful new ideas (e.g. an RXFR protocol that embedded the rsync protocol directly) to produce a fast, secure DNS daemon, and release it with a GPL-compatible license. this will blow both bind djbdns out of the water. ...kind of like postfix did to sendmail qmail. i had high hopes for the DENTS project a few years back they looked like they were really going to solve many of bind's problems, and their stuff was GPLed. it got off to a great start but unfortunately, the project seems to have died. maybe there's still some hope...sourceforge lists several DNS daemon projects: http://sourceforge.net/softwaremap/trove_list.php?form_cat=149discrim=238 moodns CustomDNS are two that i hadn't heard of before. moodns sounds a bit like what DENTS was going to be. CustomDNS is in java so i can't bring myself to take it seriously. La MaraDNS i looked at about a year ago and it has an even dumber zonefile format than djbdns (if that's possible). craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Securing bind..
Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200
Re: Securing bind..
quote who=Petre Daniel Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. i ran a search for dos in my recent debian-user archives and did not come up with anything(related), which DOS attack? i monitor bugtraq and vuln-dev closely and have not seen any mention of bind for a REAL long time. i run BIND 8 as all my nameservers. i change the configuration from what debian has significantly. everything resides under /etc/bind. everything is chowned named.named everything is readable by only user named/group named. named runs in chroot in /etc/bind and runs as user named group named. i restrict zone transfers to authorized servers only. if needed(like on a firewall or gateway), i have it bind to a specific interface(the internal one, or the loopback or both depending on your needs). more recently i have started working with syslog-ng and remote logging, i configured syslogd on the debian systems to create a log socket inside the bind chroot enviornment so i can send the named logs to the syslog server(because it cannot access /dev/log otherwise). before that i had bind log to a file inside the chroot enviornment. bind has worked good for me for years. if its configured good it can be quite secure. i reccomend the book from oreilley(sp?) DNS Bind, thats where i initially learned about the chroot and running as non root uid/gid and access lists. the information is elsewhere as well but i found that book very interesting and useful. you can go farther by restricting queries via access lists as well, but this(in my experience) will break any nameserver that is primary or secondary for a domain, as nobody but those in the access lists will be able to query for the domain info. useful for the more paranoid in a caching-only enviornment(or at least a non-public DNS). hope this helps! nate
Re: Securing bind..
On Sun, 30 Dec 2001 11:18, Petre Daniel wrote: Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Which DOS attack are you referring to? For making bind secure I suggest running it as non-root using authbind and build your kernel with OpenWall, LSM, or GRSecurity so that stack overflows don't get anywhere. Then have a script to restart it if it dies. Also don't allow recursion from outside machines. Another possibility is to have the port for outgoing connections be something other than 53 (54 seems unused) and use iptables or ipchains to block data from the outside world coming to port 53. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
Hello Nate,it seems i cant get the link of the advisory.Its about some sort of amplyfing flood,when an ousider makes spoofed queries to the bind daemon and another one ,the victim is flooded along with me the attacked.. Thx.. At 02:56 AM 12/30/01 -0800, nate wrote: quote who=Petre Daniel Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. i ran a search for dos in my recent debian-user archives and did not come up with anything(related), which DOS attack? i monitor bugtraq and vuln-dev closely and have not seen any mention of bind for a REAL long time. i run BIND 8 as all my nameservers. i change the configuration from what debian has significantly. everything resides under /etc/bind. everything is chowned named.named everything is readable by only user named/group named. named runs in chroot in /etc/bind and runs as user named group named. i restrict zone transfers to authorized servers only. if needed(like on a firewall or gateway), i have it bind to a specific interface(the internal one, or the loopback or both depending on your needs). more recently i have started working with syslog-ng and remote logging, i configured syslogd on the debian systems to create a log socket inside the bind chroot enviornment so i can send the named logs to the syslog server(because it cannot access /dev/log otherwise). before that i had bind log to a file inside the chroot enviornment. bind has worked good for me for years. if its configured good it can be quite secure. i reccomend the book from oreilley(sp?) DNS Bind, thats where i initially learned about the chroot and running as non root uid/gid and access lists. the information is elsewhere as well but i found that book very interesting and useful. you can go farther by restricting queries via access lists as well, but this(in my experience) will break any nameserver that is primary or secondary for a domain, as nobody but those in the access lists will be able to query for the domain info. useful for the more paranoid in a caching-only enviornment(or at least a non-public DNS). hope this helps! nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200
Re: Securing bind..
hi ya petra lots of different kind of floods...and DoS attacks... what kind of attack are oyu under ??? -- what shows up in tcpdump when monitoring all traffic on the wire ??? if you're an amplifier .. you have to turn off icmp broadcasts at your incoming cisco router/fw to test if you are a smurf amplifier.. see the links at http://www.Linux-Sec.net/harden/smurf.fix.txt to test your DNS config http://www.Linux-Sec.net/Audit/audit_tools.gwif.html#DNS to harden your dns servers... and spoof protecting etc .. http://www.Linux-Sec.net/Harden/server.gwif.html#DNS and lot of other stuff to harden too in addition to dns http://www.Linux-Sec.net/Harden/ have fun alvin On Sun, 30 Dec 2001, Petre Daniel wrote: Hello Nate,it seems i cant get the link of the advisory.Its about some sort of amplyfing flood,when an ousider makes spoofed queries to the bind daemon and another one ,the victim is flooded along with me the attacked.. Thx..
Re: Securing bind..
thankz a lot. Well the thing is,after i've read that advisory,2 days laterz my network was flooded,like the the traffic was very slow and nothing resolved anymore.. I noticed the stranged thing that the main ns/mailserver (bind 9.1)had difficulties resolving things around,even internally,so mail was kindof blocked.. Thx for links.. its Daniel.. At 06:12 AM 12/30/01 -0800, Alvin Oga wrote: hi ya petra lots of different kind of floods...and DoS attacks... what kind of attack are oyu under ??? -- what shows up in tcpdump when monitoring all traffic on the wire ??? if you're an amplifier .. you have to turn off icmp broadcasts at your incoming cisco router/fw to test if you are a smurf amplifier.. see the links at http://www.Linux-Sec.net/harden/smurf.fix.txt to test your DNS config http://www.Linux-Sec.net/Audit/audit_tools.gwif.html#DNS to harden your dns servers... and spoof protecting etc .. http://www.Linux-Sec.net/Harden/server.gwif.html#DNS and lot of other stuff to harden too in addition to dns http://www.Linux-Sec.net/Harden/ have fun alvin On Sun, 30 Dec 2001, Petre Daniel wrote: Hello Nate,it seems i cant get the link of the advisory.Its about some sort of amplyfing flood,when an ousider makes spoofed queries to the bind daemon and another one ,the victim is flooded along with me the attacked.. Thx.. Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200
Re: Securing bind..
Russell, On Sun, 30 Dec 2001, Russell Coker wrote: Also don't allow recursion from outside machines. Why does this help? Another possibility is to have the port for outgoing connections be something other than 53 (54 seems unused) and use iptables or ipchains to block data from the outside world coming to port 53. Security through obscurity? Quite frankly, I find this strategy annoying. Nothing annoys me more than finding out that I have to open up yet another hole in my firewall so that I can access another idiot who has set up his webserver at port 1080, or 8080 or whatever his fancy pleases. If your service isnt secure at the IANA designated port, why would it be secure at the new one? Of course, in the case of DNS servers, you could be OK, since you do want to lessen the number of folks who use your services (right?). But in general, I consider this to be poor advice. Regards, Jor-el
Re: Securing bind..
The eaisest and most failsafe way to secure bind is to install djbdns. Google is your friend. -Tech On Sun, 30 Dec 2001, Petre Daniel wrote: Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing bind..
Jor-el wrote: Another possibility is to have the port for outgoing connections be something other than 53 (54 seems unused) and use iptables or ipchains to block data from the outside world coming to port 53. [...] Of course, in the case of DNS servers, you could be OK, since you do want to lessen the number of folks who use your services (right?). But in general, I consider this to be poor advice. That is perfectly true. In fact, restricting access to the (recursive) nameserver should be considered not only in a matter of IP filtering but also in BIND's own configuration (using allow-query and allow-recursion sets). Authoritative name serving is a totally different matter, since you can not predict the source adress. -- Thomas Seyrat.
Re: Securing bind..
On Sun, Dec 30, 2001 at 12:46:55PM -0500, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. Troll. Google is your friend. -Tech On Sun, 30 Dec 2001, Petre Daniel wrote: Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Jacob Elder http://www.lucidpark.net/
Re: Securing bind..
On Sunday 30 December 2001 18:46, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. If you have nothing to say - do not speak. -- Configuration options for BIND are listed on http://www.isc.org/products/BIND/docs/config/ List of URL that might be usefull is here: http://www.isc.org/products/BIND/contributions.html Cricket Liu's presentation on how to secure BIND: http://www.acmebw.com/papers/securing.pdf Securing DNS: http://www.psionic.com/papers/dns/ - acl defines hosts or networks that you can either allow or deny access version defines version number that bind answers if asked for it. (like: 'this space for rent. contact hostmaster' ;]) blackhole defines hosts or networks that bind will not answer at all. (ie.: 10.x.x.x, 192.168.x.x, 224.x) allow-recursion/allow-query defines hosts or networks that can use your server to get non-auth answers or do recursive queries. listen-on defines interfaces and ports bind will listen on. If you don't have any domains to server to the outside world, you just list the intranet (NAT) interface in here. forward only means that you will forward all request (and work ;]) to the dns servers listed in forwarders. -- BOFH excuse #57: Groundskeepers stole the root password
Re: Securing bind..
On Sun, 30 Dec 2001 16:17, Jor-el wrote: On Sun, 30 Dec 2001, Russell Coker wrote: Also don't allow recursion from outside machines. Why does this help? When someone sends a recursive query to your server then they know (with a good degree of accuracy) what requests are going to be made by that server and what responses will be expected. So you can send a recursive query for www.microsoft.com, then send a dozen packets appearing to be responses from the Microsoft DNS servers giving an IP address of one of your servers. While you're at it you make sure that the false packets you sent had long TTL entries so that they stay in the cache for a while. Then suddenly you have all clients of that DNS server thinking that the MS servers are on your IP addresses (with lots of potential for abuse). Another issue is that if at some future time a bug is discovered in bind that results in a security hole when doing recursion then you want to only be vulnerable to your own network (who you can hunt down if they abuse it) rather than the rest of the world. Another possibility is to have the port for outgoing connections be something other than 53 (54 seems unused) and use iptables or ipchains to block data from the outside world coming to port 53. Security through obscurity? Quite frankly, I find this strategy Please read my messages carefully before flaming me. DNS cache machine sents out requests from source port 54 (not obscure - every administrator of every DNS server on the net can easily discover this). Recursive requests go to port 53 (getting a DNS client to even talk to another port is difficult or impossible depending on the client). iptables/ipchains blocks access to port 53 from untrusted IPs (IE everything outside your LAN or dialup pool). Bind will not be expecting any data other than replies to it's requests on port 54 (the port that is open to the outside world) so even if you screw up in your configuration of bind to not allow recursion from the outside world you're still protected. Smart people NEVER rely on only one layer of protection if they can avoid it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
On Sun, 30 Dec 2001 22:02, jernej horvat wrote: On Sunday 30 December 2001 18:46, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. If you have nothing to say - do not speak. Perhaps a discussion of the relative merits of djbdns and bind is in order. I wanted to move to djbdns at one time, but it was too painful. Everything had to be redone (the config files were all incompatible), the documentation was inadequate, and there was no good amount of support on the net. Has djbdns improved since then? Securing DNS: http://www.psionic.com/papers/dns/ 2.4.x kernels support the --bind option to mount which avoids the syslogd hackery described in this URL. Also the authbind method supported by Debian is much more powerful and useful than using the chuid() functionality in bind. Both these things aren't mentioned. Cricket Liu's presentation on how to secure BIND: http://www.acmebw.com/papers/securing.pdf I disagree with the supposed security benefits of disabling zone transfers, it's just security by obscurity. Also when idiots read such advice and take it to heart it gets in the way when you have a genuine need for zone transfers. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Securing bind..
thank you all very much. you're right.if one doesn't have anything useful to say i'll recommand him to let others help.. thx guys. At 10:02 PM 12/30/01 +0100, jernej horvat wrote: On Sunday 30 December 2001 18:46, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. If you have nothing to say - do not speak. -- Configuration options for BIND are listed on http://www.isc.org/products/BIND/docs/config/ List of URL that might be usefull is here: http://www.isc.org/products/BIND/contributions.html Cricket Liu's presentation on how to secure BIND: http://www.acmebw.com/papers/securing.pdf Securing DNS: http://www.psionic.com/papers/dns/ - acl defines hosts or networks that you can either allow or deny access version defines version number that bind answers if asked for it. (like: 'this space for rent. contact hostmaster' ;]) blackhole defines hosts or networks that bind will not answer at all. (ie.: 10.x.x.x, 192.168.x.x, 224.x) allow-recursion/allow-query defines hosts or networks that can use your server to get non-auth answers or do recursive queries. listen-on defines interfaces and ports bind will listen on. If you don't have any domains to server to the outside world, you just list the intranet (NAT) interface in here. forward only means that you will forward all request (and work ;]) to the dns servers listed in forwarders. -- BOFH excuse #57: Groundskeepers stole the root password Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200
Re: Securing bind..
Hello, On Sun, 30 Dec 2001, Russell Coker wrote: On Sun, 30 Dec 2001 22:02, jernej horvat wrote: On Sunday 30 December 2001 18:46, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. If you have nothing to say - do not speak. Heh, I didn't send a blank message. The point was clear. It was not a 'troll'. Perhaps a discussion of the relative merits of djbdns and bind is in order. Certainly. I wanted to move to djbdns at one time, but it was too painful. Everything had to be redone (the config files were all incompatible), the documentation was inadequate, and there was no good amount of support on the net. Of course the config files are incompatible - djbdns's file format is far simpler. The documentation is excellent - and simple, because the system is simple. Has djbdns improved since then? I don't think djbdns has ever been at the level you suggest. I strongly *strongly* suggest that anyone considering setting up DNS, be it BIND or djbdns, check out Daniel Bernstein's site on the subject, http://cr.yp.to/djbdns.html Securing DNS: http://www.psionic.com/papers/dns/ 2.4.x kernels support the --bind option to mount which avoids the syslogd hackery described in this URL. Also the authbind method supported by Debian is much more powerful and useful than using the chuid() functionality in bind. Both these things aren't mentioned. Cricket Liu's presentation on how to secure BIND: http://www.acmebw.com/papers/securing.pdf I disagree with the supposed security benefits of disabling zone transfers, it's just security by obscurity. Also when idiots read such advice and take it to heart it gets in the way when you have a genuine need for zone transfers. What is wrong with security by obscurity? It's an excellent strategy, albeit not a complete one. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page Yours, -Tech -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing bind..
quote who=Petre Daniel Hello Nate,it seems i cant get the link of the advisory.Its about some sort of amplyfing flood,when an ousider makes spoofed queries to the bind daemon and another one ,the victim is flooded along with me the attacked.. Thx.. if you do find it please pass it along to me, i am interested in what it has to say especially if its something recent. if you can send it to my real email address: aphro.at.aphroland.dot.org if its sent to debian-user@ it may get lost in that inbox so many messages go there :) thanks!! nate
Re: Securing bind..
On Sunday 30 December 2001 22:58, Russell Coker wrote: 2.4.x kernels support the --bind option to mount which avoids the syslogd yep. linux v2.4.x and bind v9.x are easier to set up. debian has almost out-of-the box chroot solution. I disagree with the supposed security benefits of disabling zone transfers, Why? Do you need the whole zone when you just need to resolve one host or IP ? Do you give away all your personal data when someone asks you for your name ? And this is what djb has to say for zone transfers :-) Zone transfers are an archaic alternative mechanism for copying DNS information. http://cr.yp.to/djbdns/faq/axfrdns.html#what - iptables/ipchains blocks access to port 53 from untrusted IPs What you can also do with bogus option in BIND. Or with ACLs and allow-query. --
Re: Securing bind..
jernej horvat wrote: [ snip ] And this is what djb has to say for zone transfers :-) Zone transfers are an archaic alternative mechanism for copying DNS information. http://cr.yp.to/djbdns/faq/axfrdns.html#what ``Zone transfers are an archaic alternative mechanism for copying DNS information. Instead of immediately sending new data to the slaves, you run a zone-transfer service that accepts periodic connections from the slaves; your users complain while they're waiting for the slaves to check for new data. The zone-transfer protocol isn't a modular file-transfer system; it is an ad-hoc system tied to the details of DNS. The protocol has terrible compression and no security. Every new zone on the master requires manual reconfiguration of the slaves. Zone transfers lose all information about client differentiation and scheduled record changes.'' It is always amazing to me how *intelligent* people try to make their point by taking other people's words out of context . . . Notice, that bind, current or not, has no answers to djb's concerns, as expressed in his complete paragraph ; [ snip ] -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .
Re: Securing bind..
On Monday 31 December 2001 01:29, Michael D. Schleif wrote: ... It is always amazing to me how *intelligent* people try to make their point by taking other people's words out of context . . . ... http://cr.yp.to/djbdns/faq/axfrdns.html#what i added the URL so i that everyone could look it up. the WHOLE text. i added another quote from that URL.. Notice, that bind, current or not, has no answers to djb's concerns, as expressed in his complete paragraph ; There has been some work on improving the zone-transfer protocol: a NOTIFY mechanism that wakes up the slaves (after a delay, and without a failure notice when something goes wrong); an experimental IXFR mechanism for incremental zone transfers (although the BIND implementation doesn't work for zone files modified by hand or by external tools); and several proposed security mechanisms, notably TSIG. BIND's May 2001 IXFR and TSIG implementations are supposedly free of the bugs that caused crashes, data corruption, and root exploits in previous versions of BIND. The BIND company occasionally mumbles about imaginary tools to handle new zones and client differentiation. By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow. Wow. May 2001.it is 30.12.2001 now and BIND 9.2.0 is out. http://www.isc.org/products/BIND/bind9.html DNS Security DNSSEC (signed zones) TSIG (signed DNS requests) IP version 6 Answers DNS queries on IPv6 sockets IPv6 resource records (A6, DNAME, etc.) Bitstring Labels Experimental IPv6 Resolver Library DNS Protocol Enhancements IXFR, DDNS, Notify, EDNS0 Improved standards conformance Views One server process can provide multiple views of the DNS namespace, e.g. an inside view to certain clients, and an outside view to others. Multiprocessor Support Improved Portability Architecture - djb should update his security concerned pages. --
Re: Securing bind..
jernej horvat wrote: On Monday 31 December 2001 01:29, Michael D. Schleif wrote: ... It is always amazing to me how *intelligent* people try to make their point by taking other people's words out of context . . . ... http://cr.yp.to/djbdns/faq/axfrdns.html#what i added the URL so i that everyone could look it up. the WHOLE text. i added another quote from that URL.. Notice, that bind, current or not, has no answers to djb's concerns, as expressed in his complete paragraph ; There has been some work on improving the zone-transfer protocol: a NOTIFY mechanism that wakes up the slaves (after a delay, and without a failure notice when something goes wrong); an experimental IXFR mechanism for incremental zone transfers (although the BIND implementation doesn't work for zone files modified by hand or by external tools); and several proposed security mechanisms, notably TSIG. BIND's May 2001 IXFR and TSIG implementations are supposedly free of the bugs that caused crashes, data corruption, and root exploits in previous versions of BIND. The BIND company occasionally mumbles about imaginary tools to handle new zones and client differentiation. By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow. Wow. May 2001.it is 30.12.2001 now and BIND 9.2.0 is out. http://www.isc.org/products/BIND/bind9.html DNS Security DNSSEC (signed zones) TSIG (signed DNS requests) IP version 6 Answers DNS queries on IPv6 sockets IPv6 resource records (A6, DNAME, etc.) Bitstring Labels Experimental IPv6 Resolver Library DNS Protocol Enhancements IXFR, DDNS, Notify, EDNS0 Improved standards conformance Views One server process can provide multiple views of the DNS namespace, e.g. an inside view to certain clients, and an outside view to others. Multiprocessor Support Improved Portability Architecture - djb should update his security concerned pages. improved != resolved By-the-by, what does ``Improved standards conformance'' mean? Does it or does it *not* conform? Or, is it just a little bit pregnant? ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .
Re: Securing bind..
On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote: ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . by throwing away all your existing zonefiles, DNS configuration, DNS tools and a bunch of features which djbdns doesn't support, you get to use rsync to transfer zonefiles around. an additional part of the price you pay is djb's moronic non-free software license and his rabid reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here attitude. big deal. bind can do rsync zone transfers merely by writing a wrapper script for named-xfer. i've done it. it works. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Securing bind..
Craig Sanders wrote: On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote: ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . by throwing away all your existing zonefiles, DNS configuration, DNS tools and a bunch of features which djbdns doesn't support, you get to use rsync to transfer zonefiles around. And, perhaps, your point? Broken as many of them are, they still work quite well with djbdns, thank you. I have nothing against bind, having setup various dns servers over the years; rather, I'll opt for simplicity wherever I can find it, if that simplicity is both functional and secure. To each his own . . . an additional part of the price you pay is djb's moronic non-free software license Really? http://cr.yp.to/distributors.html and his rabid reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here attitude. As you know, the software does *not* espouse his nor anybody else's views. So what? If conformance to standards is interesting to you, then check this out. If you are pleased with chasing the complexities inherent in overly complex tools, then, please, keep them uptodate . . . big deal. And, why would anybody want an overly complicated system to do something that is really, really quite simple? I don't. If you do, enjoy it; but, please, keep it uptodate and, somehow, get it to conform to the standards that are agreed upon so that simpletons like me can do something else with their lives, rather than be concerned over the simplest function of networks -- name resolution ; bind can do rsync zone transfers merely by writing a wrapper script for named-xfer. i've done it. it works. That, too, is my point -- glad you found it . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .
Re: Securing bind..
On Sun, 30 Dec 2001, P Prince wrote: The eaisest and most failsafe way to secure bind is to install djbdns. Because after djbdns, bind 4.2 looks like a pinnacle of security... Google is your friend. Apparently it didn't get you a clue... -Tech On Sun, 30 Dec 2001, Petre Daniel wrote: Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Artificial intelligence is no match for natural stupidity. Who is John Galt? [EMAIL PROTECTED], that's who!
Re: Securing bind..
On Monday 31 December 2001 03:34, Michael D. Schleif wrote: http://cr.yp.to/distributors.html Because of that policy there are no precompiled packages of djbdns, because: You may distribute a precompiled package if - installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above etc. Free? If you are pleased with chasing the complexities inherent in overly complex tools, then, please, keep them uptodate . . . compiling the whole package [1], installing it in paths that djb thinks are ok. complex? And, why would anybody want an overly complicated system to do something that is really, really quite simple? You have a point there. Most users don't need an dns server. They should use their isp's nameserver in /etc/resolv.conf. :] there is an alternative = http://dnrd.nevalabs.org/ -- [1] from: http://cr.yp.to/djbdns/install.html djbdns uses daemontools to start, monitor, and control the DNS services. Before running djbdns you need to install daemontools 0.70 or above. Make sure that the daemontools programs are in your system's default path. You will also need to install ucspi-tcp if you want to use axfrdns or axfr-get. So...i need daemontools and ucspi-tcp prior to installing djbdns.
Re: Securing bind..
On Sun, Dec 30, 2001 at 08:34:32PM -0600, Michael D. Schleif wrote: Craig Sanders wrote: On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote: ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . by throwing away all your existing zonefiles, DNS configuration, DNS tools and a bunch of features which djbdns doesn't support, you get to use rsync to transfer zonefiles around. And, perhaps, your point? that throwing away all your existing configurations and starting from scratch just to get a trivial feature (which can easily be had with a shell script wrapper around named-xfer) is NOT a good idea. there are two major problems with all of bernstein's software. the first is that it requires you to throw away your existing configuration...no big deal for a caching only name-server or if you only have one or two domains to serve. a severe pain in the arse if you have hundreds or thousands of domains. the second is that it is incredibly inflexible - you can only use it in the particular way that bernstein wants you to use it...and if you actually need to use it some other way then you are, according to djb, an idiot because he is never wrong. bind is far from perfect. but it's a lot better than all of the alternatives. if something actually better (as opposed to just loud grandiose claims of being better) came along, i'd switch to it in an instant. Broken as many of them are, they still work quite well with djbdns, thank you. named.conf doesn't work with djbdns - a minor problem. more importantly, bind style zonefiles don't work with djbdns - the idiot invented his own stupid format for zone files. if djbdns had been backwards-compatible with bind zonefiles then it might have had some vague chance of replacing bind. an additional part of the price you pay is djb's moronic non-free software license Really? http://cr.yp.to/distributors.html yes, really. non-free. if you don't understand WHY it's non-free then read the DFSG again. and his rabid reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here attitude. As you know, the software does *not* espouse his nor anybody else's views. So what? unfortunately, bernstein's software is severely limited by his views. he's a fairly good programmerbut a lousy systems administrator, with no concept of how real world sysadmins use tools or how they automate them. If conformance to standards is interesting to you, then check this out. djbdns does not conform to standards. he proudly ignored any aspects of the standards that were inconvenient to him. bind can do rsync zone transfers merely by writing a wrapper script for named-xfer. i've done it. it works. That, too, is my point -- glad you found it . . . so your point is that it's better to throw away years of configuration work so you can use djbdns than it is to write a simple wrapper script. right. good thinking. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Securing bind..
Russell, On Sun, 30 Dec 2001, Russell Coker wrote: Lots of good stuff snipped Please read my messages carefully before flaming me. Ack! My apologies. Poor reading and poor wording. DNS cache machine sents out requests from source port 54 (not obscure - every administrator of every DNS server on the net can easily discover this). Not sure I follow what you are saying here. Are you saying that it is pretty easy for a DNS admin to figure out what port you are running the DNS server on (if so how?) or are you saying that port 54 is a well agreed upon port for this purpose. I doubt very much that it is the latter, since http://www.iana.org/assignments/port-numbers states that port 54 is assigned to XNS (whatever that is). Regards, Jor-el
Re: Securing bind..
One phrase, sir: WTF?! You fail to make sense. -Tech On Sun, 30 Dec 2001, Michael D. Schleif wrote: jernej horvat wrote: [ snip ] And this is what djb has to say for zone transfers :-) Zone transfers are an archaic alternative mechanism for copying DNS information. http://cr.yp.to/djbdns/faq/axfrdns.html#what ``Zone transfers are an archaic alternative mechanism for copying DNS information. Instead of immediately sending new data to the slaves, you run a zone-transfer service that accepts periodic connections from the slaves; your users complain while they're waiting for the slaves to check for new data. The zone-transfer protocol isn't a modular file-transfer system; it is an ad-hoc system tied to the details of DNS. The protocol has terrible compression and no security. Every new zone on the master requires manual reconfiguration of the slaves. Zone transfers lose all information about client differentiation and scheduled record changes.'' It is always amazing to me how *intelligent* people try to make their point by taking other people's words out of context . . . Notice, that bind, current or not, has no answers to djb's concerns, as expressed in his complete paragraph ; [ snip ] -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing bind..
Hey, On Mon, 31 Dec 2001, Craig Sanders wrote: On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote: ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . by throwing away all your existing zonefiles, DNS configuration, DNS tools and a bunch of features which djbdns doesn't support, you get to use rsync to transfer zonefiles around. an additional part of the price you pay is djb's moronic non-free software license and his rabid reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here attitude. Please, what features? big deal. bind can do rsync zone transfers merely by writing a wrapper script for named-xfer. i've done it. it works. Well, DUH. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -Tech -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing bind..
quote who=Michael D. Schleif jernej horvat wrote: ``Zone transfers are an archaic alternative mechanism for copying DNS information. Instead of immediately sending new data to the slaves, you run a zone-transfer service that accepts periodic connections from the slaves; your users complain while they're waiting for the slaves to check for new data. The zone-transfer i may be missing the point here, but in BIND 8 the 'also-notify' command combined with notify yes option for me insures instantaneous transfers to all the slave servers. at my company i have 1 master and about 7 slave nameservers spread accross the various offices/regions, after i added the also-notify options with the ips of the slave nameservers zone transfers were immediate. before adding the also-notify bind only notified one or 2 of the nameservers in the allow-transfer ACL. works extremely well. now this does NOT work in some cases where you may have an ISP slave off of you, some systems only do zone transfers at specific times but that is a administrative decision(probably a good one for the larger isps). if you control both master and slave though its quite possible. i restrict zone transfers because there is no need for anyone other then the slave nameservers to do a zone transfer. that and a couple years ago there was a DOS against bind 8 that could be triggered by hosts that were able to do a zone transfer(this is long fixed of course..). nate
Re: Securing bind..
This is well out of hand, and I've delt with it before, so this is my less mailing on teh subject. On Mon, 31 Dec 2001, Craig Sanders wrote: On Sun, Dec 30, 2001 at 08:34:32PM -0600, Michael D. Schleif wrote: Craig Sanders wrote: On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote: ``By combining all these tools, you can finally approach the functionality of a trivial rsync script. Wow.'' Enough said . . . by throwing away all your existing zonefiles, DNS configuration, DNS tools and a bunch of features which djbdns doesn't support, you get to use rsync to transfer zonefiles around. And, perhaps, your point? that throwing away all your existing configurations and starting from scratch just to get a trivial feature (which can easily be had with a shell script wrapper around named-xfer) is NOT a good idea. I am *NOT* suggesting that you use djbdns *just for* rsync zone transfers. Either you're confused, which is OK, or you're pretending to have missed teh point because you have nothing left to stand on. These are my reasons for preferring djbdns, and mine alone. 1) djbdns is orders of magnitude smaller, simpler, and more elegant than BIND will ever be. I believe that this makes it more likely to be much more secure. 2) djbdns' file format is much simpler, and works much more like one now imagines the DNS system itself. Very few sites need any real concept of zones - we just don't setup dns like that. 3) djbdns is lighter - you only run the programs that do they things you need, rather than running `djbdns --options`. 4) Following from above, djbdns has the Unix philosophy. 5) I find that I really like Daniel Bernstien's code. He's an excellent programmer, and he really understands specifications, documentation, and how to really define a good solution, and a coherent system. I am not familiar with the group that codes BIND, but somehow they've taken one of the Internet's simplest protocols, and made it the second most difficult basic service to configure (the first, IMO, being your MTA). there are two major problems with all of bernstein's software. the first is that it requires you to throw away your existing configuration...no big deal for a caching only name-server or if you only have one or two domains to serve. a severe pain in the arse if you have hundreds or thousands of domains. This is crazy. Anytime you change software packages, you must rewrite your configuration. And, if you or anyone you know manages thousands of domains, I'll mail you a crisp, clean 20 dollar bill. (In order to be eligible, you must provide the name of your employer, so that I can avoid their service.) the second is that it is incredibly inflexible - you can only use it in the particular way that bernstein wants you to use it...and if you actually need to use it some other way then you are, according to djb, an idiot because he is never wrong. This too, is crazy. DJB desiged djbdns to work correctly. It does everything that BIND does. Everything. No feature is left out, excepet the redundant and archaic, which all have a newer, better solution. DJB sees a lot of stupidity out there from the BIND zealots, and I don't see where he's wrong. bind is far from perfect. but it's a lot better than all of the alternatives. if something actually better (as opposed to just loud grandiose claims of being better) came along, i'd switch to it in an instant. I bet you wouldn't. Broken as many of them are, they still work quite well with djbdns, thank you. named.conf doesn't work with djbdns - a minor problem. This is a stupid argument. httpd.conf doesn't work well with thttpd, and proftpd.conf doesn't work well at all with wu-ftpd. more importantly, bind style zonefiles don't work with djbdns - the idiot invented his own stupid format for zone files. if djbdns had been backwards-compatible with bind zonefiles then it might have had some vague chance of replacing bind. Perhaps, but BIND invented its own zonefiles too. What you fail to realize is how bad BIND zone files suck. an additional part of the price you pay is djb's moronic non-free software license Really? http://cr.yp.to/distributors.html yes, really. non-free. if you don't understand WHY it's non-free then read the DFSG again. This doesn't deserve a response. and his rabid reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here attitude. As you know, the software does *not* espouse his nor anybody else's views. So what? unfortunately, bernstein's software is severely limited by his views. he's a fairly good programmerbut a lousy systems administrator, with no concept of how real world sysadmins use tools or how they automate them. I hope you don't consider youself a good systems administrator, If conformance to
