タグ

DNSに関するjinjin252525のブックマーク (34)

  • Route53でサブドメインだけ管理する方法 - Developers Note

    日に2回もブログを書くなんて人生初かもしれないonagataniです。こちらにちわ。という事で今回もRoute53の小ネタを。 皆さんRoute53利用されてますか!利用していない方は今すぐに利用しましょうとても便利です。 とはいえ、Route53に全部移設するのは無理だよー、wwwやwwwなしドメインは管理部署が違うので・・・という事もあるかと思います。 そんなときに便利なのが「サブドメインのDNSをRoute53に委任する」です。DNSの基的な機能なのですが知らない人もいるかと思いますので紹介させて頂きます。 DNSの委任についてはこちらの記事が参考になるかと思います AWSのマニュアル読めば理解できる方はこちらをどうぞ。 つまり「example.jp」というドメインがあるとして、www.example.jpやexample.jpについてはDNSは今のままで sub.example.

    Route53でサブドメインだけ管理する方法 - Developers Note
  • 019-DNSサーバーの引っ越し

    1 JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2015 株式会社日レジストリサービス ■「DNS サーバーの引っ越し」とは サービスプロバイダーやレジストラ(JP ドメイン名では 指定事業者)の変更に伴い、その対象となるドメイン名 の権威 DNS サーバーが変更されることを、「DNS サー バーの引っ越し(以下、引っ越し)」と呼ぶことがありま す。今回は引っ越しの中でも特に、 (A) すべての権威 DNS サーバーのホスト名と IP アドレ スが変更される (B) Webサーバーやメールサーバーなど、権威DNSサ ーバー以外のサーバーのホスト名は変更されず、 IP アドレスのみが変更される 場合について、作業時のトラブル発生を未然に防ぐ、 来あるべき手順について解説します。 なお、以降では「引っ越し」を、上記

  • NSサーバ移転に伴うNSレコードおよびそのTTL変更に関して - inuzのブログ

    TwitterID:@inuwarumonoというのは僕のことです。 Twitterにて@ockeghemさんというか、徳丸浩さんとNSサーバ移転について 教えて頂いたり意見させて頂いたり、やりとりをさせて頂きましたが 僕の言いたかった事が正しく伝えられなかったことと、僕が正しく理解できて いなかったことなどを、ブログの形にまとめます。 まずは経緯、背景から触れて、次に争点を整理し、検討を加えて最後にまとめます。 経緯 きっかけは徳丸さんのこのツイートでした。 ONAMAE.COMのレンタルDNSサーバーではNSレコードは変更できない(01.DNSV.JPなど固定)ので、NSレコードのTTLが5分というのは当に意味ない、と思います— 徳丸 浩さん (@ockeghem) 3月 8, 2012 これに対して、NSレコードのTTLが5分というのに意味がない点には完全同意ですが、 僕は徳丸さん

    NSサーバ移転に伴うNSレコードおよびそのTTL変更に関して - inuzのブログ
  • DNSサーバの変更の際の手順。

    いわゆるインターネットで、あるドメイン名のDNSサーバを別のサーバに変更(移行)する際の注意事項やら手順やら。 ※DNSについては、様々理解すべきことがあります。 ぜひこちらもご覧ください→ DNSについて。 前提など [note] 例として下記を前提として書きます。 対象のドメイン名 example.com 現在のDNSサーバ ホスト名(IPアドレス) ns01.example.com(aaa.aaa.aaa.aaa) ns02.example.com(bbb.bbb.bbb.bbb) 変更後のDNSサーバ ホスト名(IPアドレス) ns11.example.com(xxx.xxx.xxx.xxx) ns12.example.com(yyy.yyy.yyy.yyy) [/note] [note] この記事で言う「DNSサーバ」はいわゆる「権威サーバ」です。 「ネームサーバ」と同義として下

    DNSサーバの変更の際の手順。
  • Amazon Route 53 を既存ドメインの DNS サービスとして使用する - Amazon Route 53

    翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon Route 53 を既存ドメインの DNS サービスとして使用する 1 つまたは複数のドメイン登録を Route 53 に移管していて、現在有料の DNS サービスを提供していないドメインレジストラを使用している場合は、ドメインを移行する前に DNS サービスを移行する必要があります。そうしないと、レジストラはドメインの移行時に DNS サービスの提供を停止し、関連するウェブサイトやウェブアプリケーションはインターネット上で使用できなくなります。(現在のレジストラから別の DNS サービスプロバイダーに DNS サービスを移管することもできます。 Route 53 に登録されているドメインの DNS サービスプロバイダとして、Route 53 の使用は

  • Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード - Amazon Route 53

    作成したパブリックホストゾーンごとに、Amazon Route 53 はネームサーバー (NS) レコードと Start of Authority (SOA) レコードを自動的に作成します。これらのレコードを変更する必要はほとんどありません。 ネームサーバー (NS) レコード Amazon Route 53 によって、ホストゾーンと同じ名前のネームサーバー (NS) レコードが自動的に作成されます。これには、ホストゾーンの 4 つの正式なネームサーバーがリストされます。まれな状況を除き、このレコードのネームサーバーを追加、変更、または削除しないことをお勧めします。 次の例に、Route 53 ネームサーバーの名前の形式を示します (これらはサンプルとして提供されています。レジストラのネームサーバーレコードを更新する際には、これらを使用しないでください)。

  • DNSのTXTレコード(SPF)まとめ

    メールサーバーをリレーで配送する場合、リレーの仕組み上はpostfixなどのメールサーバーの設定だけでOKですが、最新のなりすましメールというかヘッダ情報を巧妙にいじって送るスパムメールが横行しているため、ヘッダ情報だけでは白か黒かの判別がつかなくなりました。 スパムフィルターは確かにある意味で有効ですが、白か黒かの判断が完全にできるわけではありませんね。その欠点を補う為に、既存のシステムの機能を利用して、送信元のドメインと経由してきたメールサーバーの関係でこの問題を解決しようというのがDNSのTXTレコードを使ったドメインの認証システムです。 DNSは、ドメインの根幹にある技術なので、なかなか難しい印象がありますが、しっかり調べて正しい情報を吸収すれば、難しくなんてないです。結構中途半端な理解で書いてるブログもありますからね・・・。たくさんのブログを読んで、話の真贋がわかるようになれば、

  • Domain Tools

    Products Iris Intelligence Platform The first place to go when you need to know. Iris Investigate Map connected infrastructure to get ahead of threats. Iris Detect Discover and monitor lookalike domains with unmatched speed and coverage. Iris Enrich Integrate DomainTools data with SIEM, SOAR, and other tools. Farsight DNSDB The world’s largest Passive DNS intelligence solution. DNSDB API Unlock th

    Domain Tools
  • Public DNS 「8.8.8.8」「129.250.35.250」は本当に速いのか? - Will feel Tips

    テスト環境 PC:ASROCK P67 Pro3 (マザーボード) Windows 7 Home Premium(OS) 回線:auひかり PLCモデム接続、北海道札幌市 測定サイト:Speedtest.net – The Global Broadband Speed Test Public DNS変更による検証結果 結論から申し上げますと、何も変更していないdefaultでのベンチマークが一番成績が優秀でした。 default Google Public DNS NTT America Technical Operations (それぞれのテスト結果の最大値) DNSベンチマークソフト『namebench』による結果Mean Response Duration(応答時間) Fastest Individual Response Duration(最も速かった応答時間) ※長さが短い方がレ

    Public DNS 「8.8.8.8」「129.250.35.250」は本当に速いのか? - Will feel Tips
  • RHEL6/CentOS6では、single-request-reopen を必須にしたい…

    2012-11-02 結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に options single-request-reopen を書いておこうという話です(全部小文字ですよ、念のため) なぜか? RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに DNSキャッシュサーバに AAAA RR の Queryを投げる AAAA RR の Reply を受ける DNSキャッシュサーバに A RR の Queryを投げる A RR の Reply を受ける という挙動でしたが、RHEL6/CentOS6 では DNSキャッシュサーバに A RR の Queryを投げる DNSキャッシュサーバに AAAA RR の Queryを投げる A RR の Reply を受ける AAAA RR の Re

  • BINDによるDNSサーバーの構築

    ※追記 2005/8/8:bind-9.3.1.tar.gzでも以下の説明で動作確認OK ■chroot 環境で動作させるための準備 仮にサーバーに侵入されたとしても、被害の拡大を最小限に抑えるために、named 専用のアカウントを用意し、jail 環境で動作させる設定を行います。まず、/etc/group に重複しないグループIDでnamed というグループを作成します。 次に、ユーザーの作成を行います。-d オプションをつけて、chroot させたいディレクトリを指定します。つまり、/var/named 以下が named の住居となり、これ以上、上位の階層へアクセスできなくなります。また、named ユーザーにシェルを提供しないよう、-s オプションを指定し、/bin/false とでもしておきます。

  • DNSレコードの書き方について質問です。ワイルドカードを指定し、かつサブドメインを運用することは可能でしょうか。…

    DNSレコードの書き方について質問です。ワイルドカードを指定し、かつサブドメインを運用することは可能でしょうか。 (したいこと) example.com -> 10.0.0.1 *.example.com -> 10.0.0.1 foo.example.com -> 10.1.1.1 bar.example.com -> 10.2.2.2 (やったこと) A @ 10.0.0.1 A * 10.0.0.1 A foo 10.1.1.1 A bar 10.2.2.2 (ところが) A * 10.0.0.1 が効いてしまって、foo. bar. のIPを返してくれません。 何かうまい書き方があるのでしょうか。

  • DNS のサブドメイン設定でワイルドカードを使う。 – JE no hitori chat

    DNS の設定のお話。 どんなサブドメインでも、同じサーバーに繋がるように DNS を設定したい時があります。 たとえば、je-pu-pu.jp っていうドメインを持ってるとして、 www.je-pu-pu.jp でも、 blog.je-pu-pu.jp でも、 abc.je-pu-pu.jp でも、 zyz.je-pu-pu.jp でも、 サブドメイン ( www とか blog とか ) の部分がどんな文字でも、同じサーバーに繋がるようにしたい。という場合です。 そんな時の、BIND のゾーンファイルの設定です。 @ IN SOA ns.je-pu-pu.jp. root.je-pu-pu.jp. ( 2008082901 28800 14400 3600000 86400 ) IN NS ns.je-pu-pu.jp. IN A 192.168.1.4 * IN A 192.168.

  • AWS: JavaのDNSキャッシュ ( TTL )について - aws memo

    AWSのサービスではDNSを用いて可用性を向上する仕組みを用いている。 各種APIのエンドポイント RDSのエンドポイント ELBのエンドポイント ElastiCacheのエンドポイント CloudSearchのエンドポイント Redshiftのエンドポイント などなど。AWSが提供するエンドポイントのFQDNを、自分のアプリケーションから参照するように設定したり、一旦DNSでCNAME設定することも多い。 ただし、これらのエンドポイントFQDNで設定されているIPアドレスは、運用中に変更される可能性がある(ノード障害、フェイルオーバー等によるIPアドレス変更、スケーリングによるIPアドレス増減、等)。そのため、アプリケーション側はエンドポイントのIPアドレス変更に追随する必要がある。(追随しないと、古いIPアドレスにアクセス試行しつづけて、結果としてシステム障害になってしまう) ここで問

    AWS: JavaのDNSキャッシュ ( TTL )について - aws memo