Amazon Route53にレジストラとしての機能がついたのでさっそく使ってみた

帰ってきて何の気なしにAmazonからのメールをぼーっとみてると
「あーはいはい、またなんか機能追加したのね」ってそのまま即効でアーカイブしそうになったけど、

(2014-08-09追記 日本語ブログエントリ出てました)

Domain Name Registration

You can now purchase a new domain name or transfer the management of your existing domain name to Route 53. When you purchase new domains via Route 53, the service will automatically configure a Hosted Zone for each domain and ensure the privacy of your WHOIS record at no additional charge. In addition, you benefit from AWS‘s consolidated billing to manage your domain name expenses alongside all of your other AWS resources.

この文章見てもしかしてRoute53にレジストラとしての機能が実装されたのか?

って半信半疑で少しぐぐってみたけど日本語の情報全然ないから僕の英語力がおかしいのかと思ったんだけど、
ちょっと試してみました。

上の文章を要約すると

  1. Amazon Route53 でドメインのお買い物ができるようになりました(レジストラになりました)。
  2. ドメインの転送もできます。
  3. Route53 で購入したドメインは自動的に Hosted Zone が構成されます。
  4. 何もしなくてもWHOISレコードからプライバシーが保護されます。
  5. 支払いはAWSの他のサービスの利用料金と統合して請求されます。

ものは試しなのでやってみました

ドメイン買ってみる

  • Route53のダッシュボードでDomainsを選択

f:id:wnoguchi0727:20140802020330p:plain

foo-bar-blah.com はもう僕がお名前.comで取得しちゃっているので買えません。
foo-bar-blah.jp ドメインは $100 だそうです。ぼったくり価格w

f:id:wnoguchi0727:20140802020333p:plain

今回は foo-bar-blah.net を取得することにしました。
Continue をクリック。

f:id:wnoguchi0727:20140802020332p:plain

技術者情報を入力します。
WHOISで個人情報が大公開されないようにするために Privacy Protection を Yes とするのがポイント。

f:id:wnoguchi0727:20140802024714p:plain

最終的な確認画面。規約に同意したらチェックして購入を確定する。

f:id:wnoguchi0727:20140802020335p:plain

ドメインの登録リクエストが正常に送信されたことが確認できる。

f:id:wnoguchi0727:20140802020336p:plain

ダッシュボードに戻ってみると Domain Registration in Progress となっており、登録中であることがわかる。

f:id:wnoguchi0727:20140802020337p:plain

しばらくすると Domains のメニューで選択した時の一覧に先ほど購入したドメインがリストアップされた。

f:id:wnoguchi0727:20140802020339p:plain

Hosted Zoneも自動的に構成されており、すぐに A レコード等を追加して使いはじめることができるようになっていた。

f:id:wnoguchi0727:20140802023645p:plain

すごいな・・・。

ドメイン移管してみる

お名前.comで取得したちょうど期限が切れそうなドメインが合ったのでRoute53に転送しました。

まずは Transfer Domain をクリックする。

f:id:wnoguchi0727:20140802020338p:plain

移管したいドメインを検索する。
今回はもうすぐ有効期限が切れそうなドメイン cloud-clipboard.com を選択した。

f:id:wnoguchi0727:20140802020340p:plain

AuthCode 等を入力して確定。

f:id:wnoguchi0727:20140802020341p:plain

これで移管の申請は完了。

f:id:wnoguchi0727:20140802020342p:plain

たぶんもう少ししたら結果出ると思う(2014/08/01深夜)。

Domain transfer in progress となり、ドメイン移管の手続きが始まったようです(2014/08/02朝)。

f:id:wnoguchi0727:20140802085611p:plain

Geographic Routing with Geo DNS の項についてはよくわかりませんでしたが、
負荷分散的な話でしょうか。誰か教えてください。。。

Lower Prices for DNS Queries では 8/1 から Route53 へのクエリ問合せが20%安くなったよって言ってるんでしょうか。

うーん、英語は難しいですね。

「夏のDNS祭り 2014 ~入門セミナ&ハンズオン~」に行ってきました

先週の7/5に開催されました「夏のDNS祭り 2014 ~入門セミナ&ハンズオン~」に行ってまいりました!

f:id:wnoguchi0727:20140705132347j:plain

概要

【自宅ラック勉強会 8.0】 この夏「ワタシハディエヌエスチョットデキル」ことを目標とします。

講師の方

滝澤 隆史 氏(@ttkzw)

インフラで有名な株式会社ハートビーツの方です。

Ustream

http://ustre.am/IWlq

ハッシュタグ

#自宅DNS #自宅ラック勉強会

質問ハッシュタグ

#自宅DNS-Q

会場到着

最近はだいぶ東京の電車にも慣れてきたので、あまり緊張すること無くいけました。
午前中は土曜日でもやってる区民事務所に行って、疲れていたので、時間が空いたらスタバで一杯飲もうかと思っていましたが、今度は会場が渋谷なので慣れないこともあり、場所の確認も兼ねて渋谷駅に行ったらおおむね時間通りになってしまいました。
いい時間なので、ココイチでカレーを食べました。
カレーはいつ食べても美味しいです。
前は車も持ってなくて、気軽にファミレスに行くこともなかったので、便利になったなと思います。

受付

セルリアンタワーのビジネスフロアに行くと警備員の方が立ってました。
駅の改札みたいなところで結構厳重に警備されていました。
さすがGMO
13:00ちょうどに受付の方がいらっしゃいました。
名刺を渡してチェックゲストカードを受け取るとSuicaと同じ要領で通過しました。
そして11Fへ。

GMOの華やかなフロアが見えてきました。
奥に行くとDNS祭り開場が。

準備

ちょっとスタッフの方に質問して、人以外なら撮影の許可が降りましたので、いくつか撮影させてもらいました。

着席するととてもかわいらしいConoHa関連のパンフレットやシールが置いてありました。

f:id:wnoguchi0727:20140705132618j:plain

f:id:wnoguchi0727:20140713221628j:plain

ひとまずConoHaへのSSH接続試験。
事前にconfigとキーペアの取得は済んでいたので一発でした。

ssh conoha-dns

ここで、Ustreamを会場で見るのはご勘弁ください!と会場に注意が促されました。
たしかに帯域を圧迫しそうですからね・・・。

開始

司会進行役は 鮭の切り身 さんです。

注意点

GMO様の会議室をご利用させていただくのでいろいろと注意。
UStream配信されています等々。

DNSの基本的な知識はとりあえず知ってるし、BINDの使い方も少しは知ってるから補欠の人には悪かったかな・・・と思ったのが大間違いでした。
ついていくのがやっとでした・・・。
自分がどれだけ知らないことがあるか思い知らされたセッションでした。

開始

GMOインターネット タカノ様 が登壇されました。

こういった勉強会に対する会場の提供といったサポートをされているようです。

ここでConoHaのサービス紹介。

  • ConoHaはCompute Nodes With Hi-flexible Architectureの略。
  • OpenStack+KVMで実装されたサービス。
  • スナップショット機能もついてる。

OpenStackはAmazon Web ServicesのEC2のオープンソース版に近いものです。

OpenStackはオールインワン構成でインストールしたことはありますが、
複数のコンピュートノードをぶら下げて実装できなかった悔しい思い出があります。

色々なコンポーネントで構成されているのでこのインフラをメンテナンスするのは大変だろうなあと思います。

ところで、ConoHaのコントロールパネルは

で実装されているそうです。Python(Django)で実装されているやつとは別なんですね・・・。とても好感が持てます。

ここで、このはモードにしたことはありますか?との投げかけがありましたが何のことやらわからなかったのですが、
言語を 日本語 から このは 言語

f:id:wnoguchi0727:20140709222517p:plain

に変更すると

f:id:wnoguchi0727:20140709222519p:plain

三雲このはちゃんが背景にお目見えしました。
とてもかわいいですね。
会場のみなさんも知らなかったようで驚いてましたw

ぜひ、美雲このは ちゃんをフォローして下さいねとのことでした。

  • ConoHaちゃーじが増えた
  • Suicaっぽいデザイン

ご清聴ありがとうございました。

ちなみに、近いうちに同じフロアで

TechOYAJI~ドキッ!おやじだらけのLT大会!ポロリもあるよ – ConoHa | Doorkeeper
のご案内

といったイベントも開催されるそうです。ポロリはどうかわかりませんが・・・。

講演開始

いよいよ滝澤氏による講演が始まりました。
資料は以下を参照とのことです。

夏のDNS祭り 2014 ~入門セミナ&ハンズオン~ – 資料一覧 – connpass

まずはDNSのポートを開けるところから

資料はこちら。

rootユーザでやるのが気持ち悪い人は一般ユーザを作ってからやってくださいと言われました。
私もずっとrootで作業するのは気持ち悪いたちなので空き時間を見つけてやりました。
言われた時点でやるのは難しかったですね・・・。

iptables(FW)の設定

基本的な流れは次の様な感じですね。

  1. iptablesのルールを確認
  2. InboundのTCP, UDPの53番ポートの穴を開ける
  3. iptablesのルールが変わったことを確認
  4. ルールを保存

IPv4のFWを開ける

sudo iptables -nvL INPUT --line-numbers
sudo iptables -I INPUT 5 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
sudo iptables -I INPUT 6 -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
sudo iptables -nvL INPUT --line-numbers
sudo service iptables save

IPv6のFWを開ける

sudo ip6tables -nvL INPUT --line-numbers
sudo ip6tables -I INPUT 5 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
sudo ip6tables -I INPUT 6 -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
sudo service ip6tables save

digコマンドが使えることを確認。

[root@v157-7-234-198 ~]# dig +short . soa
a.root-servers.net. nstld.verisign-grs.com. 2014070401 1800 900 604800 86400

で、用意ができたらGoogleDocsのスプレッドシートを案内されました。
ここに自分のConoHa VPSIPv4アドレスと好きなラベル名を設定するようです。
Google Docsのリアルタイムコラボレーション機能を遺憾なく使った良い例だと思います。

最初は ifconfig やっちゃったけど、本当は ip addr が本式。obsolete ですから。

# ip addr | head
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether fa:16:3e:01:b2:d0 brd ff:ff:ff:ff:ff:ff
inet 157.7.234.198/23 brd 157.7.235.255 scope global eth0
inet6 2400:8500:1301:813:a157:7:234:198f/64 scope global
valid_lft forever preferred_lft forever

ところで、ConoHaのVPSIPv6アドレスが豊富に割り当てられていますねー。
使い方がわからなかったので使わなかったですが・・・。

もりだくさんでした・・・。

ここでDNSに関する基本的な説明

ホスト名をIPアドレスに解決するものをリゾルバと呼ぶ

/etc/hosts で見つからなかったらリゾルバはDNSにアクセスに行く。

DNSのプレイヤー

  • スタブリゾルバ(このPC)
  • フルサービスリゾルバ(リカーシブサーバ、DNSキャッシュサーバとも)/etc/resolv.conf に指定するサーバ
  • 権威ネームサーバ(Authoritative Name Server)

ここから本番

RFC1034/RFC1035 が基本的な使用。
それ以外は拡張仕様。

RFC2181 が曖昧な部分を明確にしようとしたもの

ルートのためにはnullラベルが用意されている。
ノードの

www.example.jp.

最後がドットで終わるのは空のラベルがあるから。

っていう理由があるのはかなり腑に落ちました。

  • マスターファイルは絶対ドメイン名で記述される
  • 最後にドットがついていないと相対ドメインとして扱われる。
  • digでも絶対ドメイン名で使用する
  • 0オクテットは空のラベルで予約されている
  • プロトコル上は8bitコードも許容されている

  • ケースインセンシティブ

  • 可能な限り大文字小文字を維持する
  • 興味のある方はRFC4343を参照。

ようやく休憩となりました。けっこうもりだくさんです。

一般ユーザーを作成する暇がなかったのでここで作成 visudo でパス無しで sudo できるように ec2-user を作成。
ここでも ec2-user を使いたくなるのはAWSに毒されている・・・。

休憩中によく聞こえてきたのはEC2のときはセキュリティグループでフィルタリングしちゃうからiptables忘れちゃったというお話でした。
あーなるほどなーと思いました。
僕の場合は自鯖で参考にするiptablesの自動生成スクリプトばっかり使ってたから戸別のルールを確認するのが疎かになってなってたのが仇になった感じです。

ちなみにiptablesの設定ファイルは以下のファイルで定義されています。(IPv4)

# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Sun Jul 13 08:30:43 2014
*filter
:INPUT ACCEPT [4278:5161614]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1971:96049]
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
COMMIT
# Completed on Sun Jul 13 08:30:43 2014
.tokyo
.nagoya

これもgTLD。最初、私はエイプリルフールのネタかと思いました。

予約済みTLD

  • test
  • examle
  • invalid
  • localhost
  • local

  • .local は使っちゃダメ。とのことでした。

  • 理由はRFC6762を読んでくださいだそうです。

こんなところに理由が書いてありました。

どさにっき

  • ARPAドメイン
  • ip6.arpa
  • リソースレコード(RR)
  • ホスト名やIPアドレスとと言った資源に関するデータ
  • これらをまとめて
  • RRsetとする
OWNER TTL CLASS TYPE RDATA
  • TTL=0のときはキャッシュ禁止を表す

  • CLASS

  • IN(Internet)
  • CH
  • HS

CHはネームサーバの情報の取得に使われている

dig TXT CH…
  • TYPE
  • RRの種類
  • A, NS, CNAME, SOA
  • RDATA(資源データ)

  • SOA

  • ゾーンの権威の開始
  • ゾーン転送はこのRRの設定によって動作する

  • ネガティブキャッシュのTTLであるため、86400のような大きな値を設定しないように。

  • NSにはCNAMEを使用してはいけない

  • AAAA(クワッドエイと読む)
  • .in-addr.arpa.
  • 1つのアドレスに複数のPTRレコードを記述できる

  • TXT

  • SPF
  • DKIM
  • DNSBL

様々な目的で使用される

RRは1行で示される

複数行になる場合はカッコ ()で括るそうです。

$ORIGIN example.com.
  • @はオリジンを意味する
  • ゾーン頂点のドメイン

  • $TTL TTL

  • デフォルトのTTLを指定した値に変更する

  • クラスINは省略可能

  • $INCLUDE ファイル名のファイルを挿入する

  • DNSメッセージ
  • EDNS0を使うとUDPでも

ちょっとここで怒涛のハンズオンが展開されましたが、ページをの大半を割いてしまうため、省略します。

ハンズオン – dig編

ゾーン転送が成功しているか調べる(シリアル値)ときはセカンダリサーバのシリアル値がプライマリサーバのシリアル値と一致していることを確認するそうです。目からうろこですね。

[ec2-user@v157-7-234-198 ~]$ dig conoha.jp. +nssearch
SOA ns1.gmointernet.com. hostmaster.gmointernet.com. 2014012105 3600 300 3600000 7200 from server 157.7.32.254 in 2 ms.
SOA ns1.gmointernet.com. hostmaster.gmointernet.com. 2014012105 3600 300 3600000 7200 from server 157.7.33.254 in 1 ms.
SOA ns1.gmointernet.com. hostmaster.gmointernet.com. 2014012105 3600 300 3600000 7200 from server 2400:8500:3fff::254 in 2 ms.
SOA ns1.gmointernet.com. hostmaster.gmointernet.com. 2014012105 3600 300 3600000 7200 from server 2400:8500:3000::254 in 1 ms.

ちなみに +multiline オプションをつけると綺麗に整形されて表示されるそうです。
便利ですね。

[ec2-user@v157-7-234-198 ~]$ dig @8.8.8.8 jp. SOA +dnssec +multiline
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 jp. SOA +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20695
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;jp.            IN SOA
;; ANSWER SECTION:
jp.         21592 IN SOA z.dns.jp. root.dns.jp. (
1404543604 ; serial
3600       ; refresh (1 hour)
900        ; retry (15 minutes)
1814400    ; expire (3 weeks)
900        ; minimum (15 minutes)
)
jp.         21592 IN RRSIG SOA 8 1 86400 20140728174502 (
20140628174502 33429 jp.
RX0UdYgW3YBVNfIjvuyB8t1G630o7x2XZgIAZ0Ab8jyZ
G7YTCh2kdfFodJKdJYC9Xi+k9ecydB7V1cNqKm4/u1io
ejmKPGoU8SqYX+W5iUpH8JRMtXhi9tPg2+f1roZocuhc
tsgdEj7GzZLJzaWvjfPCLnDwhPjy7j6idxp9kkA= )
;; Query time: 66 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul  5 16:10:52 2014
;; MSG SIZE  rcvd: 240

リゾルバについて

スタブリゾルバ

  • キャッシュはMAY

フルサービスリゾルバ

  • キャッシュはMUST

  • 全世界に公開するとオープンリゾルバになってしまう

前々から気になっていて、質疑応答の時にGoogle Public DNS(8.8.8.8, 8.8.4.4)はオープンリゾルバですかと確認したのですが、
オープンリゾルバだそうです。だけど受けるところと出すところを別にしていたりシてかなり工夫しているらしいです。
すごいなー。

  • セカンダリは複数OK
  • マスター、スレーブ
  • スレーブからゾーン転送要求を行う

  • AXFRにはTCP

  • IXFRにはUDP

  • 伝搬遅延

  • NOTIFYで解決

  • ゾーン転送(NOTIFY)についてはRFC1996

オープンリゾルバであることの何が悪いのか

  • UDPのソースIPは簡単に詐称できる
  • DNSリフレクション
  • 毒入れをしやすくなる

講師さんが前述のGoogleスプレッドシートの別のシートに転写した内容をコピペして makezone.sh で自動生成されました。
シェル芸職人・・・。

Unbound

今回はBINDを使わないそうです。
というかBINDはBIND10で開発が終了してしまったらしく、次のものも微妙?なのだそうです。

ここではフルサービスリゾルバにUnbound、権威サーバにNSDを使います。

日本Unboundユーザー会

滝澤氏が翻訳されたサイトとのことです。

Unbound

  • Unbound 1.4.14以降、この2年間は脆弱性はみつかっていない
  • RHEL7は標準でUnboundはインストールできる。
  • デフォルトの設定でローカル動作可能(オープンリゾルバとはならない)
  • NXDOMAIN

NSD

NSDの特徴

  • リゾルバ機能なし
  • 設定ファイルがシンプル
  • NSD 3.2.13以降は脆弱性は見つかっていない
  • 昨年NSD4がリリース
  • nsd-controlによる制御
  • パターン
    • 動的にゾーンの追加・削除が可能

ハンズオン – Unbound編

ConoHaのVPSでは標準でEPELのリポジトリが登録されているそうです。

sudo yum --enablerepo=epel install unbound
cd /etc/unbound
sudo cp -p unbound.conf{,.orig}
sed '/^.*#/ d;/^$/ d' unbound.conf

設定ファイルをコメント抜きで俯瞰すると以下のとおり。
なんだかYAMLっぽい。

server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: yes
extended-statistics: yes
num-threads: 2
interface-automatic: no
outgoing-port-permit: 32768-65535
outgoing-port-avoid: 0-32767
max-udp-size: 3072
chroot: ""
username: "unbound"
directory: "/etc/unbound"
log-time-ascii: yes
pidfile: "/var/run/unbound/unbound.pid"
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: yes
harden-referral-path: yes
use-caps-for-id: no
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
dlv-anchor-file: "/etc/unbound/dlv.isc.org.key"
trusted-keys-file: /etc/unbound/keys.d/*.key
auto-trust-anchor-file: "/var/lib/unbound/root.anchor"
val-clean-additional: yes
val-permissive-mode: no
val-log-level: 1
include: /etc/unbound/local.d/*.conf
remote-control:
control-enable: yes
server-key-file: "/etc/unbound/unbound_server.key"
server-cert-file: "/etc/unbound/unbound_server.pem"
control-key-file: "/etc/unbound/unbound_control.key"
control-cert-file: "/etc/unbound/unbound_control.pem"
include: /etc/unbound/conf.d/*.conf
  • 必要に応じて、interface, access-controlを
  • 設定
     - デフォルト値は⼩規模向けなので⼤規模向け
  • ⽤途の場合にはチューニングも⾏う。

このへんのハンズオンはかなり複雑なので省略します。

NSD

ハンズオン – NSD編

NSD 4のRPMパッケージは提供されていない。ので滝澤氏自身がビルドされたRPMをインストールしました。

[ec2-user@v157-7-234-198 ~]$ wget http://www.sub.emaillab.jp/nsd-4.0.3-1.el6.x86_64.rpm
--2014-07-05 17:29:52--  http://www.sub.emaillab.jp/nsd-4.0.3-1.el6.x86_64.rpm
www.sub.emaillab.jp をDNSに問いあわせています... 2400:8500:1301:813:a157:7:234:430, 157.7.234.43
www.sub.emaillab.jp|2400:8500:1301:813:a157:7:234:430|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 404 Not Found
2014-07-05 17:29:52 エラー 404: Not Found。

おっと、IPv4でダウンロードしないといけなかったですか。

[ec2-user@v157-7-234-198 ~]$ wget --4 http://www.sub.emaillab.jp/nsd-4.0.3-1.el6.x86_64.rpm
wget: unrecognized option '--4'
使い方: wget [オプション]... [URL]...
詳しいオプションは `wget --help' を実行してください。
[ec2-user@v157-7-234-198 ~]$ wget -4 http://www.sub.emaillab.jp/nsd-4.0.3-1.el6.x86_64.rpm
--2014-07-05 17:30:47--  http://www.sub.emaillab.jp/nsd-4.0.3-1.el6.x86_64.rpm
www.sub.emaillab.jp をDNSに問いあわせています... 157.7.234.43
www.sub.emaillab.jp|157.7.234.43|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 792320 (774K) [application/x-redhat-package-manager]
`nsd-4.0.3-1.el6.x86_64.rpm' に保存中
100%[====================================================================================================================================>] 792,320     --.-K/s 時間 0.04s
2014-07-05 17:30:47 (19.8 MB/s) - `nsd-4.0.3-1.el6.x86_64.rpm' へ保存完了 [792320/792320]

インストール。

[ec2-user@v157-7-234-198 ~]$ sudo rpm -ivh nsd-4.0.3-1.el6.x86_64.rpm
準備中...                ########################################### [100%]
1:nsd                    ########################################### [100%]

これ以降のハンズオンもかなり複雑でしたので省略します。

怒涛のハンズオンが終了していよいよLTに突入です。

LT

@tukiyo3 さんによる「 Web系,社内インフラ担当向けTips紹介 」

LT資料 (夏のDNS祭り 2014 ~入門セミナ&ハンズオン~) – Qiita
Tips – MindMeister 思考マップ

  • メールの送り合戦になってしまった
  • nagiosが上がると電話がかかるようにした
  • whoisで所属する社員一覧をとってきたり
  • シェル芸職人。

@toshi__ya さんによる「 DNSキャッシュサーバのベンチマークテスト 」

@toshi__ya

スライドはこちら。

Dns 20140705 up_ver

  • dnsperfを用いてDNSサーバの負荷試験を実施する。
  • BIND10を起動しただけだと権威サーバにもならなければキャッシュサーバにもならない
  • unbound.confのチューニングが必要だ!!
  • キャッシュメモリの量とか増やせばいい?

@twovs さんによる「パケットが教えてくれたルートサーバが 13個の理由 」

@twovs

スライドはこちら。

パケットが教えてくれた ルートサーバが 13個の理由

512バイト中に13個入るか試してみたそうです。

だが、途中で13個も入らないんじゃないかという結論に達しそうになり、

I can compress RRs a little. ワタシハ アッシュク チョットデキル

という事実に気付いたそうです。

Message Compressionを頑張って頑張って収まることがわかりました。
14個目も入るか試してみたそうです。
収まったそうです・・・。

がんばればrootサーバ14個もいける。

DNS勉強会の開場ネットワークを作ってみた

LTではありませんが、最後にこの勉強会のインフラを構築してくれた方々よりご紹介がありました。

  • PyConのネットワークを構築する
  • 快適なネットワークを皆様に届けたい!!
  • splunk
  • VPN Gate
  • L2スイッチの下に

routerboard

  • syslogやSNMPの取得が可能
  • 持ち込んだスイッチのSpanning-treeが生きておりUplinkがShutdown

BuffaloのAP買ってこようかとした!

IPv6をどうやって構築したか

SoftEtherPacketiXで自宅にVPNしてIPv6貫通してた。
会場で驚きの声があがりました。

Splunk

リアルタイムにログを可視化できる。

まとめ

怒涛のハンズオンは終了いたしました・・・。
うーん、最後のNSDのハンズオンは苦戦してしまいうまくいきませんでした。

ただ、自分の知っているようで知らなかった事実が色々とあって、
BINDとか少し設定できるし、ちょっと復習的な感じになるのかなーと思っていましたが、
大違いで、いい感じで期待を裏切られました。

懇親会に参加しました

渋谷人多い!

その後は生まれ始めて勉強会の懇親会にも参加して色々な方とお話することができました。
自宅ラック勉強会の方々やハートビーツの講師滝澤さんともお話することができました。
ガチでインフラ系のエンジニアの方々の生の声が聞けてかなりネットワーク関係の自分の知識不足感を実感して
いい刺激を受けることができました。

どちらかというとWeb系のシステムエンジニアなので、異なった視点の話題を交わすことができてとても面白かったです。

以上、DNSがちょっとできるようになった体験記でした。