複数の仮想環境を立ち上げてWeb開発するときに便利なmDNS
トレタアドベントカレンダー11日目です。 アドベントカレンダーを書くのは二年ぶりです。そのときは、家庭を支える技術アドベントカレンダーで、いまから帰るよという連絡をYOでするサービスをつくった話を書きました。いつのまにかあれから二年たちますが、今もほぼ毎日YOでkaeruyoしています。ここ最近AmazonのIoTボタンが盛り上がってますが、ボタンを押すだけの操作はYOに通じるものがありますね。YOのAPIで遊んでみるもおすすめです。 今回は最近知ったWeb開発のTipsを紹介しようと思います。VagrantやDockerを使ってウェブアプリを開発してるんですが、いつくかのアプリ同時にたときに、複数のVMを立ち上げたりすると、そのときポートフォワードしてるポートが被ってこけたり、別のポートに設定しなおしたりしていると、どのVMがどのポートにポートフォワードされてるのか分からなくなってしまい
DNS キャッシュについての考察 | Carpe Diem
比較的アクセスのあるウェブサーバがあって、そのウェブサーバから結構な回数で Web API をたたいています。ご存じのとおり、Linux では DNS をキャッシュしてくれないので、Web API をたたくために毎回 DNS へのアクセスが発生して、DNS の負荷がすこし上がってきたので、ウェブサーバに DNS キャッシュを入れてみることにしました。 今回の用件は、次のとおりです。 Web API でたたくときにドメインを、それぞれのウェブサーバでキャッシュしたい おもに外部ドメインをキャッシュするので、DNS ラウンドロビンにはできれば対応したい ということで、いろいろと調査したり、友人からアドバイスをもらったところ、Unbound、Dnsmasq、caching-server、の三つの選択肢があることが分かりました。それぞれ、CentOS 5.7 x86_64 の環境で、試していました
A proposal to extend the DNS protocol
Today a group of DNS and content providers, including Neustar/UltraDNS and Google are publishing a proposal to extend the DNS protocol. DNS is the system that translates an easy-to-remember name like www.google.com to a numeric address like 74.125.45.104. These are the IP addresses that computers use to communicate with one another on the Internet. By returning different addresses to requests comi
Google、DNSプロトコルの拡張を提案 クライアントに近いIPアドレスを正確に判断
ネットワーク上でクライアントにより近い位置にあるサーバの情報を返すため、DNSリクエスト内にクライアントのIPアドレス情報を含めることを可能にするというもの。 Googleの公式ブログによると、DNSではトラフィックのロードバランス目的やユーザーをより近いサーバに誘導するため、クライアントの場所に応じて異なるIPアドレスを返すことがあるとのこと。現在、IPアドレス情報を持っているDNSコンテンツサーバは、DNSリクエストのソースIPアドレスで、これを判断しているようだ。 しかし、DNSでは、ISPやGoogle Public DNSのようなサードパーティのリゾルバ（DNSキャッシュサーバ）を経て再帰探索されるため、リクエストのソースは必ずしもクライアントに近いIPアドレスではないとしている。 この問題を解決するため、GoogleとNeuStarによるインターネットドラフト「Client I
SMTP - SPF導入のすすめ : 404 Blog Not Found
2007年04月15日12:00 カテゴリiTech SMTP - SPF導入のすすめ NNIPFの話題も出たので、SPFについても書く事にします。 SPFって何? Weblioはこう答えてくれました。 SPF とは (Sender Policy Framework) エスピーエフ, えすぴーえふ SPFとは、電子メールの送信元ドメインを認証する方式のひとつである。SMTPの拡張仕様であり、RFC 4408として定義されている。 ここまでの説明は合ってます。が、以下の下りは完璧に間違っています。 SPFでは、あるドメインに対して電子メールを送ることのできるアドレスを、メールサーバーの側であらかじめ送信者のIPアドレスとして管理している。管理よって認証されたアドレスがメールサーバーの保有している情報と整合した場合に限り、そのメールが正当なものとして送信される。 詳しくはRFC 4408または
メール送信者認証技術 SPF/Sender ID についてお勉強
お勉強の背景に関しては 「迷惑メール対策 OP25B（Outbound Port25 Blocking）についてお勉強」 に書いたとおりですが、迷惑メール対策としての SPF/Sender ID についてもいろいろ勉強したのでそのまとめです。（DomainKeys については思いのほかエントリが長くなったのでまた別の機会で・・・）まずは参考になったサイトの紹介から。 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 Sender ID: Authenticating E-Mail DNS関連技術の最新動向 - SPF/DomainKeysとは Sendmail 社 - 送信者認証技術の導入におけるレコメンデーション メール送信者認証の仕組みを探る(2/2):スペシャル - ZD
Sender ID：送信者側の設定作業 ― ＠IT
送信ドメイン認証は、Yahoo!やGmailで「DomainKeys」が、Hotmailで「Sender ID」が利用されているほか、多くのISPが対応を表明したことにより一段と普及が進んでいる。すでに米国などでは、送信ドメイン認証に対応しているドメインからのメールを優遇して通すなど、利用することのメリット、また利用しない場合のデメリットなどが現れてきている。 本稿では2回にわたって、IPアドレスベースの認証方式に分類される「SPF（Classic SPF）」およびSender IDについて解説する。前編では、SPFおよびSender IDを導入するに当たって、実際にどのように手を動かせばいいのかについて説明したい。 IPアドレスベースの送信ドメイン認証 まず、IPアドレスベースの送信ドメイン認証について説明する（図1）。送信側は、「Sender Policy Framework（SPF）
今更だけどDNSキャッシュポイズニングについて簡単に説明するよ！ - そして、DNSポイズニングがなかなか対応されない理由。 - FreeBSDいちゃらぶ日記
先日IIJの一日インターンに行ってきました。 NDAがあるので、事細かに書くことは出来ないのですが、教育的なプログラムが組まれていて非常に面白かったです。 そこで、色々お話しして、その中でDNSポイズニングがなかなか対応されない理由、当たり前の理由が聞けたので、「DNSポイズニングって何がヤヴァイのか良くわかんね」って人に向けた簡単な解説とあわせて書きたいと思います。 まず、DNSキャッシュポイズニングの何が怖いか? 簡単に言うと、 「googleに繋いだはずが全く別サイトに繋がっちゃう！」 って話です。 本当に繋ぎたいサイトと違うサイトに繋いじゃう事が出来るので、例えば 実在するショッピングサイトそっくりの偽サイト作って、ショッピングさせて。クレジットカードの番号ゲットしちゃったり、住所ゲットしちゃったり。 夢が広がる怖い事が出来ちゃいます。 きちんとしたセキュリティ対策していれば大丈夫
(ひ)メモ - そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ（要はreverse proxy）なんていらねっす。セッション？ んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン！ Linux Virtual Serve
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ietf.org/rfc/rfc4408.txt