プライベートな名前の解決やマルチホーミングのお供に。所謂split DNSをクライアント側で設定してみます。systemd-resolved含めて普通のOSは接続ごとのDNSサーバと検索ドメインをみて良きに処理してくれます。一方で接続切れた時に内部用の名前を外に流したくないとか、ちょこっとテストしたいとかいう場面もあります。毎回ググって情報にたどり着くのがめんどくなったので備忘です。IPのルーティングは別途必要。懐かしいですがフレッツのサービス情報サイトの.fletsとかもそうですね… Root Zone Database 流石に確保してないですか。.nttは復活してたのですね。
タグ: dns
nginxでGooglebotの検証 簡易版
2022-09-30追記: この記事の後にGoogleがGooglebotの範囲を公開したので、もっと簡単に簡易検証できるようになっています。
Facebookと傘下が死んでいたようですがこの記事の
Internet providers usually update their DNS records every few hours, but they can take several days to fully propagate.
はちょっと何言ってるか良く分かりませんでした。他人のRRをプロバイダがアップデートしている??? いずれにせよ全部の権威サーバ[abcd].ns.facebook.comがAS32934の中にいてサービスを提供しているサーバごとBGPテーブルから消え去ったのでネガティブレスポンスのキャッシュではなくてサーバに到達できないというエラーのキャッシュになります。キャッシュが1000くらい直列になった謎沼の底でもない限り数日かかることはないかと思います。
それはともかく本題のGooglebotの検証方法は公式には
となっています。User-agentも逆引き(rDNS, PTR RR)も詐称したい側が容易に詐称可能です。.google.com や .googlebot.com のA RRやAAAA RRはGoogleの権威サーバを乗っ取るかどこぞのキャッシュサーバを攻略しないといけないため通常は正しい、GoogleはUser-agent詐称しない、という前提のもと検証できることになります。
Apache HTTPDでは HostnameLookups Double と SetEnvIf を組み合わせて検証できます。nginxではNginx HTTP rDNS moduleを使ってできそうです。パッケージになっているディストリビューションが少ないので、配置しなければいけないサーバが多い場合はテスト目的以外で使うにはちょっと躊躇します。
そこでFCrDNS部分をざくっと省略版にしてAS番号で処理することにします。
消えたwakwak このwakwakの障害はglueレコードの理解を深めるチャンスです
お客様宛メールの配送エラー。XePhion エンタープライズの一部サービスにおける障害発生のお知らせについてPDF…
1. 発生日時
2019 年 7 月 30 日(火)2. 影響範囲
■現在ご利用いただけないサービス
(1) 「wakwak.com ドメイン」「wakwak.ne.jp ドメイン」のメール送受信
…
とのことで見てみるとns1.wakwak.comとns2.wakwak.comのglueレコードが消えたからwakwakも消えたのですね。
続きを読む
DNSSECとDNS update(RFC2136,nsupdate)とdelegation Let's Encryptワイルドカード証明書とDANE TLSA RRを添えて
締め切りより品質という記事が出ていますが、お疲れ様です。Let’s Encryptのワイルドカード証明書のサポートはとても便利になるので期待しながらDNSSECでdns-01を使った自動化の下準備をしてみます。(2018/3/14 ACME v2 and Wildcard Certificate Support is Liveということでcertbotにてワイルドカード証明書を取得しました。末尾に簡単に追記します)
続きを読む
2013/1/4 に D.ROOT-SERVERS.NET. の IPv4 アドレスが変わるそうな
[dns-operations] Advisory — D-root is changing its IPv4 address on the 3rd of January.
- 現 128.8.10.90 から 新 199.7.91.13 (すでに動作している) になる。
- IPv6アドレスは変わらない。
普通にISPのリカーシブサーバを使っている場合は関係ないですが、フルサービスリゾルバを運用しているなどでhintファイルを使っていたり、pdnsdのroot_server = discover にDを使っている場合などはもう更新しておくとよさそうです。
DNSSEC始めました
祝ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。
その「名前」、あなたのものですか?(その2)
この記事は「その『名前』、あなたのものですか?(その1)」の続きです。
あるお客様が、会社のウェブサイトの引越しをしたい、とおっしゃいました。 この場合、一番基本的な進め方としては、サイトのコンテンツを構成するファイル達を別のサーバに移動して、URLが新しいサーバを示すように変更する、と いうものです。しかしこのお客様の場合はそれが(すぐには)できませんでした。前回の記事は「ドメイン名」について解説しました。
- ドメイン名 ≒ 唯一無二の苗字
- 唯一無二だから好き勝手につけられない。→レジストラから入手するもの。
- IPアドレス ≒ 住所
- ネームサーバ ≒ 住所録
- ドメイン名に対するIPアドレスを知っているネームサーバをレジストリに登録する。
- 苗字を変えずに住所だけ引っ越すことができる。
今回は実際の引越しについて解説します。
人が引越しをする理由は様々です。間取りが狭くなった、新しい設備が欲しい、建物が無くなる、などなど。ウェブサイトのサーバを引越しする理由も大して変わりありません。そして、人が引越しをするときは、トラックで中身を移動して市役所に転出・転入届を提出しますが、ウェブサイトのサーバの引越しも基本的には中身を移動して住所変更をするだけです。
では、弊社サイトである「www.abacustech.co.jp」を引っ越すと仮定した例で考えてみましょう。前回の記事の例では、このサイトのコンテンツ(文章や画像などのページの内容)は198.51.100.88というIPアドレス(住所)のサーバに置いてありました。今回は、これらのコンテンツを203.0.113.7という「住所」にあるサーバに移動したとしましょう。
ドメイン名「abacustech.co.jp」は レジストラから株式会社Abacus Technologiesの名義で入手し(図1の(1))、Abacus Technologiesが操作できるネームサーバを登録しています(図1の(2))。そこでAbacus Technologiesはネームサーバに新しいIPアドレス(203.0.113.7)を登録します(図1の(3))。これは皆さんが引っ越した際に転居届を出すのと似ています。
この処理が終わると、ネームサーバは「www.abacustech.co.jp」について聞かれたら、新IPアドレス(203.0.113.7)を教えるので、ユーザのコンピュータからは正しく、引越し先である203.0.113.7のサーバへ要求がたどり着くのです(図1の(4))。
この処理が正しくできたのは、直接的には、レジストリに登録されているネームサーバをAbacus Technologiesが操作できたからなのですが、そもそも操作できるネームサーバが登録できたのは、以下の条件が揃っていたからです。
- abacustech.co.jpがAbacus Technologiesの名義である(管理のためのメールが届く)
- レジストラに登録されているドメイン名の登録内容の変更権限(*1)をAbacus Technologiesが持っているので、Abacus Technologiesが操作可能なネームサーバを指定できる
通常、変更権限を持つ人はそのドメイン名の名義人、もしくはその名義人から委託された人になります。この2つの根本的な条件が揃えば、ドメイン名の登録IPアドレスはいつでもどこにでも変更できます。
そこで質問です。皆さんがウェブサイトを公開しているそのドメイン名、名義人とドメイン名の登録内容の変更権限を持つ人は誰ですか?
ウェブサイトを制作する際に、その作業を業者に委託すると、ドメイン名の取得も代行してくれる業者が多いです。もしドメイン名の取得も委託する場合は、ドメイン名の名義人と、登録内容の変更権限を持つ人が誰かを確認しましょう。そして、もし将来的にサーバの引越しの自由度を視野に入れるのであれば、できる限りドメイン名の名義と登録内容の変更権限を持つ人が自分になること、もしくはその名義や変更権限が移管できることと、その移管プロセスが明確であることを確認しましょう。
ドメイン名が自分のものであれば、もちろんサーバに縛られることなく自由に処理できます。もしドメイン名の名義人でなかったり変更権限がなければ、仮にサーバを引越ししたくなっても、ドメイン名の名義人や変更権限を持つ人が許可しないと引っ越せません。もし許可が無くても引っ越したければ、別のドメイン名を取得することになり、それは苗字が変わるのに似たインパクトがありますが、このインパクトについてはまた別の機会に解説します。
ドメイン名の名義人になると、その管理にはドメイン名によって年間で数百円から数万円の管理費がかかります。ドメイン名は、不要になれば放棄できます(ただし一度放棄したら、後日同じドメイン名を再度取得したくなっても、それができる確証はありません)。また公共性の高いサイトや大人気のサイトの場合は悪い人が取得してmalwareの配布に利用される恐れもあります。
ドメイン名は唯一無二の苗字と同等で、時間が経って周知されればされるほど組織や会社の呼称の一つとして大事なものになります。ウェブサイトを制作する際や、会社のドメイン名を取得する際には、ドメイン名の名義人と管理について以上の要素を包括的に検討されることをお奨めします。
- ドメイン名の名義人であり変更権限があれば好きに操作できる
- IPアドレスはいつでもどこにでも変更できる
- →苗字を変えずに住所だけ好きに引越し可能!(*2)
(*1) 少し専門的な言葉を使うと、ドメイン名の登録内容とは「whois」の内容のことです。ドメイン名の内容の変更権限を持つ、ということは「whoisの内容の変更権限を持つ」ということで、レジストラによってその権限の付与の仕方が異なります。例えばMelbourne ITというレジストラだと、変更権限を持つユーザはユーザIDとパスワードを使ってシステムにログインして管理します。
(*2) ただしそのサーバが利用できる立場でないといけません。引越し先の物件を賃貸契約していないと引っ越せないと同じです。
注意: この記事内のIPアドレスは全て説明用のダミーのIPアドレスです。このようなIPアドレスについては「文書に記述するときに使って良い説明用のドメイン名、IPアドレス」を参照してください。
その「名前」、あなたのものですか?(その1) – ドメイン名とは何ですか?
仕事用のウェブサイトをドメインも含めて誰かにお任せで作られる方へ: ドメインを含むURLなどを長く使い続けたい場合は、なんだかよくわからなくてもぜひドメインの「登録者(Registrant)」(属性JPの場合は[登録担当者]、汎用JPの場合は[公開連絡窓口])および「管理者(Admin)」のメールアドレスは、完全にコントロールできる権限が自分だけにあり、かつ@以降にそのドメインを含まないメールアドレスを指定してもらってください。御自身で利用しているプロバイダがメーリングリストを提供している場合もあるので、そういったサービスを利用して自分とお任せする方へ自動的に転送されるようなメーリングリストのアドレスを作成すると便利かもしれません。ドメイン登録者のメールアドレスの確認はwhoisというものでできます。廃業される方も多いので何年か後に泣かないで済むかもしれません。
あるお客様が、会社のウェブサイトの引越しをしたい、とおっしゃいました。この場合一番基本的な進め方としては、サイトのコンテンツを構成するファイル達を別のサーバに移動して、URLが新しいサーバを示すように変更する、というものです。しかしこのお客様の場合はそれが(すぐには)できませんでした。そこで2回に分けてウェブサイトの引越しについて解説します。今回は「ドメイン」について解説します。
例えば弊社のサイトを見るためには、ブックマークに登録していただいたリストの中から「株式会社Abacus Technologies」をクリックしたり、http://www.abacustech.co.jp/とURLを直接入力したり、検索結果から弊社のサイトのページを選んでいただいていると思います。いずれの場合も、皆さんのコンピュータは「www.abacustech.co.jp」にアクセスしようとします。
図1の(1)でユーザーが見たいウェブページを指定するために使っているwww.abacustech.co.jpのabacustech.co.jpの部分が「ドメイン名」と呼ばれるもので、「ドメイン名」は「苗字」の役割を果たします。つまり「abacustech.co.jpさん」と呼んでいると思ってください。ただしこの「苗字」は唯一無二という特性があり、他に同じ苗字を持つ人はいません。そして、みんなが好き勝手に名前を付けていたら唯一無二にはならないので、ドメイン名は「レジストラ」から入手することになっています。なお、説明書などで例示するときに使えるドメインは「文書に記述するときに使って良い説明用のドメイン名、IPアドレス」をご参照ください。
さて、苗字を知っていても住所を知らないので、ユーザーはそのページが実際にどこにあるのかは知りません。そこで登場するのが「ネームサーバ」です。「苗字」の役割を果たすドメイン名に対して、ネームサーバは「住所録」の役割を果たします。つまりネームサーバが「www.abacustech.co.jpさん」がどこに住んでいるのか、その「住所」を見つけてくれるのです。その「住所」の役割を果たすのが「IPアドレス」と呼ばれるものです。IPアドレスは物理的に存在する機械に対して割り振られています。したがって、住所録であるネームサーバに聞けば「www.abacustech.co.jpさん」の住所が「198.51.100.88」(*1)であることが分かるので(図1の(2))、コンピュータはそのIPアドレスを指定してウェブサイトのページを要求することができるのです(図1の(3))。
でも、そもそも「www.abacustech.co.jpさん」の住所が記載されている住所録はどこにあるのでしょうか。その情報を管理しているのが「レジストリ」です。レジストラからドメイン名を入手すると、管理情報の一つとして、レジストリにそのドメインの情報を管理するネームサーバをレジストラ経由で登録できます。ネームサーバはレンタルサーバの業者が提供するもの、レジストラが提供するもの、他にも相当気合があれば自分でサーバを運用する、などがあります。
ところで、このトピックのそもそもの目的は「ウェブサイトの引越し」でした。皆さんが引っ越した場合には、市役所で転出・転入届けを出して、新しい住所を届け出ますね?市役所が駅から遠い所にあるとちょっと面倒ですが、これをしないと住民票が移動しません。さて、そう考えると、ドメイン名に関しても、「苗字」(ドメイン名)があって「住所」(IPアドレス)と「住所録」(ネームサーバ)があるということは、「要するに住所録を書き換えれば良いのか?」と想像できるのではないかと思います。それで正解です。つまり苗字を変えずに住所だけ変えることができるのです。
では次回はその引越しについてご説明しましょう。
- ドメイン名 ≒ 唯一無二の苗字
- 唯一無二だから好き勝手につけられない。→レジストラから入手するもの。
- IPアドレス ≒ 住所
- ネームサーバ ≒ 住所録
- ドメイン名に対するIPアドレスを知っているネームサーバをレジストリに登録する。
- 苗字を変えずに住所だけ引っ越すことができる。
(*1) IPアドレスは一つのドメイン名に対して複数登録できます。また一つの機械(ネットワークインターフェース)に対して複数のIPアドレスを割り振ることができます。さらには複数の機械に一つのIPアドレスを割り振る(エニーキャスト)こともできますが、一般人がインターネット上でエニーキャストを運用することはありません。
注意:
- この記事ではいわゆるサブドメインの運用については言及していません。
- この記事内のIPアドレスは全て説明用のダミーのIPアドレスです。このようなIPアドレスについては「文書に記述するときに使って良い説明用のドメイン名、IPアドレス」を参照してください。
文書に記述する際の説明用/例示用のドメイン名、IPアドレス、MACアドレス RFC6890,RFC5737,RFC3849,RFC2606,RFC6761,RFC7042 IANAなどなど
説明書などでドメイン名を例示するときに、 hoge とか foo とか bar とか chome などにを適当なTLDをつなげたり、最近ではTLDとして使ってしまうと自分のドメインでない場合や、自分のドメインでも更新しなかった場合などに問題になる可能性があります。IPアドレスもしかりです。そのままコピペされたり検索エンジンにインデックスされて他人に迷惑をかけないためにも、文書に記述するときに使ってよいドメイン名、IPアドレス、MACアドレス(EUI-48)が決まっています。
RFC6890によって RFC5735 はobsoleteにされました。(RFC5735によって RFC3330 はobsoleteにされました。参考: IPv4枯渇)
- 2016-06-28 MACアドレス関連追記
- 2013-10-11 RFC6890関連追記(Documentation用IPアドレスの変更はありません)
- 2011-02-10 .lg.jp関連追記
- 2011-01-26 .テスト などTLD関連追記
- 2010-03-17 .jp関連追記
192.0.2.0/24 | 192.0.2.0 – 192.0.2.255 | TEST-NET-1 (TEST-NET) | RFC6890 RFC5737(RFC5735 RFC3330) |
198.51.100.0/24 | 198.51.100.0 – 198.51.100.255 | TEST-NET-2 | RFC6890 RFC5737(RFC5735 RFC3330) |
203.0.113.0/24 | 203.0.113.0 – 203.0.113.255 | TEST-NET-3 | RFC6890 RFC5737(RFC5735) |
2001:db8::/32 | 2001:db8::0 – 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff | Documentation Prefix | RFC6890 RFC3849(RFC5156) |
00-00-5E-00-53- | 00-00-5E-00-53-00 – 00-00-5E-00-53-FF | EUI-48 (MAC addresses) Documentation Values | RFC7042 2.1.2 (2.1.1) |
00-00-5E-EF-10-00-00- 他 | 00-00-5E-EF-10-00-00-00 – 00-00-5E-EF-10-00-00-FF | EUI-64 (unmodified 64-bit MAC addresses) Documentation Values | RFC7042 2.2.3 |
.test | recommended for use in testing | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
.测试(.XN–0ZWM56D) .परीक्षा(.XN–11B5BS3A9AJ6G) .испытание(.XN–80AKHBYKNJ4F) .테스트(.XN–9T4B11YI5A) .測試(.XN–G6W251D) .பரிட்சை(.XN–HLCJ6AYA9ESC7A) .δοκιμή(.XN–JXALPDLP) .テスト(.XN–ZCKZAH) .טעסט (.XN–DEBA0AD) .آزمایشی (.XN–HGBK6AJ7F53BBA) .إختبار (.XN–KGBECHTV) | e.g. ほげ.テスト (xn--18j4d.xn--zckzah) | Reserved for testing internationalised domain names | Root Zone Database |
.example | recommended for use in documentation or as examples e.g. hoge.example | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
.invalid | intended for use in online construction of domain names that are sure to be invalid | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
.localhost | having an A record(DNS) pointing to the loop back IP address and is reserved for such use | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
example.com | e.g. hoge.example.com, example.com | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
example.net | e.g. hoge.example.net, example.net | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
example.org | e.g. hoge.example.org, example.org | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
example.jp example0.jp example1.jp … example9.jp ドメイン名例.jp (xn--eckwd4c7cu47r2wf.jp) | e.g. hoge.example.jp, example7.jp, ほげ.ドメイン名例.jp (xn--18j4d.xn--eckwd4c7cu47r2wf.jp) | 汎用 JP ドメイン名における予約ドメイン名の3 JPRS FAQ | |
example.<属性ラベル>.jp example0.<属性ラベル>.jp … example9.<属性ラベル>.jp example.<市区町村ラベル>.<都道府県ラベル>.jp … example.<都道府県属性ラベル>.<都道府県ラベル>.jp … example.<市区町村属性ラベル>.<市区町村ラベル>.<都道府県ラベル>.jp … など詳細は右記技術細則にて | e.g. hoge.example3.ed.jp, example7.city.shibuya.tokyo.jp | 属性型(組織種別型)・地域型JPドメイン名登録等に関する技術細則の4.4 JPRS FAQ | |
example.lg.jp example0.lg.jp … example9.lg.jp | e.g. city.example8.lg.jp | LG ドメイン名登録等に関する技術細則の3.4 JPRS FAQ |