Secondary and TLD not updating

[Dawn Connelly]

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.

On Mon, Nov 17, 2008 at 7:47 PM, Kevin Darcy <kcd at chrysler.com> wrote:

> Dan at spore.ath.cx 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: bind-users-bounces at lists.isc.org
>> To: Jefferson Ogata
>> Cc: bind-users at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Google for President
YouTube for VP
in any year divisible by 4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20081117/66fab792/attachment.html>