DNS History: Exploring Your Domain's Past by inspecting DNS trails What insights can DNS history reveal about domain names? As the term suggests, this record tracks all modifications to a domain’s DNS settings over time, offering invaluable information for both security and strategy. That’s why today we will explore the concept of DNS history, the type of DNS records involved, and the various tool
2017年9月27日(PDT)、 DNSのルートゾーンを管理するICANNが、 現在実施中のルートゾーンKSKロールオーバーに関するスケジュールを変更すると発表しました。 KSK Rollover Postponed https://www.icann.org/news/announcement-2017-09-27-en ICANNによる報道発表の日本語訳「ICANN、ドメインネームシステムを守る鍵の更新を延期」 https://www.icann.org/resources/press-material/release-2017-09-28-ja 具体的には、KSKロールオーバーの作業のうち、 2017年10月11日に予定していた新しい鍵による署名の開始が先送りとなりました。 ICANNの発表によれば、最近の調査によって、 ISPなどインターネット上で利用されるリゾルバのうち、 相当な
DNS CAA（Certification Authority Authorization）は、自分が所有しているドメインに対して、SSL/TLSサーバー証明書を発行できる認証局(CA)を指定できる仕組みです。ドメイン所有者が CAAレコードを登録することによって、認証局が証明書を誤発行してしまうリスクを減らすのがこの仕組みのねらいとされています。そこで今回は、CAA に対応している Let's Encrypt 認証局を DNS CAAレコードに設定してみました。 Let's Encrypt は自分が所有しているドメインのSSL/TLSサーバー証明書を、無料で発行してくれる認証局です。詳しくは「Let's Encrypt サーバー証明書の取得と自動更新設定メモ」の記事をご参照ください。 CAAレコードを設定できるDNSサーバー 自前でDNSサーバーを運用していれば、BINDやPowerDN
2017年9月8日以降、認証局（CA）には、証明書発行プロセスでDNSのCAAレコードの確認が義務付けられました。Ballot 125 – CAA Records (passed) DNSのCAAレコードへの登録は必須ではありませんが、CAAレコードを登録しておくと、証明書の誤発行防止につながります。 ドメインの管理者がDNSのCAA (Certification Authority Authorization) レコードを利用し、ドメイン名とサブドメインに対して証明書を発行できる認証局 (CA) を指定できます。 証明書発行を依頼された認証局 (CA) はドメイン及びサブドメインのCAAを確認し、証明書を発行できる認証局 (CA) が異なる場合は、証明書を発行せず、ドメイン管理者に誤った発行申請があったことを報告します。
On Friday, July 7, an unauthorized connection to one of our technical partners resulted in the modification of the name servers [NS] of 751 domain names which then pointed traffic to the impacted domains to a malicious site. Our technical team was notified shortly thereafter and proceeded immediately to reverse the updates on impacted domains and investigate the incident. Pending the completion of
さきほど「DNSの浸透」に関して書いたのですが、それに対して「でもTTLを無視するDNSキャッシュサーバがいるから仕方がない」というような反応が一定数登場しています。 「浸透」の話になると、そのような話がほぼ必ず登場するのですが、実際に「この製品がTTLを無視する」とか「このISPで運営されているDNSキャッシュサーバはDNSプロトコルに違反している」という具体例をいまのところ見た事がありません。 「そういう困ったDNSキャッシュサーバも居るんだよ」とか「でもTTLを越えたあとも旧IPアドレスにアクセスあるもん」という感じの主張が多いです。 そんなところにsumikawaさんから以下のようなTweetを頂きました。 確かに、DNSの世界におけるTTL情報はアプリケーションには届かないので、権威DNSサーバのTTLを事前に小さくしたとしても、アプリケーションが持っているキャッシュは制御ができ
1 JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2015 株式会社日本レジストリサービス ■「DNS サーバーの引っ越し」とは サービスプロバイダーやレジストラ（JP ドメイン名では 指定事業者）の変更に伴い、その対象となるドメイン名 の権威 DNS サーバーが変更されることを、「DNS サー バーの引っ越し（以下、引っ越し）」と呼ぶことがありま す。今回は引っ越しの中でも特に、 (A) すべての権威 DNS サーバーのホスト名と IP アドレ スが変更される (B) Webサーバーやメールサーバーなど、権威DNSサ ーバー以外のサーバーのホスト名は変更されず、 IP アドレスのみが変更される 場合について、作業時のトラブル発生を未然に防ぐ、 本来あるべき手順について解説します。 なお、以降では「引っ越し」を、上記
Multi-Region Latency Based Routing now Available for AWS | Amazon Web Services
AWS News Blog Multi-Region Latency Based Routing now Available for AWS The Amazon Web Services are now available in an ever-expanding series of locations. You’ve asked us to make it easier to build applications that span multiple AWS regions and we are happy to oblige. Today I’m pleased to announce that Amazon Route 53 is making available the same latency based routing technology that powers Amazo
当ブログをご愛読頂いている方であれば、当然ご存知ないことと思いますが、俺は DNS が大好きです。 とは言っても、DNS サーバーの構築とか運用に詳しいわけでも、攻撃に対抗する方法を知っているわけでもありません。 やったことがあるのは、せいぜい、レンタル DNS サーバーでゾーン定義ファイルを書いて遊ぶくらいのものです。 昨今は、DNSSEC で遊びたいのですが、そのための環境が無く、悲しみに暮れています。 閑話休題。 タイトルの 2/3 のジレンマというのは、DNS の運用において成立させたい、とある 3 つの性質のうち、同時に成立できるのは 2 つまでで、3 つ全部を成り立たせるのは不可能だ、ということを指しています。 その 3 つの性質というのは、 Zone Apex によるアクセス DNS サーバーのアウトソーシング 変動する IP アドレス です。 こういうの、何て言うんでしょう
トップページ - 翻訳ドキュメント - RFC 1034 原文：ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt 原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。 サイト内関連リンク：RFC 1035 DNS 実装と仕様 Network Working Group Request for Comments: 1034 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - CONCEPTS AND FACILITIES ドメイン名- 概念と機能 1. STATUS OF THIS MEMO 1. この文書の位置付け This RFC is an introduction to t
コーソル DatabaseエンジニアのBlog へようこそ コーソル DatabaseエンジニアのBlogでは、 コーソル所属のエンジニアがOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。 コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス（コンサルティング、設計、構築など）、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。 株式会社コーソル - サービス案内 株式会社コーソル - セミナー情報 コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。 コーソルについて知るためには・・・ 株式会社コーソル - 会社情報 人事ブログ - 『コー
The big security news of Summer 2008 has been Dan Kaminsky's discovery of a serious vulnerability in DNS. This vulnerability could allow an attacker to redirect network clients to alternate servers of his own choosing, presumably for ill ends. This all led to a mad dash to patch DNS servers worldwide, and though there have been many writeups of just how the vulnerability manifests itself, we felt
--------------------------------------------------------------------- ■（緊急）キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について（2014年4月15日公開） ～問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨～ 株式会社日本レジストリサービス（JPRS） 初版作成 2014/04/15（Tue） 最終更新 2014/05/30（Fri） （対策に関するDNS運用者向け文書へのリンクを追加） --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
12月6日、Internet Week 2006のセッションの1つとして行われた「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。 12月5日から8日にかけて「Internet Week 2006」が横浜で開催された。このうち12月6日に日本ネットワークインフォメーションセンター（JPNIC）が主催した「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。 なりすましと反射を悪用したDoS攻撃 取り上げられた課題の1つは、偽装した発信元IPアドレスから不特定多数のDNSサーバにクエリを投げかけ、被害者に多数のパケットを反射させてDoS状態に陥れる「DNS amplification attack」だ。2006年3月には実際にその被害が発生し、警察庁からも関連するレポートが公表され
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
DNS問い合わせの可視化 最近、データをまとめたり可視化したりしてその性質を調べる探索的データ分析(例)にはまっています。と、同時にネットワーク分析にもちょっと手を出しており、その2つの派生物としてドメイン名問い合わせの結果を可視化してみました。 これを読んでいる人にはもはや説明の必要はないと思いますが、一応書いておくと、世の中のwww.google.comやwww.amazon.co.jpのようなドメイン名はサーバの場所を直接示しているわけではなく、「この名前を持っているサーバのIPアドレスはなんですか？」というのをDNSサーバという別のサーバに問い合わせることで目的のサーバのIPアドレスを教えてもらい、その後目的のサーバへ接続します。以前は正引き（ドメイン名からIPアドレスを問い合わせる）と逆引き（IPアドレスからドメイン名を問い合わせる）が対称構造になるように設定するのが主流でしたが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Announcement: ELB stickiness updates to support Feb 2020 Chromium CORs changes
