TSIGについてまとめてみた(未整理)

DNS memo

TSIG って何

ゾーン転送における、スレイブサーバ側の、マスターサーバからのなりすまし防止のための仕組み。

スレーブ・サーバのゾーン転送とセキュリティ (3/3)：実用 BIND 9で作るDNSサーバ（5） - ＠IT
http://www.tatsuyababa.com/NW-DNS/NW-200302-DNS07.pdf
https://jprs.jp/tech/material/rfc/RFC2845-ja.txt

TSIG（Transaction Signature）。
TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします。

鍵生成コマンド

結構時間がかかる。中々結果が返らなくてもあせらない。

/usr/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -n HOST example.com
# 結果
$ ll *key
 Kexample.com.+157+13212.key ( key の前の数字はランダム？)
$ ll *private
 Kexample.com.+157+13212.private ( private の前の数字はランダム？)

bind への設定 (マスターサーバ・スレーブサーバ両方での設定)

生成された「Kexample.com.+157+*.key」ファイルを開くと以下のようになる。

cat  Kexample.com.+157+13212.key
example.com. IN KEY 512 3 157 jRRJA...(省略)

の 157 以降「jRRJA...(省略)」部分を /etc/bind/tsig-keys/example.com.key (bind:bind 600) で以下のように保存。
なお、本操作は root 権限での実施が望ましい。(というかじゃないと操作できなかったっぽい)

key example.com {
    algorithm hmac-md5;
    secret "jRRJA...(省略)";
};

bind への設定方法

http://www.tatsuyababa.com/NW-DNS/NW-200302-DNS07.pdf
に記載の通り。named.conf に以下のように記載する。

TSIG付きDNSダイナミックアップデートの設定（named.confファイル）

# 正引きゾーン sample
zone "example.com" {
        type master;
        file "example.com.zone";
        allow-update { key ddns.example.com.; };
};
# 逆引きゾーン  sample
zone "0.168.192.in-addr.arpa" {
        type master;
        file "0.168.192.in-addr.arpa.zone";
        allow-update { key ddns.example.com.; };
};
# TSIG鍵の設定  sample
key ddns.example.com. {
        algorithm hmac-md5;
        secret "iSUuKtizDJEK/9ptgewTHQ==";
};

セカンダリサーバにおけるゾーン転送の設定（named.confファイル）

// TSIGを使用するサーバの設定
server 192.168.0.10 {
keys { axfr.example.com.; };
};
// TSIG鍵の設定
key axfr.example.com. {
algorithm hmac-md5;
secret "nAgPY1cTo8HJ/FXw1waaow==";
};

NAPTR レコードについて調べたページまとめ(未整理)

DNS memo

とりあえずURLリスト

お仕事で調べたり、これから使いそうな NAPTR に関する URL集。
あとで優先度順に並べるのと感想を書く。 途中でも公開。

RFC 類

その他

レコードはこんな感じらしい

Regexp が謎。

NAPTR * Label * zone apex のみ可

  • Order

    • 16bit符号無し整数 (0-65535)

  • Preference

    • 16bit符号無し整数 (0-65535)

  • Flags

    • NAPTR レコードの DNS 検索動作を指定します
    • 種別
      • "u" or "U"：URI を出力
      • "s" or "S"：Replacement フィールドのラベルを SRV 検索したものを最終結果として出力
      • "a" or "A"：Replacement フィールドのラベルを A, AAAA 検索したものを最終結果として出力
      • "p" or "P"：アプリケーション依存の動作を行う (未定義)
      • ""：DDDS の反復処理

  • Services

    • リソースレコードが対象としているサービスを指定
    • 例
      • SIPサービス：E2U+sip
      • H.323サービス：E2U+h323
      • 電子メールサービス：E2U+msg:mailto
      • Webサービス：E2U+web:http

  • Regexp

    • E.164番号 (ENUM 番号) からURIを生成するための置換文字列を指定

  • Replacement

    • Regexp とは排他で、使用しないときは "." を指定

SRVレコードについて調べたページまとめ(未整理)

とりあえずURLリスト

お仕事で調べたり、これから使いそうな SRV に関する URL集。
あとで優先度順に並べるのと感想を書く。 途中でも公開。

RFC 類

RFC2782 サービスの場所を指定するＤＮＳ資源レコード（ＤＮＳ ＳＲＶ）
RFC2219 ネットワークサービスへのＤＮＳ別名の利用

RFC2052 日本語訳 - [RFC/技術資料] ぺんたん info 2052 よりは、2782 のほうがわかりやすそう？目的が違うのかしら？

その他

www.atmarkit.co.jp
www.atmarkit.co.jp
そもそもの発端。NAPTR を調べてたら、SRV の話が出てきたので調べ始めた。

レコードはこんな感じらしい

左辺 Service (アンスコ)始まり 大文字・小文字の区別が必要 Proto (アンスコ)始まり 大文字・小文字の区別が不要 Name 右辺 Priority 0-65535 Weight 0-65535 Port 0-65535 Target 参照先が CNAME は NG RData が外部 or 内部で A/AAAA を登録 を登録してないとだめ ホスト名ではなく「.」とした場合は、サービスが利用不可

WACATE 2019 夏 ～ テスト計画半端ないって ～

はじめに

注意：WACATE のテーマとタイトルが違うのは、私が一番大事だと思ったことをタイトルにしたからです。正確には「WACATE2019 夏 〜納期半端ないって！〜」です。

WACATE 翌日で、当日よりは落ち着いてるけどまだ当日分の加速装置が働いている状態で書いています。
今回の記事のメインターゲットは「私」。 正確には「未来の私」です。
なので、なんか違うなって思ったら関係リンク先にどうぞ！

関係リンク

BPPセッション

speakerdeck.com

中村さんのセッション

www.slideshare.net

中野さんのセッション(BGMは矢野顕子)

www.slideshare.net

toggetter

togetter.com

WACATE のページ

wacate.jp

WACAくないけど WACATE に行ってきました！夏

というわけで、予防線を張りつつ、感想です。
今回の WACATE のメインテーマは「納期半端ないって！」です。

まずは 2019年夏のWACATE について、ズバッとよかったこと、感銘を受けたこと、その他感想を箇条書きで並べます！

  • 記事名の通り。テスト計画スゲー――――！！！！！
  • 夜の分科会で、ブロッコリーさんと中村さんのお話を聞けてとても良かった(詳細は内密)
  • 中野さんのセッションマジよかった。脳疲労と達成感で脱力しまくっている中でもちゃんと頭に入ってきたし、ワークをやったからこそ、より染み入った
  • The 10 Minute Test Plan 私もまずは取り組んでみよう
  • Rex Black スゲーーーーーー！
    • テスト計画を作るよりも、合意形成、期待を合わせることが大事
    • テスト計画はステークホルダーに意思表示すること、責務を知らせることが重要
  • テスト計画の可能性をあきらめない(だったっけ…？)ということ。これ、テスト計画に限らずだなあと思った。どうせ使えない、じゃなくて、なぜ使えないのかを考えようと思う
  • バグを見つけるためにはまず整理されていた方が効率的に見つけることができる
  • チームマネジメントは難しいし、テスト方針を貫くことも難しい
  • テスト設計、実装、実行のすべては、テスト計画、分析があってこそだなあと思った

当たり前じゃん、と思うことも多いかもしれないですが、改めて体感できてよかったと思うことと、そそそそそうだったのかーーーーー！と驚くこともありました。
きっと未来の私は「こんなの当たり前に実践できてるよ！」って見返したときに言うはず。

かように学ぶことは大量でした。

行く前の感想

現在の業務について、まずは説明しますね。これが前提になってくるので。

  • テスト対象：法人向けのWebサービス
  • テスト納期：基本は 2，3週間前後でテスト計画から出荷判定までを行う
  • テストレベル：とりあえず開発がコンポーネントテストまではやってくれてるといいなあという状態。システムテスト相当の評価を実施
  • 現在の状況：上記の基本 PRJ のほかに、Phaseが複数に分かれる、約 半年に渡る評価 PRJ を担当。常時 2、3 PRJ の PL をしている

という状況で、WACATE 夏のテーマを知った私は「ｳｪｰｰｰｰｰｰｲ！これは私のためのプログラムなのでは？」と浮かれ果ててました。 何しろ、上記の状態なのにテスト計画もろくにない状態でプロジェクトを日々進めていたからです。
この状況を打開せねばならない、しかし、まさに木こりのジレンマ状態。振り上げた斧を下ろすことも、ましてや研ぐこともできない状態でした。(まあ今もまだそうです)

ちなみに、1年前の私はポジぺにこんなことを書いてましたね…

サイクルの早いテストをこなすのでいっぱいいっぱいになってしまい、本来やるべきテストプロセスがおろそかになっている。

か、、、変わってない、、、。(つд⊂)ｴｰﾝ
以前に比べると「要求分析をちゃんと明示的に行うようになった」「開発チームと評価項目のレビューを行うことがプロセスに明示的に組み込まれるようになった」という点では変わりました。
しかし、その中で何をやるのかは各PLに任されており、誰もがこれでいいのか…？と思っている状態でした。(たぶん…。いや私以外はもしかしたらこれで完璧って思ってるのかもしれないですけど)

行った後の感想

作ったものに対してステークホルダーに共有して合意をとる、というのが大事なのは「知って」いました。
だけど、実際には先にあげたとおりの「スピード感」というワードでやらないことをごまかしていたように思います。
実際、テスト計画まではいかなくても、テスト方針を書いて伝えたプロジェクトでは、テスト設計で大きなぶれなくテストができたことを思い出しました。
その時は設計者と PL の間だけのものだったけど、それをちゃんとプロジェクトの開始時点で開発と握って、変わりそうなら開発と握りつつ進めないといけなかったんだな、と思いました。

私に足りなかったのは「テスト計画をステークホルダーと握ること。」
「何のためにテスト計画を作るのかをちゃんとは理解していなかったこと」
この 2 点かなあ。

QAエンジニアになって今更感はあるけど、少しずつチームにテスト計画の意義を共有、浸透していければいいと思いました。

最後に

当時の自分のつぶやきを残して、記事を終えたいと思います。

テスコン要求分析チュートリアル前半

記事内容

完全に自分のツイートをまとめただけ。

参考資料

テスト要求分析チュートリアル資料

http://aster.or.jp/business/contest/doc/2019_TRA_1-3_V1.0.0.pdf

ザクっとした感想

テスト要求分析って、なんとなくやったつもりになってるし、なんとなくできちゃう。
これってどういうことかというと、説明はできないんだけど、長年の勘と経験でやれちゃってます、ってパターンがすごく多いってことだと思う。

そのまま同じような差分開発の評価を続けていると、うまくいったように見えていても、どこかに大きな落とし穴があったりして、でも要求分析してないし、そのあとの設計もふんわりするから、落とし穴に気づけないままはまって「なぜ…こんなことになったのか…わかりません…」みたいなことになるんだと思う。

それじゃあかんでえ、と、今回のイベントでは言ってた。
自身の所属する組織や、求められる品質や、開発規模、その他もろもろの要因によって求められる要求が違うので、そこら辺を加味しつつ、

  • どういった目的でテストするか
  • どこまで、どんなテストをするか

といったあたりを、きちんと根拠をもって、かつ言語化して、ステークホルダーと合意をとりつつ、トレーサビリティをもって要求分析をしましょうね、という風に理解した。

Twitterまとめ

自分のつぶやき。基本的には右矢印(→)から先がその時ふわっと思ったこと。 その手前は資料のメモだったり、講師の人が話してたこと。

Selenium & Edge & Python

Selenium で Edge を動かそうとして詰まりを解消したメモ

自社研修で Selenium で Edge を動かすための環境構築にちょっと苦労したのでメモを残す。

Edge のバージョンが 17 までと、18 以降で手順が違うぞ？！問題

  1. Microsoft の以下のページから、自身の Edge のバージョンとあった webdriver.exe を落とすように言われた…
    developer.microsoft.com

f:id:mktk0808:20190215230107p:plain
Edgeバージョンとwebdriver

('ω')
18はないでござる...

当然古いバージョンではエラーになってしまう...

調べてみたら、

WebDriverの改善 WebDriver を利用した Microsoft Edge での自動テストがより簡単になりました。

これまで WebDriver を使用して自動テストを行う場合、ダウンロード用の Web サイトに赴き、テストする Edge のバージョンに合わせて個別のパッケージを別途入手する必要がありましたが今回のアップデートにより Windows Feature on Demand(FOD)、つまり Windows 10 の [設定] - [アプリと機能] の中にある [オプション機能の管理]からインストールして使うことができるようになりました。しかも Windows Update により WebDriver のバイナリも自動的に更新されます。

Windows 10 October 2018 Update に搭載されたMicrosoft Edge(EdgeHTML 18)の新機能 – monoe's blog

とあったので、その通りに Microsoft Webdriver をインストールしてみました。

引っかかりポイント 2つ目

もともとは、以下のように webdriver.exe と同じディレクトリに python のファイルを置いて実行していたのですが、当然ファイルは無いのでエラーになります。古いファイルを実行しても、もちろんエラーになります。

#Edgeを操作
driver = webdriver.Edge(executable_path=".\\MicrosoftWebDriver.exe")

困ったなあ…と思ってたら、ぴんときました。
さっき落とした webdriver がこのPCのどこかにいるんじゃない？と。

調べてみたら、c:\windows\system32 の下にいました。 そこで、今度は

driver = webdriver.Edge(executable_path="C:\Windows\System32\MicrosoftWebDriver.exe")

こうしてみたら動くようになったのですが、先輩に確認したところ、そもそも環境変数が通っているところなら、executable_path はいらん！ということで、

driver = webdriver.Edge()

これで動くことが確認できました。ちゃんちゃん。

DNS 勉強会資料 2日目：レジストリ・レジストラ？(memo)(教育)

DNS をはじめよう 2日目

全体の流れ

以下の流れで話が出来たらいいな・・・

レジストリ・レジストラとは？

  1. レジストリ：ドメイン名の一元管理を行う役割を担う
  2. レジストラ：ドメイン名登録者からの申請を取り次ぐ役割を担う

1 つのTLD ( DNS 勉強会資料 1日目：ドメイン名って何？(memo)(教育) - 備忘録～小さなことから大きなことまで～ 参照) には 1つのレジストリ、が原則です。
ただし、1つのレジストリに対して、レジストラは複数であることが多いです。

f:id:mktk0808:20190109112654p:plain
レジストリ・レジストラ

お名前.com やサクラインターネットなどのほかにも様々なレジストラがいます。

レジストラの役割
  • 登録者からの登録申請の受付
  • レジストリデータベースへの登録依頼
  • Whois サービスの提供
  • 登録者情報の管理

レジストラは、ドメイン名を登録したい人(もしくはその取次ぎを受けた人(リセラ))からの申請情報を受け取り、レジストリが管理するデータベースへの登録依頼を行います。

レジストリの役割 ( 抜粋 )
  • レジストリデータベースの運用管理
  • ドメイン名の登録規則の策定
  • 登録申請の受付
  • Whois サービスの提供
  • ネームサーバの運用

ドメイン名って何？のなかでも説明しましたが、インターネット上のIPアドレスを特定するための仕組みが DNS です。 例えば example.jp が複数存在してしまうと、いったい私がアクセスしたい example.jp はどれなの？となり、違う宛先にアクセスしてしまうことも考えられます。

そうならないために、「レジストリデータベース」でドメインを一元管理するわけです。

.jp ならば、JPRS がドメインを一括で管理するので、example.jp というドメインを取得したとしたら、example.jp = xxx.xxx.xxx.xxx というIPアドレスを紐づけることによって、インターネットを通して、example.jp にアクセスできるようになるわけです。

おまけ情報

前述のとおり、ドメインの重複は許されません。が、テストなどで適当なドメインを使用してしまうことがありませんか？ それがテストの範囲内で収まってて、インターネット上にでないのであれば問題ないのですが、もしでている場合、きちんと制約をかけないとそれは誰もがアクセスできるものになってしまいます。
ルール上、「example.jp, example.com」といった、「example」というドメインはドメイン登録できない(しない？)ことになっていますので、テストで使う場合は「example」を使ってみてください。

よくテストで使われる「hogehoge」は実際に使用者がいるのでなるべく避けたほうが無難です。

   Domain Name: HOGEHOGE.COM
   Registry Domain ID: 1979393_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.jprs.jp
   Registrar URL: http://jprs.jp/registrar/
   Updated Date: 2018-01-26T17:30:19Z
   Creation Date: 1996-03-09T05:00:00Z
   Registry Expiry Date: 2019-03-10T04:00:00Z
   Registrar: Japan Registry Services Co., Ltd.
   Registrar IANA ID: 1485
   Registrar Abuse Contact Email: gtld-abuse@jprs.jp
   Registrar Abuse Contact Phone: +81.352158457
   Domain Status: ok https://icann.org/epp#ok
   Name Server: NS1.DNS.NE.JP
   Name Server: NS2.DNS.NE.JP
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2019-01-09T03:51:33Z <<<

今日はここまで。