2011/11/30 DNSOPS.JP BOF＠富士ソフトアキバプラザ
18:45〜
■ DNSSECのgTLDとccTLDの動向update（BBTower 大本さん）
- 2011/4/20 BoFスプリングフォーラムからのDNSSEC対応状況の変化
対応状況:
今日（11/30）.mm（ミャンマー）がsignされた
gTLD
.aero 動向変化なし
.mil DNSKEY公開済み
ccTLD
.de 6/4導入ずみ
.cl 4/22
.nz テスト用DNSKEY導入済み、年内に正式導入予定
.ruは未導入だが.suが導入済み、おそらく.ruの導入テスト？
.twは11/4導入済み
.au 導入スケジュールが承認された
.kr 11/24に導入
.ie 導入を表明
.si 9/1 テスト開始アナウンス
.ac、.io、.sh 4/29に導入すみ
.nc 7/12、.gl 8/4、.su 10/24、.ug 11/12
TLD導入は順調に進んでいる
TLDレベルのトラブルも発生している
fbi.govの署名期限切れ
ICB plc.で障害、管理下の.sh .io .ac. tmが影響を受けた
質疑:
Q: レジストラの対応状況はまとまっている？
A: 情報があればぜひ教えてほしい
Q: TLDが対応してもレジストラが対応していないところもあるのでは？
A: .euはレジストラについて誇らしげなアナウンス。
■ Amazon Route 53の使用法と裏側（Amazon荒木さん）
- Amazon Route 53の提供するもの
SLA100％
権威DNSサーバ、多様なRRType
高速な更新
IP Anycast
使った分だけ後払い
- AWSのグローバルネットワーク
20のエッジロケーション（東京、アジア、US、欧州）
Anycast運用
通常4つの権威DNSサーバを登録
それぞれが別々のAS、別々のTLDで動いている
- サポートするレコードタイプ
だいたいサポートされている
ただしDNSSEC未対応
- ホストゾーンとレコード
ホストゾーン: 管理可能なレコードの集合
サブドメインも同一のホストゾーンに入る
レコードは加重ラウンドロビンをサポート
0-255重み
エイリアスタイプ: AWS向けのレコードタイプ
- 値段
11月1日に値下げ
ホストゾーンへの課金 + クエリ数への課金
ホストゾーンへの課金（1ヶ月あたり）
$0.50/1ホストゾーン（ホストゾーン25個まで）
$0.10/1ホストゾーン（25個目以上）
クエリ数への課金（1ヶ月あたり）
$0.50/100万クエリ（10億クエリ/月まで）
$0.25/100万クエリ（10億クエリ/月以上）
araki.netの例だと$0.7/月程度
- 設定
AWS Management Consoleから操作可能
- ツール
API経由でFirefoxプラグイン（R53fox）でも操作できる
Goole Spreadsheetからゾーン情報を流し込めるプラグインもある
- その他
IPv6対応
AAAAが設定できる
IPv6 transportには未対応
プライベートIPアドレスも登録OK
TTLデフォルトは設定しない
セカンダリDNS、DNSSECには未対応
反映までにかかる時間は2〜3秒
重み付けもできるのでグローバルロードバランサにも使える
質疑:
Q:DoS攻撃を受けた場合の過大課金対策は？
A:DDoS対策を行っている
明らかにDDoSと分かった場合にはrefundする
Q:DNSSEC対応予定は？
A:顧客からの要請はある。
C:DS登録作業でのミスが怖いかもしれない
Q:IPv6サポートは？
A:国内のISPと比べると遅れている印象があるが、
次のIPv6 Dayで対応できるかもしれない
■ Google Public DNS （Google Erikさん）
- publicdns.google.com
Googleの「make the web faster」の一環
Webクローラが使っていた手法を使って作った
IPv4アドレス: 8.8.8.8/8.8.4.4
IPv6アドレス: 2001:4860:4860:8844/2001:4860:4860:8888
World IPv6 Dayに合わせて追加
- Client Subnet Option
HTTPにおけるX-Forwarded-Forのようなもの
権威サーバにとってクライアントの位置がわからなくなることへの対応
Internet Draftを出している: edns-client-subnet
IP Geolocationを応用したCDNに効果あり
Google Public DNS、OpenDNS、Bigravityが採用
EDNSを利用、Option formatは 0x50faをつけたオプションコード
source netmask、scope netmask、クライアントのIPアドレスを格納
source netmask: クライアントのネットマスクをキャッシュDNSサーバが格納
クライアントに一番近いキャッシュDNSサーバが設定
scope netmask: キャッシュしてよいネットマスクを権威DNSサーバが格納
詳しくは: http://www.afasterinternet.com/ （英語）
FAQ, I-D, digへのpatchなどがあります
質疑:
Q:クライアントにどんなメリットがあるのか？
A:権威DNSサーバが、クライアントのIPアドレスを直接知ることができない
問題を解決する。CDNの役に立つ。
トライアングルルーティングになるようなことを避けられる。
Q:CDNプロバイダは何かコメントをしているか？
A:Akamaiも議論に参加しているが、オフィシャルな意見は分からない
Amazon Route 53のチームが興味を持っているなら連絡してほしい
Q:DNSSEC Validationのサポートは？
A:いま答えることはできないが、そう遠くない将来にサポートされるだろう
DNSKEYの取り扱いのバグが直ったら提供されるようになるのではないか
Q:日本からのクエリ数は？
A:解析チームから情報をもらっていない。
IPv6クエリについては、とても少ないと聞いている。
■ IPv6対応で考えないといけないこと＋α （JPRS藤原さん）
- BIND 9バグの根本対策
権威DNSサーバ:
MasterをBIND9、SlaveをNSDにして動かす
同時に落ちなければよい
キャッシュDNSサーバ:
BIND 9とUnboundの2台のサーバを動かす
resolv.confやDHCPで両方のIPアドレスを配る
手元で試した限りでは、ブラウザは普通に動く
Windows XPのnslookupはエラーになる
適度に死活監視をしておけば、「重複をお許しください」に焦る必要がなくなる
権限奪取につながるものではなくDoS（サービス停止）がほとんど
- 逆引き
日本では機械生成の逆引きが普及しており、それを前提とした設定が多い
大昔、APNICがIPv4逆引きをしくじったという話があったが、詳しくは知らない
（会場: 実際にあった）
何がおきたのか？
→JANOGでレポートがあった
+ SSHログインの遅延
+ メールが送れない（MTAの接続元逆引きチェック）
+ 掲示板に書き込めない
IPv6ではすべてのIPアドレスに逆引きを設定するのは困難
エンドノードの使うIPアドレスはときどき変わる
現状はエンドノードでは設定されておらず、サーバは設定されているように思われる
現状、サーバ系はIPv4/IPv6ともに逆引きが入っている
sshd認証時の補助
who、lastlogなどの表示
メールサーバ間での逆引きチェック
おすすめの設定:
サーバは逆引きを設定する
サービスごとに、逆引きを行う・行わないを設定する
SMTP submission（メールサーバ間）だと必須
sshd、httpdはOffにするのがよい
掲示板の投稿制限
/32 /48など
ログ集計
/32、/48で接続元を分類
クライアントの識別は/128で
- レジストラのIPv6、DNSSEC対応
レジストラや、リセラの対応情報を持っていますか？
gTLD
GoDaddy: DNSSEC・IPv6ともにOK
Network Solutions: IPv6はメールすると設定できる
jp
jpshop.jpに情報あり
情報集めませんか？
- まとめ
+ 複数の実装を組み合わせましょう
+ IPv6は逆引きが設定されていないことが多いので、サーバの設定を
考えましょう
+ レジストラ、リセラでIPv6, DNSSECの対応状況を収集共有しましょう
質疑:
C:tomocha wikiにIPv6対応の指定事業者の情報がある
Google検索すると、まとめているサイトがいくつかヒットする
Q:IPv6協議会で情報を集めていたのでは？
A:サービス移行サブWGで話が出たが、jpshop.jpの情報でよいと結論が出た
C:IIJはDNSSEC対応してるのに×になっている
アップデート要求は出したが直っていない
C:IPv6逆引き設定をしていないISPもあり、tracerouteでホスト情報が出ない
C:hosts.allowにホスト名で書いているとうまくいかない
C:resolv.confに複数書くと、セカンダリDNSサーバへのfallbackに5秒くらいかかった
C:BSD系の新しい実装（BIND 8ベース）だとresolv.confにタイムアウト時間を書ける
C:マルチベンダによるリスク分散はよいが、運用負荷や情報集積などで難しい
C:対応を急いで行う必要がなくなるのはよい
■ DNSトリビア（JPRS森下さん）
- twitter上の個人企画
これまでに22個のネタをツイート、今日は5つ追加
- 日本の昔話
昔のDNSサーバはA・B・Cの3系列
A:海外向け
B:国内向け
C:両方
今のJP DNSはAの子孫
- AS112で実験されたIP Anycast
何か起きても致命傷にならない、はず
運用経験がルートDNSのAnycast運用にも役立てられた
- 昔のイギリスのネームサービス（NRS）はDNSとは順序が逆
例: uk.ac.site
メールについては、ゲートウェイサーバで相互変換していた
「cs」が「.cs」チェコスロバキア（旧）なのかコンピュータサイエンスなのか混乱
1990年代前半に他国と同じ順番になった
DNSプリフェッチのことを考えると、NRS方式がよかった
- DNSSECの署名は有効”期間”、有効期限ではない
以前「クレジットカードとは違う」と説明したが、ダイナースは有効期間方式らしい
- 許されるCNAMEの台数は実装依存
RFCでは制限を定義していない
Google Public DNSは数十段あっても大丈夫らしい？
■ スマートフォンDNS Queryについて （ソフトバンクモバイル 井上さん）
スマートフォンからのDNS Queryの傾向について紹介が行われた。
■ AAAA filterとかブロッキングとか （IIJ山本さん）
DNSによるブロッキングについて運用者としてどのように考えるべきか
課題提起が行われた。