  |
はてなキーワード: DNSとは
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）: Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）: Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
Core Web Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 | ホーム</title>
<meta name="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml" title="RSS" href="/feed.xml">
<meta property="og:title" content="あなたの名前 | ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home / About / Posts</nav>
<footer>© 2025 あなたの名前</footer>
GitHub Pages（Jekyll標準。Rubyベース、Node不要）
Cloudflare Pages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C. ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：Search Consoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
Route 53 の“データプレーン（DNS応答）”は SLA 100% と明記されています。
ただしこれは「停止がゼロを保証」ではなく、停止があればサービスクレジットで補償するという“契約上の約束（SLA）”です。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
https://anond.hatelabo.jp/20240722084249
根源的に悪いのは広告業者ではあるんだけど。
軽く調べた限り、画面一番下の小さなバナー動画広告枠が表示されたらアウト。表示されない時もある。しかしこいつがCPU消費モンスター。
私の iPhone 12 mini (経年劣化によるバッテリー最大容量は81%)は、Togetterを開いて7分でバッテリーを10%減らした。
計測方法: 画面の輝度40%くらいで、 https://togetter.com/li/2610053 (JR東日本の全ての指定席券売機が...) の画面を開いて放置。 51%が50%になった瞬間から、40%になった瞬間まで、当該広告ありだと7分20秒で10%減。 その直後に画面下のバナー動画広告枠だけをバツ印で消して、さらに放置。 41%が40%になった瞬間から、39%になった瞬間まで、当該広告なしだと34分43秒で1%減※。 ※ バナー動画広告枠を消したら画面の自動ロックなしで放置してもぜんぜん減らないので、10%ではなく1%で計測をやめた。
iPhoneだと、はてなブックマークアプリ内のWeb表示には、Safariに入れてる広告ブロックが効かないのよね。
小さなバツ印を(精確に…)タップすればバナー動画広告枠は消えるので、気になる時は面倒でも消したほうがいいよ。
他のサイトでも起きてるとは思うんだけど、はてブやってるとTogetterをたくさん閲覧しがちなので…。
アプリをやめて、広告ブロックが効くブラウザ版のはてブを使うことも考えたけど、いろいろUIが違うからいまひとつだね。
技術的な話をすると
この広告枠は requestAnimationFrame を毎秒60回呼び出してアニメーション表示させてて、それ自体はまっとうな手法としてありうるんだけど、たぶん呼び出しのたびに余計な処理をしてるからCPUを爆食いしてしまってるんだと思う。なにやってんだか。この手のCPU爆食いはPC向け広告でも氾濫してるので、広告ブロックにはCPUやメモリの消費を抑え、発熱とファンの回転騒音を減らし、バッテリーを長持ちさせる効果もあるのだ。(追記: モバイルでは通信容量の節約もできるね)
追記:
280blockerは入れてるけど、はてブアプリ内のTogetterには効かないんだよね。月額100円/年額900円のプレミアムプランなら効くのかな？効いたという報告 https://x.com/yukai_han/status/1685466299064016896 はある。これは280blockerのDNSブロック内のプレミアムプラン向け「アプリ広告専用設定」のことかな。
VPN系の広告ブロック機能だと効くような気もするけど未検証。
追記2:
ブコメ有識者のおかげでブロックできた！280blockerのDNSブロックは、280blockerアプリ内だけでなくiPhoneの設定アプリからも設定が必要 https://280blocker.net/ios-dns-settings/ だったんだね…！うおお…！！！
https://b.hatena.ne.jp/entry/s/internet.watch.impress.co.jp/docs/column/horisage_qa/2035773.html
解説:: HTTPSなら暗号化されてる？うんうん。でも、だれがどこにアクセスしたかはバレバレなのよ？IPアドレス暗号化してるとか思ってないよね。
エッチなサイト(うふふ)とか証券サイトみてると、フィッシングサイト狙い撃ちしやすいから気を付けようね。
起きること:: セッションCookie盗まれたり、偽サイトから攻撃サイトに誘導されて釣られる。
解説:: DNSでサイト乗っ取手もHTTPSの証明書エラーで気付く。うんうん。でも、HTTPSをHTTPにダウングレードされたら、あなたのCookie丸見えよ？Scureで大丈夫？サーバーのバグでアウトね。
うんうん。Cookieがダメでも、偽のHTTPサイトでリダイレクト誘導して、攻撃サイトに移動すればセキュアで保護されるので、このフローに警告なんて一切出ないね。
"こちらです"安易に踏んでない？ログインの時にドメインが完全にあってるなんて毎回検証してる？
SSL Strip攻撃といいます。AI曰く、まだまだガバガバみたいよ？
その中でHSTS導入済み: 約31%
HTTPS導入済みかつHSTS未導入: 約54-57%
DNSキャッシュポイズニングの餌食になっていたら口座開設しようとした人はもろに個人情報を盗まれることになる。
IPアドレスを書けばいいのに。サポセンに聞けば教えてくれるか？
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250718165845# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaHn+wAAKCRBwMdsubs4+ SF3EAQDd3j8bZ3ULRIab+zLTUpUJIewPcHdwRFh6+KY0VpUnRgEA3f5ZIL7/MnhX iCaq15hatJDpIaVX8zva2NAszLrtxw0= =OxMC -----END PGP SIGNATURE-----
SBIのような大手は偽サイトがつくられやすいと思うしたとえ公式のパンフレットに書いてあるアドレスもDNSがウイルスでやられちゃってて偽サイトにつながってしまう危険がある。
するとサポセンに電話して「サイトのipアドレス教えてください」って聞くぐらいしか安全な方法が浮かばないが変に思われないだろうか？
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250718010726# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaHn9vAAKCRBwMdsubs4+ SETGAQC6R+LLnMOKlL1oqTakmq9DYwExaRYrM9V0k4gpac3ZxgEArGLYlV9wfpKX Gh6r0hGUiQ7z5ARgPFs95410z2XsywA= =F69W -----END PGP SIGNATURE-----
あなたがWebコンテンツの開発に関わっていないような人であれば気にしないでいいよ。みんなが専門家である必要はないのだから。
でもね、他人からお金をもらってWebサイトの公開作業やメールを使えるようにする設定をしているような人だったら、何が悪いのかを理解する努力をしたほうがいいよ。
ここやXなんかで「DNS 浸透」と検索すると「浸透言うな」と言われて反論してる人がいるけど、何で「浸透と言って何が悪いの？」とか言って感情的になる人が多いんだろうね。
こういうこと言っちゃう人は何も分かってないし、何が問題かを考えることすらしないんだよね。なんでだろうね。
最初にも書いたけど素人ならいいよ別に。勉強する必要性がないのだから。でも技術者だったらタイトルに書いた質問に答えられないのはどうかと思うよ。
表現の話じゃないんだよ。浸透の代わりに〇〇と言え、とか技術的に正確に言え、とか言っているわけじゃないんだよ。
DNSの仕組みを全く理解せずにDNSを利用していること自体が問題だって言ってるんだよ。
「浸透してないですね」とか「浸透するまで待つ必要があります」とか言って、無駄に時間を過ごしていることが問題だって言ってるんだよ。
「DNS 情報が時差を伴って更新されていく」なんてことはないのよ。何年待っても更新されないんだよ。DNSの仕組み分かってる？
っていうか「更新される」って何が？
何時間か待てば自然と情報が更新されるんだったらそれでも別にいいと思うよ。でもそんな仕組みじゃないんだよDNSは。
それとね、キャッシュされてる情報を即時に更新するような形でDNS情報を変更することはできるんですよ。仕組みを理解してれば誰でもね。
そういうことを理解せずに「浸透するのに何時間も待たなければいけない」とか言っている状況自体が問題だって言ってるんだよ。
「別に技術知ってる人にはキャッシュ切れで更新される云々言えばいいけど」じゃないんだよ。キャッシュ切れを長い時間待つこと自体が間違ってるって言ってるんだよ。
あのさ、英語の表現は正しいっていう思い込みをしている人がいるみたいなんだけど、それやめたほうがいいよ。
DNS Propagation って直訳すると「DNSの伝播」なんだけど、これ「浸透言うな」の指摘に引っかかる表現そのものなんだよ。
「DNSの浸透待ち」とか「Wait for DNS Propagation」とか言わずに勉強しろよっていうのが「浸透言うな」なんだよ。
だから何が悪いかも分からないし、論点のズレた反論をいつまでも言い続けるしかできないんだよ。
・ポートフォリオのためにreact, typescriptでアプリ作成
を帰宅後や休日コツコツやってる26歳男です。現職は旅行代理店。
ビルの喫煙所で一服してたら私服の男性2名が入ってきた。このビルで私服なのはIT系の会社だけ。仮にA社とする。
喫煙所に俺とその2人の3人しか居なかった。だからA社の人達の雑談が耳に入るんだよね。
そしたら断片的だけど「DNSが〜」とか「要件が〜」とかまあ、話していたわけよ。
外部で話したらダメだろということは置いておいて、今勉強している単語たちが断片的に聞こえるわけな。
そしたら「あーならこうすればいいのか」とか「なるほどね」とかどんどん盛り上がって来ていたわけよ。課題が解決したのかな。
ただ、難しい単語だらけ。
そしてたまに聞こえる知っている単語、俺が勉強しても勉強してもよく分からない概念だったりするわけよ。
それをさも当然かのように、まるで簡単かのように話しているわけよ。
見た目は汚いおっさんなんよ。私服もヨレヨレ。無精髭生やしてさ。
けど、その難しい概念を簡単に使いこなし、それでどんどん楽しくなって行ってる(ように見える)
心が折れかけた。なんか、レベルが違いすぎた。
それでも向こうは専門職で何年もやっているだけ。そう思いたい。
そこに、スーツの若い男が入って来た。2人に混ざって雑談開始。多分新卒さんかなあ。若いし、スーツだし。
するとさ、「基本情報簡単でした」みたいなことが聞こえて来たわけよ。
なんかさ、もうさ、怖い。
なんであれが簡単になるのさ。
人種が違いすぎる。
転職、別業種にしようかな。それとも同業種への転職にしようかな。
なんかさ、もうさ、本当にさ、エンジニアさんって凄いんだね。
TLSと何もかも一緒ってわけではなくて、あくまでアナロジーでしょ
信頼の検証方法とかそういう難しい話ではなくて、トポロジー的なこと
TLSの検証の進め方は末端であるリーフ（たとえばhatelabo.jpのサーバ証明書）から中間CA、ルートCAっていう風に下から上に辿る
DNSも同じツリー形式だけど、DNSの場合はルートからリーフに向かって問い合わせをする（.に問い合わせて、jpに問い合わせて、hatelabo.jpに問い合わせる）
戸籍は下方向(子孫)はそもそも既知なことが多いから、上位(祖先)方向へ向かって辿ることが多いよね
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらく TCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前に HTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えば anond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見える client IP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
ろくに規制も進まないで20年くらい野放図なままなんだから、広告ブロッカーを入れて各自自衛するべきだよというのは暴論ではなく非常に建設的な意見だろう。その意見だけは邪険にしないでくれ。
広告による収益化で多くのWebサービスが支えられてる時代になってしまっているのは現実だが、Webユーザーはそれを望んでるわけでも積極的に歓迎しているわけでもない。
だったらそれを拒否して無力化していく、したたかなユーザーが増えることで、Web広告が稼げない・時代にそぐわないマネタイズであるという認識と実態を広め、より建設的な、広告に依存しないWebのマネタイジング手法への移行を促していく必要があるだろう。
広告の仕組みは、あの手この手で本来顧客になり得ない人間の注意力や関心を奪い、嗜好を刷り込んでいくためにマインドハッキング的表現手法にきわめて近くなる、もともと悪質なものだ。デジタル世界ではその悪質さがより強く出る。
そういう悪質なゴリ押しが最適解になってしまうデジタル広告ではない、より健全なマネタイズをするようになったWebでは、今成り立っていたサービスでも成り立たなくなるケースが多発するだろう。
でもそれでいい。本来成り立っちゃダメな商業化が、Web広告の抱える野蛮さ、ズルさによって、成り立ってしまっている時代を終わらせなきゃいけない。
そのために抵抗が大きくなることは予測できるだろう。でもだからこそ、本当にWebの未来を真剣に考えるネットユーザーなら、Web広告を毅然と拒否しなくちゃいけない。
現実の物理世界を占有する誰かの所有物上の広告とは違い、デジタル世界では、自分の目に映るものを表示している自分が所有するコンピュータのクライアント側の描画内容は、利用者が弄れてしかるべきだろう。
弄るために十分コンピュータに造詣が深い必要はあるし、自分でその操作の責任を負う必要はあるが、そうしている限り、こうした行為は、アナログ的に目を滑らせて広告を無視することと同等の権利だ。
例えるなら、会社ロゴ入りのボールペンをタダで渡してくるのはそっちの自由だし勝手だが、それを私物として使うにあたってロゴを削り落として使う自由も勝手もこちらにある、という観点に近い。
ブロッカーを批判する人は、「そんなことするとロゴペンくれる人が悲しむよ！くれなくなるよ！削り落とさないでって規約に書いてるよ！」というロゴペンばらまき企業に同情的な人だろう。チラシ入りティッシュばらまきでもいいが。
だが、ブロッカーを使う人は、「くれなくなるなら別に構わない、もっといいペンを買うし、全員がロゴに好感を持たないことを見越してもともと迷惑ゴリ押しの自覚アリで宣伝効果を期待しばらまいているのだから、離反者が出るのも自分が離反側になる場合があるのも道理だろう」と考える。
なんらかの財物とペアにすればどんな押しつけも正当化されると考えているなら、それは非常に傲慢な姿勢だろう。宣伝効果が生じない人にまで宣伝をばらまいて不快を生じさせる至らなさの責任を末端ユーザーが背負ったり擁護したりすべきじゃないし、それを当たり前と思うのも加担になる。
ともかくそうした悪しき習慣に過剰適応してしまうインターネットしぐさが、今のWebをこんな宣伝押しつけパラダイスにした。
歩いていると3秒に1度はテッシュ配り人が動線に割り込んでくるがごとき時代に、ティッシュ内のチラシを一瞬で抜き取りペンのロゴを削り落とすテクを教え広めるのは、歪んだ現実に対する許容されるべき抵抗だろう。
ただし、広告ブロックができるソフトウェアというのは、その技術的な仕組み上、表示領域を書き換える大きな権限を持つものだ。
だから本当に信用できるところを選ばなきゃいけない。
過去には有名だった広告ブロッカーが買収され、マルウェア企業に乗っ取られたこともある(Nano Adblockerなど)。それくらい、その類のツールが持つ権限は悪意あるものにとって魅力的だ。
だから広告ブロッカーを使う人は、知らないうちに自分の使ってる拡張機能やアプリケーションの中身や母体が変化していないか、絶えずアンテナを張って情報収集をしている程度の情報リテラシーがないといけない。
営利企業によって開発・リリースされているブロッカーはそういうリスクが高いと言える。
そういう商業の香りがする母体は、ブロッカーでありながら、控えめな広告ならブロックしない方針を徐々に拡大していき、より経済力の強い広告事業者陣営に手籠めにされていくことが考えられる(Adblock Plusなど。)
だが熱心なボランティアによってフィルタ更新が行われていて、利益よりも思想を重視して運営されている、広告ブロックコミュニティにおいて信頼のおける母体もいくつかある。
個人的に2つ挙げるなら、uBlock OriginとAdguardだ。人によってはそこにBraveを加えるかもしれないが、Braveは広告モデルから脱却しているわけではなく、他社が出す広告は徹底的に消すが、Braveが出す広告を代わりに見ると仮想通貨を還元するよというビジネスで、自社で控えめな広告を出していくという点ではAdblock Plusに近い。
もちろんその仮想通貨がらみの機能を無効にして純粋な高性能ブロッカー内蔵Chromium系ブラウザとして使うこともできるが、所々信用ならんムーブをしている節があるので個人的にはおすすめしない。この分野は信用が最重要なので。
ただ、FirefoxのようなWebの理想を重視する陣営も広告に代わる有効な未来を描けているわけではなく、結局Googleにコバンザメしてその収益に依存しているので、現実的な落としどころとしてBraveのやり方を支持するという考えもあり得るだろう。
見据える未来が違うものの、結果的なブロック精度という面では、ブラウザ拡張のuBlock Origin、スマホ用単体アプリのAdguard、それからuBlock Originフィルタを使っているブロッカー内蔵ブラウザのBraveが三強であり、広告ブロックを期待する人がこの3つ以外を選ぶメリットはあまりないだろう。
OriginがつかないuBlockという拡張もあるが、運営母体が違い袂を分かったものでいわば偽物なので使ってはいけない。
また、Chromeは巨大デジタル広告企業Googleの息がかかっており、ブロッカーのような権限の大きな拡張機能を弱体化させる変更(Google主導のManifestV3有効化)が入ったので、高精度のブロックを望むのならChromeやEdge上でブロック拡張を使うのはいい判断ではない。uBlock OriginなどもLite版が提供されているが、どうしてもChromeを離れられない人向けの選択肢にとどまるだろう。
結論としては、
PCであればFirefox + uBlock OriginもしくはBrave、スマホのWeb閲覧であればFirefox + uBlock OriginかBrave、スマホのアプリ内広告であればAdguard for iOSやAdGuard for Android(Playストアではなく公式から落とす)でAdguard DNSを有効にすることでブロックできる。
より詳しい実用的な指南情報は、臭いサイト名だがここが一番網羅されている。なんJ AdGuard部 Wiki*
ブロックに関する是非や経緯、選び方を含む概念的・思想的な情報は、ここが参考になる。よくある質問 · Yuki2718/adblock2 Wiki · GitHub
