Hey, maybe it's time to agree to disagree on this one? If Bert and Ernie can live together in roommate bliss, I'm sure we can all accept and appreciate each others differences.<br><br><div class="gmail_quote">On Mon, Nov 17, 2008 at 7:47 PM, Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com">kcd@chrysler.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><a href="mailto:Dan@spore.ath.cx" target="_blank">Dan@spore.ath.cx</a> wrote:<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just because individual records are public doesn't mean you should allow just anyone to configure their nameserver as a slave to your domain. <br>
There's no benefit to allowing transfers to just anybody except for the allowance it makes for the laziness of admins.<br>
<br>
</blockquote></div>
Incorrect. I've often AXFR'ed people's zones to help troubleshoot problems they've reported.<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote></div>
Individual queries of every record in the zone consumes as much or even more bandwidth.<br>
<br>
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.<br>
<br>
(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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<div class="Ih2E3d">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Its one more potential vulnerability with no particular benefit. Sounds like a poor trade to me. <br>
</blockquote></div>
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.<br>
<font color="#888888">
<br>
- Kevin</font><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
------Original Message------<br>
From: Res<br>
Sender: <a href="mailto:bind-users-bounces@lists.isc.org" target="_blank">bind-users-bounces@lists.isc.org</a><br>
To: Jefferson Ogata<br>
Cc: <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: Secondary and TLD not updating<br>
Sent: Nov 17, 2008 4:20 PM<br>
<br>
On Mon, 17 Nov 2008, Jefferson Ogata wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 2008-11-17 14:25, Holger Honert wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chris Thompson schrieb:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Nov 17 2008, Res wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ack! allow-transfer should never be any<br>
<br>
</blockquote>
What, never? Why not?<br>
<br>
<br>
</blockquote>
Security issue! You really want everyone to download your zone(s)?<br>
<br>
</blockquote>
I couldn't care less. If the security of my systems were the least bit<br>
dependent on keeping DNS records secret, I would kinda suck as an admin,<br>
wouldn't I?<br>
<br>
</blockquote>
<br>
<br>
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.<br>
<br>
<br>
<br>
</blockquote>
<br></div><div><div></div><div class="Wj3C7c">
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Google for President<br>YouTube for VP<br>in any year divisible by 4<br><br>