タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

DNSSECに関するtzccinctのブックマーク (5)

  • DNSSECの仕組み

    A Gentle Introduction to DNSSEC DNSSEC creates a secure domain name system by adding cryptographic signatures to existing DNS records. These digital signatures are stored in DNS name servers alongside common record types like A, AAAA, MX, CNAME, etc. By checking its associated signature, you can verify that a requested DNS record comes from its authoritative name server and wasn’t altered en-route

    tzccinct
    tzccinct 2021/05/25
    RRsets, ルート署名セレモニー(Root Signing Ceremony)。
  • DNSのセキュリティ拡張"DNSSEC"入門|【技業LOG】技術者が紹介するNTTPCのテクノロジー|【公式】NTTPC

    DNS (Domain Name System)は、ドメイン名(www.nttpc.co.jp等)から対象のサーバーのIPアドレスを教えてくれるシステムです。Webページを見たり、メールをするために、無くてはならないものだということは皆さんご存知かと思います。 そのような重要なシステムであるのにも関わらず、DNSは通信のほとんどにUDP (User Datagram Protocol)を使っていたり、受け取った答えが正しいものかチェックしていなかったりと、大雑把な作りとなっています。それにはさまざまな背景があるのですが、そこを突いた攻撃や脆弱性が最近でも発見されています。 下に攻撃の一例を挙げます。 上記で述べたように、キャッシュDNSサーバー側で受け取った情報が正しいかどうかをチェックしていないため、攻撃者が不正な応答を紛れ込ませると、キャッシュDNSサーバーはその応答を正しい情報として

    DNSのセキュリティ拡張"DNSSEC"入門|【技業LOG】技術者が紹介するNTTPCのテクノロジー|【公式】NTTPC
  • DNSSECの基礎概要

    Copyright © 2012 株式会社日レジストリサービス 1 DNSSECの基礎概要 2012年11月21日 Internet Week 2012 DNSSECチュートリアル 株式会社日レジストリサービス (JPRS) 舩戸正和 Copyright © 2012 株式会社日レジストリサービス 2 チュートリアルの内容 • DNSSECの導入状況 • DNSキャッシュへの毒入れと対策 • DNSSECのしくみ • 鍵と信頼の連鎖 • DNSSECのリソースレコード(RR) • 対応が必要な関係者 • まとめ Copyright © 2012 株式会社日レジストリサービス 3 DNSSECの導入状況 Copyright © 2012 株式会社日レジストリサービス 4 DNSSECの導入状況 • rootゾーンにおけるDNSSEC – 2010年7月15日より正式運用 • TL

  • インターネット10分講座:DNSSEC - JPNIC

    今回の10分講座は、各TLDが対応を表明するなど導入の機運が高まりつつある、DNSSECについて解説します。 1. DNSSECの予備知識 1.1 DNSの仕組み まずはじめに、DNSではエンドユーザーのPCなど、DNSを利用するクライアントがどのようにドメイン名の情報を得るのか、その流れについて簡単に説明します(図1)。 図1:DNS 問い合わせ (1)クライアントから、所定のネームサーバに対し、問い合わせを依頼します。具体的には、ドメイン名に関する情報はリソースレコードという形式で管理されているので、www.nic.ad.jpというドメイン名のIPアドレスを知りたい場合にはwww.nic.ad.jpのAレコード(IPアドレスを格納するリソースレコード)を問い合わせます。 (2)依頼を受けたネームサーバは、問い合わせ内容を元に、ルートサーバ※1から委任をたどりながら順に問い合わせを行い、

  • DNSSEC 関連情報 ~よくある質問~ / JPRS

    受信したデータについて以下の二つが確認できた場合、そのデータは「当に正しい」と検証できます。 当にその相手が作成したものであること(データ出自の認証) 通信途中で書き換えられたり、一部が失われたりしていないこと(データの完全性) つまり「正しい相手から」「そのままの形で」の二つが、「当に正しい」の検証における必要条件となります。

  • 1