運営中

Labee Dev Toolbox

ドメインの設定を外側から確認するWebツール集。

何を解いているか

ドメインの設定は、外から見た結果でしか確認できません。DNSが引けているか、証明書が生きているか、SPF / DKIM / DMARC が意図どおりに並んでいるか。手元の dig と openssl でも足りますが、毎回コマンドの形を思い出すところから始まります。

なぜ作ったか

会社員、個人事業主、ラビー合同会社の代表という複数の立場で開発に関わるなかで、「あると便利だけれど毎回探すのが面倒」なツールが手元に散っていました。それをまとめて1か所に置いたのが Labee Dev Toolbox です。 登録もAPIキーも要りません。確認したいだけの用途に、アカウント作成という手続きを挟みたくなかったためです。ブラウザから開いても、コマンドラインから叩いても、同じ結果が返る形にしています。

設計の判断

  • 登録を挟まず、IP単位で絞る

    確かめたいだけの用途に、アカウント作成を挟まないことを先に決めています。 利用者を識別しない代わりに、IPアドレスを鍵にした毎分の上限をエンドポイントごとに置いています。 外部へ実際に接続するSSL確認は10回、DNSとメール認証は30回、IP確認は60回と、処理の重さで数字を分けています。

    アカウント登録やAPIキーを置かず、クライアントIPを鍵にした毎分の上限をエンドポイントごとに設けていることを示す図
    識別はアカウントではなくクライアントIP。上限はエンドポイントごとに分けている
  • 画面をAPIの薄い前面に置く

    Webの画面とコマンドラインで別々の実装を持たず、どちらも同じAPIを呼ぶ形にしています。 画面はそのAPIの薄い前面という位置づけで、結果の形も共通です。 OpenAPIの定義とドキュメントも同じ定義から出しています。

    入力欄の内容がブラウザの fetch と写して使える curl の両方になり、どちらも同じエンドポイントに届くことを示す図
    入口は2つでも、届く先は同じハンドラ。検証関数も画面とサーバーで共有している
  • 確認の実行はすべてエッジに置く

    外から見た結果を返すという性質なので、確認の実行はすべてエッジに置いています。 利用者のブラウザから直接叩く形にはしていません。 DNSやメール認証の問い合わせ元を一定に保てるほか、ブラウザから到達できない確認も同じ枠で扱えます。

    手元の dig や openssl では自分のリゾルバのキャッシュしか見えないのに対し、labee.dev は Cloudflare Workers のエッジから DoH と HEAD を投げ、その手前で宛先を制限していることを示す図
    手元のコマンドと違い、問い合わせはエッジから出る。その手前で宛先を絞る
  • ツールを4つに削り、1画面に収めた

    収録するツールは4つに絞っています。 以前は18以上を並べていましたが、ドメインの設定を外から確かめるという一点に用途を寄せ、それ以外を落としました。 残したのはDNS、SSL証明書、メール認証、IPの4つで、1画面に収まる数にしています。

    18以上あったツールを3つの条件で絞って4つに減らし、1本の動的ルートと1つの画面、4枚のパネル、共通の枠という構造に収めたことを示す図
    残す条件を3つ決め、通った4つだけを1本のルートとタブ1枚に並べた

提供形態

対応プラットフォーム
Web
価格
無料
登録
不要(APIキーも不要)
確認できる項目
DNS、SSL、メール認証(SPF / DKIM / DMARC / BIMI)、IP
利用方法
ブラウザ / コマンドライン
プラットフォーム
  • Web

開発の記録

Labee Dev Toolboxを作るなかで書いた記事です。

ほかのプロダクト

ほかに開発・運営しているプロダクトです。

← 自社プロダクト一覧へ