[EMAIL PROTECTED] wrote:
Just because individual records are public doesn't mean you should allow just anyone to configure their nameserver as a slave to your domain.
There's no benefit to allowing transfers to just anybody except for the
allowance it makes for the laziness of admins.
Incorrect. I've often AXFR'ed people's zones to help troubleshoot
problems they've reported.
Weigh that against the risks of DoS attacks, and the sucking up of previous
upload bandwidth by domain transfers out. Each such transfer could well use
many many queries worth of bandwidth.
Individual queries of every record in the zone consumes as much or even
more bandwidth.
Moreover, if a would-be hacker were to start *guessing* at names in the
zone, then the total query traffic might actually be *substantially*
larger than the zone transfer would be.
(If Intrusion Detection/Prevention is in place, the hacker could "fly
under the radar horizon" by spreading the queries over a moderately-long
period of time, from different clients in a botnet, but the aggregate
traffic might still be higher than an AXFR).
Perhaps you don't understand that AXFRs are TCP. So reflection attacks
aren't really an issue, and the usual concerns about
DoS-amplification-via-reflector are misplaced.
Admittedly, if one has exceptionally large RRsets in a given zone (e.g.
using TXT RRs as a kind of _ad_hoc_ database), then allowing AXFRs might
enable the hackers to find those RRsets and use them for amplification
in subsequent DoS attacks. But the moral of that story is that one
shouldn't use DNS as a generic distributed database, not that open AXFRs
are inherently a security vulnerability.
We never experienced any problems with having zone transfers completely
open, for years. I realize that's just anecdotal evidence, but, on the
other hand, are there any documented cases where open AXFRs were
actually used in any kind of attack? If not, then I call FUD.
Its one more potential vulnerability with no particular benefit. Sounds like a poor trade to me.
That's one opinion. I cited a "particular benefit" above. Another
benefit is that maintaining lists of "authorized" slaves, potentially on
a zone-by-zone basis, complicates named.conf and, as we all know,
complicated configs lead to a higher risk of error, which can itself
lead itself to security breaches.
- Kevin
------Original Message------
From: Res
Sender: [EMAIL PROTECTED]
To: Jefferson Ogata
Cc: bind-users@lists.isc.org
Subject: Re: Secondary and TLD not updating
Sent: Nov 17, 2008 4:20 PM
On Mon, 17 Nov 2008, Jefferson Ogata wrote:
On 2008-11-17 14:25, Holger Honert wrote:
Chris Thompson schrieb:
On Nov 17 2008, Res wrote:
Ack! allow-transfer should never be any
What, never? Why not?
Security issue! You really want everyone to download your zone(s)?
I couldn't care less. If the security of my systems were the least bit
dependent on keeping DNS records secret, I would kinda suck as an admin,
wouldn't I?
does your employer know this is your attitude? he/she might take a
different stand :) I know you'd no longer be working for me, if that was
your take on how things should be.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
