Nginxでproxy_passにホスト名を書いた時の名前解決のタイミング - （ひ）メモ
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
プログラマならば使うべき：GitHubでDNS管理ができる Luadns | Everyday Deadlock
さきほどTwitterで流れてきたのでたまたま見つけたのですが、LuadnsというDNSホスティングサービスがかなり凄いです。Luaスクリプトでゾーン設定を書いてGitHubにpushするだけで即座にDNS設定ができてしまいます。 DNSホスティングサービスというと、多くの場合ブラウザを開いてログインしてコントロールパネルからポチポチと入力して送信して、、、という手順を踏まないと設定が更新できないわけですが、Luadnsは違います。example.com.lua ファイルをEmacsやVim(やその他エディタ)で開いてLuaスクリプトを書き、git commit ＆ git push で設定が完了してしまいます。push にフックして Luadns の設定が自動的に更新されます。 マウスまで手を動かすのが無限に遠く感じられるプログラマにとっては、これほど素早く簡単にDNSが設定できるのはか
Chromeが起動時に三つのランダムなドメインに接続しようとする理由
“Chrome connects to three random domains at startup.” — Mike West Chromeを起動した際、http://aghepodlln/とかhttp://lkhjasdnpr/のようなランダムなドメインへの接続を試みる。何でこんなコトをしているのかという見当はずれの推測が、いくつか出回っている。事実としては、この挙動は必要なのだ。以下の説明で、この疑問を晴らす。 このような接続要求の目的は、現在使用しているネットワークが、存在しないホスト名への接続要求を検知して勝手にリダイレクトするかどうかを判定するものである。例えば、少なからぬISPが、http://text/のようなDNSルックアップの失敗に対し、http://your.helpful.isp/search?q=text（あなたの親切なISP）へリダイレクトしている。この「親切
MacOSX のローカルの DNS キャッシュ - Hatak::Techlog
DNS の設定を触るとき、ローカルのキャッシュが変わっていないためにハマることが多々あります。Mac の場合、ターミナルで dig して変更を確認してもブラウザで開けなかったりするわけで。 これは、MacOSX 内部で DNS 解決の結果をキャッシュする機能が働いているためです。 キャッシュをコントロールするためには dscacheutil コマンドを使います。 dscacheutil Usage: dscacheutil -h dscacheutil -q category [-a key value] dscacheutil -cachedump [-buckets] [-entries [category]] dscacheutil -configuration dscacheutil -flushcache dscacheutil -statistics
「魔法の数字8.8.8.8」に関する調査協力のお願い:Geekなぺーじ
タイトルは釣りです。 ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い！」と言っています。 [N] iPhoneのWiFi接続を高速化する魔法の数字「8.8.8.8,8.8.4.4」 「8.8.8.8,8.8.4.4」より速い「129.250.35.250」: 小粋空間 以下が、その反応の例です。 懐疑的な感想もある一方で、「早くなった」とか「設定を変えた」と発言しています。 はてなブックマーク：[N] iPhoneのWiFi接続を高速化する魔法の数字「8.8.8.8,8.8.4.4」 はてなブックマーク：「8.8.8.8,8.8.4.4」より速い「129.250.35.250」: 小粋空間 実際どうなの？を調べたい で、実際はどうなのかを書こうと思
米国による横暴なドメイン乗っ取りに対抗し、BitTorrentベースのDNS構築の動き | P2Pとかその辺のお話
P2Pとかその辺のお話 WinMXとかWinnyとか、日本ではろくな扱いを受けていないP2Pですが、海外ではけっこう真面目に議論されてるんですよというブログ。 以下の文章は、TorrentFreakの「BitTorrent Based DNS To Counter US Domain Seizures」という記事を翻訳したものである。 原典：TorrentFreak 原題：BitTorrent Based DNS To Counter US Domain Seizures 著者：Ernesto 日付：November 30, 2010 ライセンス：CC by-sa ここ数日の米国当局によるドメイン押収、そして同様のドメイン乗っ取りをさらに容易にしようという法案（COICA）の動きは、分散型BitTorrent DNSシステムの構築を促した。このシステムでは、ピア･ツー･ピアでドメイン情報を
http://to./が開けるしくみ - しょんぼり技術メモ
※2010/04/14 11:55追記 ブコメでのご指摘の通り、「なぜ開けるか」に対する答えは、「"to"のトップレベルドメイン(TLD)にAレコードが設定されているから」というシンプルなものです。 "to"はトンガのTLDで、古くからTLDを売って外貨を稼いでいます。恐らく、今回の"to."URL短縮サービスもその一環ではないかと考えられています。（beroさん コメントでの情報提供ありがとうございました) ※さらに補足：もう少し正しい説明 を追加しました。 Twitterでちょっと話題に上っていたので。 http://to./というURL短縮サービスがあります。一見開けなさそうなこの不思議なURL、実は正しく開けます。 その仕組みについて簡単に説明したいと思います。 ブラウザで"http://to./"にアクセスすると、ブラウザはOSに"to."のIPアドレスを尋ねます。 そのリクエス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sstephenson/dnsserver.js: A DNS server for Node.js