1. DNS/FCP/2018

PowerDNS Blog https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/

Let's Encrypt が edns-buffer-sizeを512にした。

Contents

  1. DNS/FCP/2018

MLでの議論も： [dns-operations] Spoofing DNS with fragments

https://lists.dns-oarc.net/pipermail/dns-operations/2018-September/017950.html 

This is mostly a solved problem from the point of view of the low-level infrastructure: 

Current Linux has mitigations DNS servers can use to 
avoid fragmented responses for reasonable response buffer sizes (such as 
1200 bytes) even when ICMP path MTU poisoning is used.

これが実行されていれば、被害は少なくてすむのだが。

https://lists.dns-oarc.net/pipermail/dns-operations/2018-September/017972.html

Have anyone seen a reproducible published method using the technique, that can be recreated in non-controlled conditions such as on the public internet? As far as I can gather from the Register article, they've seen a paper.

I am asking because this author is known to us from a previous paper making claims that could not be reproduced. In the recent years, a paper was forwarded to us (at my previous employer) that claimed of various CNAME chain and additional section based poisoning and claimed that a variety of DNS implementations were found vulnerable including BIND. We could not test other implementations, but we did check the author's claims and didn't find BIND vulnerable to any of the recipes provided in the paper.

http://www.cs.colostate.edu/~cs557/papers/KSW17.pdf

(No CVEs or any bugfixes were released for any of the several claims in the paper, because we couldn't reproduce any of them.)

IP fragmentation attack is neither new nor is it for DNS - the same author has published "Fragmentation Considered Poisonous", which influenced me to prepare the EDNS CHECKSUM draft against any fragmentation attacks. But some time after writing that draft, I did not feel that the attack was practical in a real-life public internet scenario at that time. If the attacks described in that previous paper were performable, surely they'd have been used and we'd be aware of them. 

Perhaps this has changed, and we should have an open mind for each
vulnerability report, but I'd like to see a clear reproducible (by us)
recipe in a non-controlled situation, such as poisoning a public or 3rd
party DNS resolver (CA's resolver should be fine) for an answer from a
well-known 3rd party zone such as ISC.ORG.

最後の主張は妥当なのだろうか。

脆弱性の再現手段だけを求めるくらいだ。