タグ

r53とDNSに関するjinjin252525のブックマーク (7)

  • AmazonのDNSトラフィック乗っ取り 仕組みについて解説 - orangeitems’s diary

    Route53のトラフィック乗っ取り AmazonのRoute53がトラフィック乗っ取りの被害に遭った、と聞くとぎょっとした人が多いのではないでしょうか。AWSの利用者は多いですからね。攻撃の仕組みについて解説します。 www.itmedia.co.jp AWSのクラウドベースのDNSサービスである「Route 53」のDNSトラフィックが何者かに乗っ取られ、「MyEtherWallet.com」のユーザーが仮想通貨を盗まれる事件が発生した。 解説 まず、この問題に関して利用された攻撃手法は「BGPハイジャック」という名前であることをおぼえてください。BGPとはネットワークの中で、ルーティング情報(経路情報)を交換するためのプロトコルです。BGPにて世界中のルーターが会話をすることによって、世界中どんなところにでも、インターネットがつながっていればパケットを届けることができるのです。例えば

    AmazonのDNSトラフィック乗っ取り 仕組みについて解説 - orangeitems’s diary
  • オンプレからAWSのDNSを引く高可用性な構成 | DevelopersIO

    コンニチハ、千葉です。 オンプレ+AWSのハイブリッドな構成で、AWS側のDNS引きたいということがあります。 例えば、ELBやRDSです。オンプレ側がインターネット接続可能でパブリックなDNSを引く場合はあまり問題になりません。が、オンプレ側がパブリックDNSを引けない場合は困りますね。 この場合、AWSDNSをを利用したくなるのですが残念ながらオンプレからAWSDNSを直接引くことはできません。 構成 そこで、直接引くのではなくAWS上にDNSフォワーダーを立て、オンプレのサーバではこちらを参照するように構成します。 自前で立てるのではなく、AWS Directory Serviceを使えばマネージドなので運用が楽になります。参考 ただ、今回はオンプレからDirect Connect(またはVPC、以下略)経由にてS3をアクセスする構成を考えており、今回立てるDNSフォワーダー上に

    オンプレからAWSのDNSを引く高可用性な構成 | DevelopersIO
  • それは僕たちのドメイン・DNS運用 - YAPC::Asia Tokyo 2015

    はじめまして、こんにちは!jigyakkumaです!!!!!1 Infrastructure as Codeが叫ばれる昨今、ドメインやDNS管理・運用にもその波が押し寄せておりますが皆様いかがお過ごしでしょうか。 私が所属している組織では取り扱うドメイン・DNSの数が比較的多く、管理・運用でのベストプラクティスを日夜模索しながら改善を行っている状況です。 運用や管理といった分野は各社のエンジニアや担当者がそれぞれ構築した仕組みやルールで運用を行ってはいるが、ノウハウの共有や知見を得る機会があまりないと感じております。 会社で所有しているドメインやDNSについて運用の手間やトラブルなどでお困りの方も、もしかすると多いのではないでしょうか。 トークではドメイン登録代行サービスを使用した人力による運用を経てAWS Route53にドメイン・DNSを集約するまでの背景やメリット、注意点を中心に会

  • 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
  • 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 ネームサーバーの名前の形式を示します (これらはサンプルとして提供されています。レジストラのネームサーバーレコードを更新する際には、これらを使用しないでください)。

  • 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
  • 1