[Sysadmins] Eircom DNS woes...

Colm MacCárthaigh colm at allcosts.net
Wed Jul 15 09:28:20 IST 2009

On Wed, Jul 15, 2009 at 9:24 AM, Brian Boyle<brian.boyle at heanet.ie> wrote:
> Colm MacCárthaigh wrote:
>> Since Eircom and RTE both peer at INEX, using strict RPF might offer
>> some protection against that one. Many of the IE nameservers are
>> reachable that way too, and one of the root servers. So that helps.
> Is that practically possible though? Can you configure an RPF filter
> based on the content of a pretty deeply buried piece of info, such as
> a DNS response? Also, this would turn into a site by site filter,
> which wouldn't be much fun.

It's not DPI, it's just insisting that responses from the nameservers
come from the paths they should come from. We just have to reduce the
likelihoods of success for the attackers, and every little helps.

>> The next thing that a network admin could do is to analyse the hop
>> counts to each of the root servers, each of the IE nameservers and so
>> on, and to enable ttl-based ACLs (with a range of +/- 2 or so, to
>> handle path changes) as a temporary measure. That might cut out enough
>> traffic to get way below the volume needed to successfully spoof an
>> answer to a cache.  But it does take some analysis and automation.
> Most of the root servers are 9 or more hops from me, and many are
> "further" away. Also, given the nature of routing to/from them (with
> the added complication of anycast implementation), I wouldn't consider
> the ttls to be determinate over any period of time. Between those two,
> I think there is plenty of scope for a sufficiently large DDoS network
> to keep pounding away.

In an emergency though, the administrators could reconfigure their
root hints to point at only a subset of the root nameservers - ideally
ones they have more trustworthy paths to - and then apply it. But
internet paths are generally stable for at least hours, and if we
discard legitimate traffic, there are plenty of retries. I wouldn't be
too worried about it, in an emergency.


More information about the Sysadmins mailing list