[dns-operations] s3.amazonaws.com problem - price to pay for not using DNSSEC

Petr Špaček petr.spacek at nic.cz
Thu Oct 24 08:40:24 UTC 2019


On 23. 10. 19 14:37, Daniel Stirnimann wrote:
> I have located a host in our network which sends such queries the
> network resolver (which we operate):
> 
> mqfgioo5.s3.amazonaws[.]com. IN CNAME
> 6l-dpfrn.s3.amazonaws[.]com. IN CNAME
> 2idg5c42.s3.amazonaws[.]com. IN CNAME
> qzq3uz5m.s3.amazonaws[.]com. IN CNAME
> nenkxm2p.s3.amazonaws[.]com. IN CNAME
> yk2max6j.s3.amazonaws[.]com. IN CNAME
> qhcbric2.s3.amazonaws[.]com. IN CNAME
> wg-jmekf.s3.amazonaws[.]com. IN CNAME
> dnwn2ip1.s3.amazonaws[.]com. IN CNAME
> 711o385.s3.amazonaws[.]com. IN CNAME
> rn0v02a6.s3.amazonaws[.]com. IN CNAME
> pm1a3a4t.s3.amazonaws[.]com. IN CNAME
> 0xc.tibo.s3.amazonaws[.]com. IN CNAME
> 76jt.m9g.s3.amazonaws[.]com. IN CNAME
> 4tjc8hp.s3.amazonaws[.]com. IN CNAME
> b-.9ft7y.s3.amazonaws[.]com. IN CNAME

Funnily enough this attack would have been partially mitigated on resolver side if S3 domain was signed with DNSSEC!

New versions of resolvers already implement RFC 8198 which makes random-subdomain attacks ineffective against DNSSEC-signed domains. With 1/3 of clients in the world behind DNSSEC-validating resolver it would already make a difference.

This "protection effect" of signing + RFC 8198 was experimentally confirmed by measurements back in March 2018 and reported by me at DNS-OARC 28 meeting. Slides:
https://indico.dns-oarc.net/event/28/contributions/509/attachments/479/786/DNS-OARC-28-presentation-RFC8198.pdf

Update from 2019:
Slight latency increase reported on slide 9 is in fact bug in BIND implementation and not feature of the protocol.

Petr Špaček  @  CZ.NIC


> 
> Interestingly, it also sends other suspicious queries such as:
> 
> . IN TYPE1847
> . IN TYPE1847
> . IN TYPE567
> . IN TYPE1847
> . IN TYPE567
> . IN TYPE1847
> . IN TYPE1847
> . IN TYPE1900
> . IN TYPE823
> . IN TYPE1900
> . IN TYPE1847
> 7a4. IN TYPE868
> . IN TYPE1847
> . IN TYPE1847
> . IN TYPE1900
> . IN TYPE1847
> . IN TYPE1847
> 3n2y. IN TYPE612
> . IN TYPE311
> . IN TYPE1900
> 
> However, these are mostly answered from cache because of aggressive use
> of DNSSEC-validated cache. Still, I guess root server operators may see
> an increase in queries with unassigned query types.
> 
> Daniel


More information about the dns-operations mailing list