[dns-operations] BGP Hijack of Amazon DNS

[Lanlan Pan]

bert hubert <bert.hubert at powerdns.com>于2018年4月27日周五 上午2:33写道：

> On Thu, Apr 26, 2018 at 02:11:15PM -0400, Viktor Dukhovni wrote:
> > What's interesting to me here is that hijacking the routes to a
> DNS-hosting
> > provider for a large number of domains enables attacks that then
> compromise
> > many target domains, that would be more difficult to compromise
> collectively
> > via BGP alone.
>
> Another important thing is that even a brief BGP hijack of DNS *persists*.
> A 5 minute takeover can poison people's caches for a day or more.
>

+1,  time is critical.

Personally I think,  RPKI may help (ISP side),  FIDO with 2-step
verification may help (Client/MobileApp side).
Recursive cache is hard to control,  especially when BGP hijack the
authoritative server's IP and set a long fake A TTL.


> I've been pondering a bit if you could attempt to use a takeover to change
> NS records for TLDs.  So you hijack a query for www.powerdns.com to a gTLD
> server & return some fresh NS records pointing to new IP addresses.  I
> think
> that if you use a shorter TTL than the resolver already had in its cache,
> these NS records might stick.
>
> But in any case, a 1 minute BGP hijack of a big nameserver could have
> effects that last for a day or more. Unlike a direct hijack of a webserver
> or mailserver IP address.
>
> And I think a 1 minute BGP hijack is quite feasible, far more so than
> keeping it going for a day.
>
> Btw, it has been noted that injecting a cached HTTP(s) 302 would achieve
> something similar if you hijack a webserver IP.
>
>         Bert
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180428/a390705c/attachment.html>