= DNSSEC = <> Calling time on DNSSEC? https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ [[/Calling time]] <> Against DNSSEC 15 January 2015 https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [[/Against]] https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/stuff/dnssec-qa.html https://tools.ietf.org/html/rfc2065 [1997] == validator == 共用リゾルバーでは検証されているか。 jp.sharp のような設定が排除されない現状をどう受け止めるか。-- ToshinoriMaeno <> == NSEC3 == NSEC3の使い方は付録にある。 https://jprs.jp/tech/material/rfc/RFC5155-ja.txt [dns-operations] Forged Delegation Injection into Empty Non-Terminal with NSEC3 https://lists.dns-oarc.net/pipermail/dns-operations/2018-January/017214.html == dns.jp == [[/dns.jp]] == gov.mufj.jp == NSEC3+opt-outの問題 [[/NSEC3+opt-out]] [[/gov.ac]] ENT 問題 == ルートゾーンKSK更新の影響 == [[ルートゾーンKSK]]更新の影響のまとめ　　[[ルートゾーンKSK/日本では/お騒がせ見出し]] 　検証(BINDでいうdnssec-validate yes) を有効に指定していなければ、影響はありません。 {{{ この時期にDNSSEC検証を有効にする理由はありません。有効にしていなければ、影響はうけません。 }}} {{{ いますぐに大きなUDPパケットを受け取るように設定する必要もありません。 }}} KSK更新が影響するのはDNSSEC検証有効になっている場合だからです。 大きなUDPパケットを受け取れるかを確認することは容易ではありません。 　リゾルバーはUDPで受け取れなかったらTCPを使います。 {{{ 　外向きTCP/53が使えるか、確認しておくことを勧めます。 }}} [[/2017]] DNSを使っていなければ、[[ルートゾーンKSK]]更新の影響がないことを確信するまでに使った時間！ 　学べば学ぶだけ、DNSSECはだめだと分かる。-- ToshinoriMaeno <> [[/open-resolver]]　[[/用語/DNSKEY]] <> ---- = DNSSECについて = [[/DOflag]] [[/JPNIC]] : 間違いだらけの説明 DNSの安全性を強化するために必要なのは[[DNSSEC]]なのでしょうか。 　改めて、考えてみたいと思います。-- ToshinoriMaeno <> DNSSECはKaminskyの指摘以前に計画されている。:-) 少なくともKaminsky流の攻撃を防ぐためのものではない。 [[/政府が推進？]] == なぜだめなのか == やれることの割に管理運用の手間が掛かり過ぎる。これに尽きる。 https://sockpuppet.org/blog/2015/01/15/against-dnssec/ 開発に手間がかかっている。その分、DNSの改善や保守がおろそかになる。 DNSでの毒盛対策が進まない。 == JPRSによる紹介 == https://jprs.jp/tech/material/iw2009-lunch-L1-01.pdf#page=14 [[/TLD/jp]] ドメイン情報　　https://jprs.jp/doc/dnssec/jp-dps-jpn.v1.4.html == 概要 == 分割、整理中です。-- ToshinoriMaeno <> DNS(UDP)は中間者攻撃には対抗できないことが分かっています。 DNSSECはDNS（UDP)の弱点である毒（偽レコード）を検出するためのひとつの仕組みです。 本当に毒盛に弱いのでしょうか。よく検討する必要があるでしょう。 これまでの理解では、DNSSECでしか守れないのは中間者攻撃による毒盛だけです。 　　しかし、中間者攻撃されるとしたら、DNSレコードだけ守ることにどれほどの意味があるでしょうか。 == KSK更新に関連しての通知 == 毒入れされやすいUDPを使い続けるのがまずいことははっきりしているのに、こだわる理由が分かりません。 　ただ、DNSSECがうまく行っていない理由もあきらかにしておかないと、過ちを繰り返すことになるでしょう。 -- ToshinoriMaeno <> DNSSEC 署名検証チェック http://www.e-ontap.com/dns/validation.html == なにができるのか == DNSSECはman-in-the-middle-attacksによるキャッシュ毒盛からDNSデータを守るためだという。　（Is DNSSEC Worth the Effort?） 　だとすると、MITMAの危険性を評価することが重要になるが、それはとても難しい。 [[DNS/毒盛]] == なにができないのか == MITMAを前提にするなら、DNSSECを使っていないという偽情報（毒）は容易に入れられる。 　そこでは、DNSSECを使っていないサイトは信用しないということでないとあぶない。 DNSSECで守れるものもあるが、守れないものの方がはるかに多いのが現状だ。 -- ToshinoriMaeno <> [[/できないこと]] == なにがまずいのか == [[/なにがまずいのか]] == DNSは十分に安全 == 　その手間が問題なのか。いや、TLDなどへの負荷が集中するので、それらの管理者が避けたがっているからだ。 UDP を使い続けるなら、DNSCurveのようなより単純な仕組みを使う方がよさそうだ。 == リンク == 「実践DNS」 http://sockpuppet.org/blog/2015/01/15/against-dnssec/ [[/Against DNSSEC]] http://ianix.com/pub/dnssec-outages.html https://www.nic.ad.jp/ja/materials/iw/2012/proceedings/t9/t9-Funato.pdf https://news.ycombinator.com/item?id=7449960 Resolving DNS Queries and Caching Validated Responses https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm-implementations-11-2-0/13.html [[DNS/DNSSECいうな]] http://www.theregister.co.uk/2015/03/18/is_the_dns_security_protocol_a_waste_of_everyones_time_and_money/ Is the DNS' security protocol a waste of everyone's time and money? http://www.circleid.com/posts/20150318_is_dnssec_worth_the_effort/ Is DNSSEC Worth the Effort?　　Head of Security at .SE DNSSECの売り込みにすぎないようだ。 [[/RFC]] [[/CloudFlare]] <>