サービス内容 IIJ Public DNSサービス(以下、本サービス)はDNS over TLS(DoT/RFC7858)、DNS over HTTPS(DoH/RFC8484)を利用した名前解決サービスです。 DoT、DoHは、従来用いられているDNSに変わる名前解決のためのプロトコルとして開発が進められています。 IIJでは、DoT、DoHによる名前解決の実用性の確認、また、DoT、DoHに対応したDNSサーバの運用ノウハウの獲得のため、試験的にDoT、DoH対応の名前解決サービスを提供いたします。本サービスはpublic DNSとして、IIJをご契約の方以外でもご利用いただくことができます。 DoT、DoHにご興味があり、本ページでご案内の条項に同意いただける方は、ご利用中のパソコン・スマートフォンに設定を行うことで、本サービスを利用した名前解決を行うことができます。 DoT、DoH
はじめに 昨年から DNS over TLS (DoT)、DNS over HTTPS (DoH) にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 (9.9.9.9)、昨年4月開始の Cloudflare (1.1.1.1)が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS (8.8.8.8) も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire
サマリDNSによる認証(DNS-01)でドメインを認証し、Let’s EncryptからSSL証明書を取得することができたので、メモとしてまとめます。クライアントはサードパーティ製のletsencrypt.shを使用します。DNSで認証するには、ドメインに認証専用のサブドメインを追加し、サブドメインに対してTXTレコードを設定できる必要があります。HTTPによる認証ではないため、Webサーバは必要ありません。このためHTTPによる認証と比較してとても簡単に証明書を取得できます。HTTPによる認証と手間なところ無料でDVのSSL証明書を取得できるLet’s Encryptが話題です。 Let’s Encryptで証明書の取得を行う場合、HTTPを使用してドメインを認証を方法(HTTP-01)が紹介されることが多いようです。 この方法でドメインを認証する仕組みは、ざっくり説明すると以下のとおり
Software Design誌にて、来月より6ヶ月連続で、 「(VMware x Kubernetes) はじめよう、おうちクラウド」 という連載が2021年10 月18日より開始されるため、 宣伝も兼ねて、DevOps meetup に登壇しました。
Internet Systems Consortiumは2月15日(米国時間)、「BIND 9 Refactoring|Internet Systems Consortium」において、今後はBIND 9をベースにコードのリファクタリングを進めると発表した。現在のところ、開発リソースの25%ほどのコードのリファクタリングに当てるしているが、開発資金の状況によってはこの割合を下げる可能性もあるとしている。開発チームは以前BINDをスクラッチから再開発する取り組みを行ったことがあるが、これは失敗に終わったとしている。 BINDはインターネットを支える重要なソフトウェアの1つだが、重大な脆弱性が発見されることの多いソフトウェアとしても知られており、管理者を悩ませるソフトウェアでもある。開発チームはBINDのコードが複雑であり、特に複雑になってしまっているコア機能部分に関連する脆弱性の発生が多いこ
DNS温泉2015 (DNS温泉2) Sep 12-13, 2015 @伊豆山研修センター 鈴木常彦 @E-ONTAP.COM プログラム 一日目 13:00 始業式 オリエンテーション 自己紹介 13:40 1時間目 哲学 DNS の基礎を疑い再考する 権威とは何か 委任とは何か ゾーンとは何か 内部名とは何か グルーとは何か 再帰とは何か フォーマット (テキスト: RFC1034, RFC1035) 15:10 休み時間 15:20 2時間目 図工 DNS を触ってみる 仮想ネットワークを作る ルートサーバを作る TLD を作る 自分のドメインを作る キャッシュサーバを作る 検索してみる (教材: ノートパソコン, VirtualBox, VITOCHA) 16:50 放課 (お風呂など) 18:00 夕食 19:30 3時間目 学級会 LT大会 & 懇親会 「nslookup しか
DNS温泉番外編2016 March 26, 2016 @IIJ 鈴木常彦 @E-ONTAP.COM プログラム 12:10 DNS 基礎講座 ~ 浸透いうな ~ 13:00 「RFC2181」講座 13:50 休憩 14:00 「幽霊ドメイン名脆弱性」と NS 移転講座 15:30 休憩 15:40 「委任/移転インジェクション」対策講座 17:00 ライトニングトーク 18:00 終了 DNS 基礎講座 ~ 浸透いうな ~ キーワード (ホワイトボードで図解) RFC1034 RFC1035 スタブリゾルバ、フルリゾルバ キャッシュサーバ、コンテンツサーバ(権威サーバ、ゾーンサーバ) ゾーン 委譲 (委任 / delegation) グルー 再帰.. (recursive) 、反復.. (iterative) 浸透...いうな
そもそもDNSの設定がうまく変更できたかどうかをうまく確認できていない人をよくみかけます。設定の確認には、DNSの仕組みを知り、「再帰検索要求」と「非再帰検索要求」をうまく使い分ける必要があります。 コンテンツサーバの設定確認 「非再帰検索要求」でNSとなっているサーバの設定を個別に確認しましょう。こんな感じ、、、 委譲元の確認(djbdnsのツール推奨) % dnsq ns e-ontap.com a.gtld-servers.net(できるだけIPアドレスで) 2 e-ontap.com: 130 bytes, 1+0+3+3 records, response, noerror query: 2 e-ontap.com authority: e-ontap.com 172800 NS ns.e-ontap.com authority: e-ontap.com 172800 NS ns
待つ必要のない客を待たせる (客を騙す行為) 騙されていることに気づかない サービスの問題点に気づかない (キャッシュ・コンテンツ兼用など) ... 実例 適切な設定確認を怠る (まず委任元と権威サーバを非再帰問い合わせで確認) 不適切な確認でネガティブキャッシュを入れて自爆する (いきなりキャッシュサーバに再帰検索要求) 待った上でしか設定ミスや障害を疑わない そもそもいつまで待てばいいのかわからない (自分から見えたら浸透完了? 例えば30日待ちますか?) 浸透待ちで睡眠不足になる (人的コストの無駄遣い) DNS の仕組みの理解が進まない 間違った理解の浸透と定着に手を貸す 「浸透いうな」と言われて悲しい目にあう (あるいは逆切れしてさらに無知を晒す) 確実に同じ失敗を繰り返す etc. (募集中) 浸透いうな!
こないだ書いた。浸透いうな先生にチェックしてもらってから公開しました。先生ありがとうございます。 DNS移転失敗体験談 from oheso tori 思いがけず人気が出たので驚いたのと、結構みんな「あるある」言ってるところを見ると救われますね(いや救われないか) slideshareでじゃリンク貼られなかったんでこっちで貼っておきます。 ■キャッシュサーバを権威サーバと兼用すると危ない http://www.e-ontap.com/dns/weirdra/ ■浸透いうな! http://www.e-ontap.com/dns/propagation/ ■権威/キャッシュDNSサーバーの兼用によるDNSポイズニングの危険性について http://jprs.jp/tech/security/2012-07-04-risk-of-auth-and-recurse.html ■[書き起こし]親の
--------------------------------------------------------------------- ■(緊急)GNU C Library(glibc)の脆弱性について(CVE-2015-7547) - 関連情報の収集・パッチの適用を強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2016/02/18(Thu) 最終更新 2016/02/23(Tue) (脆弱性の影響を軽減可能なフルリゾルバーの条件を明確化) --------------------------------------------------------------------- ▼概要 2016年2月16日(協定世界時)、GNU C Library(以下、glibc)の名前解決 ライブラリgetaddrinfo関数の脆弱性に関する緊急の注意喚起が公開されま した。
BIND 9.8系を例にとり、Linux(RHEL 6、CentOS 6)上における権威DNSサーバーのインストール、環境設定とゾーンの設定方法を解説する。 権威DNSサーバーにおける設定の基本は、DNSサーバーそのものの設定とゾーンファイルの設定の2つにある。 そのポイントには、例えば再帰検索要求を無効にするかどうか、どこからの接続を許可するかなどがある。設定を誤ると、場合によってはオープンリゾルバーなど好ましくない状態になってしまうため、設定内容には注意が必要だ。 ゾーンファイルは、権威DNSサーバーが管理するゾーンの情報を記述するファイルである。ゾーンファイルに誤った内容が記述されていると、その内容がそのまま公開されてしまうことになるため、こちらについても十分な注意が必要だ。 ここでは、Linux(RHEL 6、CentOS 6)上における権威DNSサーバーの構成方法を、権威DNSサ
NSはネームサーバー(Name Server)の略で、ゾーンに対する権威を持つ権威DNSサーバーを指定するものである。1つの権威DNSサーバーを1つの行で記述し、複数台の権威DNSサーバーがある場合にはその数だけ記述する。 例えば、以下のように2つの権威DNSサーバーがある場合には2つの行でそれぞれを記述する。 NSレコードは、権威DNSサーバーをホスト名で指定し、直接IPアドレスで指定するものではないこと、そして、指定するホスト名はAやAAAAレコードを持つものでなければいけないことに注意してほしい。また、CNAMEを使用した指定をしてはならない(CNAMEはCanonical Nameの略で、別名に対する正式名を指定するためのレコードである)。 また、NSレコードは、自身が管理する権威DNSサーバーだけでなく、親となる権威DNSサーバー側にも設定しなければならない。これは、DNSにおけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く