一つの組織が登録できるドメイン名の数を、一つに制限する原則のことです。
日本でインターネットが普及し始めた当初、ドメイン名は有限なものであるという考えから、1組織1ドメイン名の原則が作られました。1組織1ドメイン名によって組織あたりの登録可能ドメイン名数を制限することは、将来の登録者に対するドメイン名空間の確保、及びドメイン名と知的財産権にかかわる問題の発生の軽減につながりました。属性型・地域型JPドメイン名では、現在でも1組織1ドメイン名の原則が適用されています。
一方、後に導入された。汎用JPドメイン名や都道府県型JPドメイン名では、1組織1ドメイン名の原則を適用していません。汎用JPドメイン名は、インターネットが社会に浸透するに従って生まれた、複数のドメイン名を使いたい、登録手続きの簡略化や費用の低減を図ってほしいといった要求を踏まえて導入されました。

* 属性型（組織種別型）・地域型JPドメイン名登録等に関する規則（JPRS）
* 政府機関が登録可能なGO.JPドメイン名の数について（JPRS）
* JPドメイン名の種類（JPRS）

ドメイン名に対するIPv6アドレスを指定するリソースレコードです。同じドメイン名に対して複数記述することができます。

例）
ns1.example.jp. IN AAAA 2001:db8::1
ns2.example.jp. IN AAAA 2001:db8::2
server.example.jp. IN AAAA 2001:db8::a1
server.example.jp. IN AAAA 2001:db8::a2
server.example.jp. IN AAAA 2001:db8::a3

* IPv6（JPRS）
* ドメイン名（Domain Name）（JPRS）
* Aリソースレコード（Aレコード）（JPRS）
* NSリソースレコード（JPRS）
* MXリソースレコード（MXレコード）（JPRS）

Authoritative Answerを表します。DNSメッセージのHeaderセクション内に存在する、応答の際に意味を持つビットであり、値が“1”であった場合、応答したネームサーバーが問い合わされたドメイン名に対する管理権限を持っていることを示します。

digコマンドでは以下のように出力されます。


* DNS Tips：DNSパケットフォーマットと、DNSパケットの作り方
* 権威サーバー（権威DNSサーバー）（JPRS）
* 権威（オーソリティ）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* DNS Tips：digコマンドやdrillコマンドの使い方を教えてください

ASCII Compatible Encodingの略称。
国際化ドメイン名を既存のインターネットの仕組みの中で扱えるようにするための互換形式で、ASCII文字以外の文字（非ASCII文字）をASCII文字のみを用いて表現します。
インターネット利用者の慣れ親しんだ言語のURLによるインターネットアクセスを実現しつつ、ネットワーク上ではACEにより変換されたASCII文字のみのドメイン名となるため、既存のネットワークインフラやアプリケーションプログラムで扱うことが可能です。

Alternative Dispute Resolutionの略称。
裁判によらず、公正中立な第三者が当事者間に入り、話し合いを通じて解決を図る手続きのことです。裁判よりも利用しやすく、柔軟に紛争解決を図ることを目的としています。
ADRにはさまざまな種類があり、運営主体や手続き方法も多種多様です。日本では、裁判外紛争解決手続についての基本理念、国や地方公共団体の負う責務、民間事業者の行う仲介や仲裁などについて定めた法律として「裁判外紛争解決手続の利用の促進に関する法律」、いわゆる「ADR法」が制定されています。
JPドメイン名紛争処理方針（JP-DRP）は、ADRを用いたドメイン名の紛争解決方法です。「JPドメイン名紛争処理方針のための手続規則」によりJPNICが認定した紛争処理機関である「日本知的財産仲裁センター」は、法務大臣の認証を受けた民間ADR事業者です。

* 政府広報オンライン：法的トラブル解決には、「ADR（裁判外紛争解決手続）」
* 独立行政法人国民生活センター：ADR（裁判外紛争解決手続）の紹介
* 裁判外紛争解決手続の利用の促進に関する法律

Asian Institute of Technology（アジア工科大学院）の略称。
タイにある国際的な大学院大学で、アジア地域を中心に約50カ国から学生が集まり、英語での教育が行われています。タイで最初にインターネット接続をするなど、タイのインタ─ネットコミュニティを牽引しています。

At-Large Advisory Committee（At-Large諮問委員会）の略称。
ICANNの諮問委員会の一つで、ICANNの活動の中で個人インターネットユーザー（At-Largeコミュニティ）の利益にかかわる事項についての検討及び理事会への助言を行います。
世界5地域それぞれに設置されている地域別At-Large組織（RALO：Regional At-Large Organization）から2名ずつ選出される10名と、指名委員会によって選出される5名の計15名で構成されます。

* ALAC
* ICANN関連 | 関連組織リンク集（JPRS）

The Community of Asia Pacific Internet Organizationsの略称。
「AP」で始まるアジア太平洋地域のインターネット関連組織の連合体です。「AP*Retreat」「AP Joint Secretariat Meeting」を開催し、各組織間の連携を図っています。

* AP*、APstar
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

Asia-Pacific Advanced Network （アジア太平洋高度研究情報ネットワーク）の略称。
1997年に発足したアジア太平洋地域を結ぶ学術ネットです。日本、米国、韓国、タイ、香港、シンガポール、インドネシア、フィリピン、オーストラリアなどの間でネットワークを相互接続しています。

* APAN
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

The Asia Pacific Coalition Against Unsolicited Commercial Emailの略称。
いわゆる「スパムメール」などの問題への対策を、アジア太平洋地域において連携して行っていくことを目指し、2002年の夏から活動を行い、半年に一度のAP Net Abuse Workshopの開催などを通じて解決策を検討していました。

Asia Pacific Computer Emergency Response Teamの略称。
各国・地域におけるCSIRT（Computer Security Incident Response Team）の活動と連携し、アジア太平洋地域におけるコンピューターセキュリティインシデント情報のコーディネーション実施を目指して2003年2月に発足しました。APCERTはAPSIRC（Asia Pacific Security Incident Response Coordination Conference）を主催しています。

Asia & Pacific Internet Association（アジア太平洋インターネット協会）の略称。
アジア太平洋地域におけるインターネット関連サービス業界の共通利益を推進するため1997年に設立された業界団体です。同地域のインターネットの利便性や安定性を向上させ、持続可能な開発を行っていくための人的資源の基盤構築をミッションとしています。

* APIA
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

Asia Pacific Next Generation Campの略称。
アジア太平洋地域におけるインターネットの次世代を担う若者たちが国境を越えて集い、さまざまな問題について語り合うとともに将来に向けての協力関係を築く目的で、2002年から年2回程度開催されています。

* APNG Camp
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

Asia Pacific Networking Groupの略称。
APCCIRN（Asia Pacific Coordination Committee for Inter-Continental Research Networking）が発展する形で、1994年に組織化されました。多くのAP関連団体・組織の母体と位置付けることができます。

* APNG
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

Asia Pacific Network Information Centreの略称。
IPアドレス・AS番号の割り振り・管理業務を行う、世界に五つあるRIR（Regional Internet Registry：地域インターネットレジストリ）の一つです。オーストラリアのサウスブリスベン（South Brisbane）に事務所を持つNPO（Not-for-Profit Organization）で、アジア太平洋地域を管轄し、自らが管理するIPアドレスの逆引きDNSの登録・公開なども行っています。
APNICは、JPNICからの提案により、パイロットプロジェクトとして1993年9月1日に業務を開始しました。こうした活動を通じて、現在のようなRIR－NIR（National Internet Registry：国別インターネットレジストリ）－LIR（Local Internet Registry：ローカルインターネットレジストリ）という階層構造で IPアドレス管理を担うという体制が整備されました。

* APNIC（Asia Pacific Network Information Centre）
* 日本におけるインターネット資源管理の歴史～ドメイン名とIPアドレスを中心とした日本のインターネットの歩み～ 第6章　グローバルなIPアドレス管理体制の確立へ

The Asia Pacific OperatorS Forumの略称。
アジア太平洋地域におけるネットワークオペレーターが集まるフォーラムで、1996年にメーリングリストとしてスタートし、2000年から半年に一度メンバー会合が行われています。北米のNANOG、欧州のEOF、アフリカにおけるAfNOGに相当するオープンフォーラムです。

* APOPS
* オペレーターコミュニティ | 関連組織リンク集（JPRS）

Asia Pacific Regional Internet Conference on Operational Technologiesの略称。
第1回は1996年にシンガポールで開催されました。アジア太平洋地域において、強固なインターネットインフラを構築するために必要なスキルを身に付けたネットワーク技術者を育て、同地域のインターネットを発展させていくことを目的としています。

* APRICOT
* インターネット・ドメイン名に関係するアジア・太平洋地域の団体 | 関連組織リンク集（JPRS）

Asia Pacific Top Level Domain Associationの略称。
アジア太平洋地域のccTLDレジストリの連合組織であり、1998年の発足以来、ドメイン名やレジストリ運用に関する議論や情報交換、ICANNを始めとするインターネットガバナンス組織への提言などを通じて、アジア太平洋地域のccTLD発展を導く重要な役割を担っています。
なお、JPRSもメンバーとして参加しています。

* APTLD
* 地域のccTLD,TLD連合組織 | 関連組織リンク集（JPRS）

Advanced Research Projects Agency Networkの略称。
1969年に米国国防総省の高等研究計画局（ARPA）がスタートさせたネットワークです。当初は、UCLA（カリフォルニア大学ロサンゼルス校）、UCSB（カリフォルニア大学サンタバーバラ校）、ユタ大学、SRI（スタンフォード研究所）の4カ所を相互接続したものでした。
TCP/IPを用いてUNIXコンピューターを相互接続したARPANETは、現在のインターネットの原型とされています。

American Standard Code for Information Interchangeの略称。
コンピューターや通信において広く用いられている文字コード体系で、1963年に米国規格協会（ANSI）によって定められました。7ビットで表現され、128種類のローマ字、数字、記号、制御コードから構成されています。

Address Supporting Organizationの略称。
ICANNの支持組織の一つで、「Address Council」と呼ばれる評議会と、「ASO General Assembly」と呼ばれる総会、及び事務局で構成されています。IPアドレスに関してICANN理事会に勧告する役割を持っています。ASO Address Council委員は、各地域インターネットレジストリ（RIR：AfriNIC、APNIC、ARIN、LACNIC、RIPE NCC）から3名ずつ選出されます。

* ASO
* ICANN関連 | 関連組織リンク集（JPRS）

個人インターネットユーザーで構成されたICANNのコミュニティです。

* What is the At-Large Community?

ドメイン名に対するIPv4アドレスを指定するリソースレコードです。同じドメイン名に対して複数記述することができます。

例）
ns1.example.jp. IN A 192.0.2.1
ns2.example.jp. IN A 192.0.2.2
server.example.jp. IN A 192.0.2.11
server.example.jp. IN A 192.0.2.12
server.example.jp. IN A 192.0.2.13

* IPv4（JPRS）
* ドメイン名（Domain Name）（JPRS）
* AAAAリソースレコード（AAAAレコード）（JPRS）
* NSリソースレコード（JPRS）
* MXリソースレコード（MXレコード）（JPRS）

1980年代にカリフォルニア大学バークレー校が作成したDNSソフトウェアで、「Berkeley Internet Name Domain」の略称です。1995年に米国の非営利法人Internet Software Consortium（現Internet Systems Consortium, Inc.：ISC）が開発を引き継ぎ、オープンソースのDNSソフトウェアとして提供しています。
BINDは主要なDNSソフトウェアの一つで、以下に示す三つの機能を提供します。

CA（Certification Authority：認証局）は、証明書の発行・更新・失効、CA秘密鍵の生成・保護及び証明書利用者の登録などを行う主体のことです。
IA（Issuing Authority：発行局）及びRA（Registration Authority：登録局）によって構成されます。

※ CA（Certification Authority：認証局）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

2005年に設立された、電子証明書を使った通信の安全性を向上させるためのガイドラインを策定している会員制の組織です。一定の条件を満たした認証局・Webブラウザーベンダーなどが会員になることができます。

CA/Browser Forumにより策定されるガイドラインは、事実上の標準となっています。ガイドラインの策定はメーリングリストをはじめとする公開の場で進められ、会員の提案と投票で決定されます。

CA/Browser Forumにおける投票は、証明書を発行する立場の認証局と、証明書を認証に利用する立場のWebブラウザーベンダーなどの二つのカテゴリーに分けて集計され、以下の条件をすべて満たした場合に可決されます（CA/Browser Forum Bylaws Version 2.3による）。

・認証局の投票の2/3以上が賛成であること
・Webブラウザーベンダーなどの投票の半数プラス1票以上が賛成であること
・それぞれのカテゴリーについて、1会員以上が賛成であること
・アクティブな会員数（過去3回の会議・電話会議に参加した会員数の平均値）の半数以上が、投票に参加していること

* CA/Browser Forum - CAB Forum（公式Webページ）
* ２．電子証明書ガイドライン策定のためのCA/Browser Forum
  （一般財団法人日本情報経済社会推進協会（JIPDEC）による解説）
* インターネット用語1分解説～CA/Browser Forumとは～ - JPNIC
* サーバー証明書発行サービス（JPRS）

ドメイン名の登録者が、登録されたドメイン名に対応する証明書の発行を許可する認証局（Certification Authority：CA）を指定するリソースレコードです。CAAは、Certification Authority Authorizationを意味します。
ドメイン名登録者は、CAAリソースレコードを設定することで

• flag
  クリティカルフラグのみが定義されています。クリティカルフラグは、認証局が対応するCAAリソースレコードのtagの種類を理解できない場合、証明書を発行してはならないことを示します。クリティカルフラグを設定する場合は値に128を指定します。それ以外の場合は値に0(ゼロ)を指定します。


• tag
  値には、現状で以下の3種類があります。
  - issue： 証明書を発行できる認証局のドメイン名をvalueで指定します。
  - issuewild： ワイルドカード証明書を発行できる認証局のドメイン名をvalueで指定します。
  - iodef： 発行を許可しないCAに証明書発行要求があった場合の連絡手段をIODEF（RFC 5070）の形式でvalueに指定します。
  なお、issueおよびissuewildのvalueに";"を指定した場合は、そのドメイン名に対する証明書はいかなるCAからも発行されないことを示します。

Country Code Names Supporting Organisationの略称。
ICANNの活動を支える支持組織の一つです。ccTLDの連合体としてICANNの他の支持組織や委員会などと協調しながら、ccTLD全体にまたがるグローバルな課題についてポリシー案を策定し、ICANN理事会に勧告を行う役割を担います。
JPRSは、「.jp」のレジストリとしてccNSOに参加しています。

* ICANN（アイキャン）（JPRS）
* ccTLD（国別トップレベルドメイン）（JPRS）
* ICANN関連 | 関連組織リンク集（JPRS）
* ccNSO

Country Code Top Level Domainの略称。
国や地域に割り当てられたトップレベルドメイン（TLD）です。その文字列には、原則としてISO（国際標準化機構）のISO 3166-1において規定されている2文字の国コード（*1）が使用されています。ルートゾーンの管理とTLDの委任はICANN（Internet Corporation for Assigned Names and Numbers）が行っており、日本には「.jp」が割り当てられ、JPRSが委任を受けています。

ICANN（Internet Corporation for Assigned Names and Numbers）と各ccTLDを管理するスポンサ組織（委任された組織）が公式に締結する契約です。ccTLDの登録管理における責任関係を文書によって明確化し、グローバルなインターネットコミュニティの利益のために、DNSとインターネットの技術的な安定と運用を維持することを目的としています。
ccTLDスポンサ組織とICANN間の関係構築や確認の形は様々であり、ccTLDスポンサ契約の他に、それぞれが果たす役割を記載したレターの交換を行うといった形態もあります。
JPRSは、JPドメイン名についてICANNと「.jp ccTLDスポンサ契約」を締結しています。

* ccTLDスポンサ契約書（.JP）（JPRS）
* .jp ccTLDスポンサ契約締結およびJPドメイン名業務移管について（JPNIC）

Council of European National Top Level Domain Registriesの略称。
欧州地域におけるTLD（トップレベルドメイン）レジストリの連合体です。JPRSはCENTRのAssociate Memberとなっています。

* CENTR
* 地域のccTLD,TLD連合組織 | 関連組織リンク集（JPRS）

Computer Emergency Response Teamの略称。
コンピューターへの不正アクセスや脆弱性などのコンピュータセキュリティインシデントに対応する活動を行う組織です。具体的には、コンピュータセキュリティインシデントについて、情報収集・分析を行い、結果の公表や関係組織との調整により、問題の解決・再発の防止を図っています。

最初のCERTは、当時のインターネット上の10％のシステムを停止させた「モーリス・ワーム事件」をきっかけとして、1988年に米国カーネギーメロン大学内に設立されました（*1）。日本ではJPCERT/CC（*2）がその任務に当たっています。

*1 Welcome to CERT
*2 JPCERT/CC（ジェーピーサート/シーシー）（JPRS）

CTにおいて、認証局が発行した証明書を登録するログサーバー、またはそのサービスをいいます。

現在、複数の組織がCertificate logsを提供するログサーバーを運用・公開しています。


* Certificate Transparencyについて（JPRS）
* サーバー証明書発行サービス（JPRS）

別名に対する正式名を指定するためのリソースレコードです。
ホスト名には、「canonical name（正式名）」以外に、「aliases（別名）」を付けることができます。DNSの名前解決では、CNAMEリソースレコードが見つかった場合、ドメイン名を正式名に置き換えて名前解決を継続します。ある別名に対する正式名は常に一つであるため、一つの別名に対し、正式名を二つ以上指定することはできません。
CNAMEリソースレコードは、以前はホスト名に別名を付ける手段として使われていました。現在では主にCDN （Contents Delivery Network）や、/24未満のIPv4アドレスの逆引きを設定する際に使われています。
別名は、例えば1台のサーバーで複数のサービスを提供している場合に、サービスごとにサーバーの名前を変えるときに使用します。サーバーの正式なドメイン名はservice.example.jpであるが、将来のことを考えて情報提供ではinfo.example.jpを、ショッピングではshop.example.jpというドメイン名で運用したいといったケースが該当します。この例のような場合、DNSではCNAMEリソースレコードを用いて以下のように定義できます。


* リソースレコード（JPRS）
* 名前解決（Name Resolution）（JPRS）

Common Nameは、サーバー証明書のIssuerフィールドにおける証明書を発行した認証局名や、Subjectフィールドにおける証明書を設定・使用するサーバー名を示すFQDNなどに設定される名前（一般名）です。Common Nameは、識別名（Distinguished Name）を構成するエントリの一つ「CN」となります。

図：コモンネームの例

CP（Certificate Policy）は、CA（Certification Authority：認証局）が発行する証明書の種類、用途、申込手続など、証明書に関する事項を規定する文書のことです。

※ CP（Certificate Policy）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy）（JPRSサーバー証明書発行サービス）

CPS（Certification Practices Statement：認証運用規定）は、CA（Certification Authority：認証局）を運用する上での諸手続、セキュリティ基準など、CAの運用を規定する文書のことです。

※ CPS（Certification Practices Statement：認証運用規定）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局運用規程（Certification Practice Statement）（JPRSサーバー証明書発行サービス）

CRL（Certificate Revocation List：証明書失効リスト）は、証明書の有効期間中に、証明書記載内容の変更、秘密鍵の紛失等の事由により失効された証明書情報が記載されたリストのことです。


※ CRL（Certificate Revocation List：証明書失効リスト）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

認証局によるサーバー証明書の発行状況を、外部から確認できるようにするための仕組みです。
CT （Certificate Transparency）はGoogleにより提案され、2013年に実験（Experimental）仕様としてRFC 6962が公開されました。現在、新仕様となるバージョン2.0を策定する作業が、IETFで進められています。バージョン2.0ではこれまでの運用で得られた知見とフィードバックを反映する形で、プレ証明書[*1]の形式の変更・Certificate logのデータ構造の変更・検証アルゴリズムの変更などが行われています。

[*1]プレ証明書: Certificate logsへの登録時に、認証局が事前作成する証明書。

CTに対応したサーバー証明書発行の流れを、図1に示します。Certificate logsに登録されたログはインターネットに公開され、誰でも確認できる状態になります。



① 申請者が認証局に証明書発行を申請
② 証明書発行の際、認証局がCertificate logsにプレ証明書を送信
③ Certificate logsがSCT[*2]を認証局に返信し、ログに記録
[*2]SCT: SCT: Signed Certificate Timestamp
④ 認証局がSCT付きの証明書を申請者に発行
⑤ 申請者がSCT付きの証明書をWebサーバーに設定（利用）

CTが提案・推進されることになった背景として、サーバー証明書の不正発行・誤発行によるトラブル事例が相次いだことが挙げられます。CTによってサーバー証明書の発行状況を利用者が確認できると、サーバー証明書の不正発行・誤発行を発見するのに役立ちます。
ChromeとSafariでは2018年からサーバー証明書のCT対応が必須となっており、対応していないサーバー証明書は信頼されず、無効扱いになります。2020年に公開された新しいEdgeにおいても、CT対応が必須となっています。
JPRSサーバー証明書発行サービスはCTに対応しており、2018年4月5日以降に発行するサーバー証明書について、所定のCertificate logsへの登録とSCTの付加を実施しています。

* Certificate Transparencyについて（JPRS）
* サーバー証明書発行サービス（JPRS）

CNAMEリソースレコードの指定先にWebサーバーが存在しない、親ゾーンの委任情報（NSリソースレコード）の指定先の権威サーバーにゾーンが存在せずlame delegationになっているなど、指定された名前の実体が無効になっているリソースレコードを示す用語として使われることがあります（図1）。danglingは「宙ぶらりんの」を意味しています。

図1：dangling recordsの例

Domain Name Systemの略称。
インターネットに接続されたコンピューターの情報（ドメイン名とIPアドレスの対応など）を得るための仕組みです。
例えば、「example.jp」にアクセスするためには、「example.jp」に対応するIPアドレスが「192.0.2.1」であるという情報が必要ですが、その対応を調べる際にDNSが利用されます。

あるIPアドレスやドメイン名に対する評価（reputation）情報を提供する、DNSをベースとした仕組みです（RFC 6471）。
DNSBLのリストは、何らかのポリシーに基づき評価情報を収集・管理している組織が提供します。代表例は、迷惑メール対策のためのリストで、あるIPアドレスについて、電子メールの受け取りを推奨しないリストに存在するか否かの情報を提供します。

* RFC5782「DNS Blacklists and Whitelists」
* RFC6471「Overview of Best Email DNS-Based List (DNSBL) Operational Practices」
* DNSブロッキング（JPRS）
* 名前解決（Name Resolution）（JPRS）

DNSSEC検証に用いる公開鍵を格納するためのリソースレコードです。
一つの鍵ペアに必ず一つのDNSKEYリソースレコードがあり、DNSSEC署名しているゾーンは通常二つ以上のDNSKEYリソースレコードを持ちます。

DNSKEYリソースレコードのゾーンファイルにおける表現は以下のとおりです。

• ・flag： ZSKであれば256を、KSKであれば257を指定します。


• ・protocol： DNSSECを示すプロトコル番号である3を指定します。


• ・algorithm： DNSSECのアルゴリズム番号（※）を定義し、RSASHA256の場合は8を指定します。


• ・public key： Base64という方式で符号化した公開鍵の内容を記述します。

Domain Name Supporting Organizationの略称。
1998年に設立されたICANNの三つのSupporting Organizationの一つでドメイン名に関する支持組織です。2002年のICANN改革を受け、ccTLDを除いたグループの機能は新たに組織化されたGNSOに引き継がれています。

Domain Name System Operations Analysis and Research Centerの略称で、インターネットのDNSインフラのセキュリティ、安定性、及び理解を向上させるために組織された、米国の会員制非営利団体です。2004年に設立され、2008年に法人化されました。
DNS-OARCは、以下の活動を行っています。

• ・DNSサーバーの運用状況など、秘匿情報を含む会員間の各種情報やデータの共有
• ・インターネットにおいて重要なDNSサーバーのトラフィック解析や、負荷の解析
• ・DNSに関するワークショップの開催
• ・DNSに関するパフォーマンスと攻撃発生後の分析
• ・DNSに関する調査や問題解決に利用できるツールやサービスの提供

2021年1月にイスラエルのサイバーセキュリティ専門家チームJSOFが公開した、DNSフォワーダーdnsmasqの脆弱性です。DNSpooqには、以下の脆弱性が含まれています。

1. 内部処理の不具合により、DNSキャッシュポイズニングの成功確率が上昇する（CVE-2020-25684、CVE-2020-25685、CVE-2020-25686）
2. DNSSEC検証の不具合によりバッファオーバーフローが発生し、最悪の場合、リモートコード実行（RCE）が可能になる（CVE-2020-25681、CVE-2020-25682、CVE-2020-25683、CVE-2020-25687）

dnsmasqはホームルーターなど、ネットワーク機器で動作している場合があります。該当するネットワーク機器を利用している場合、本脆弱性の影響を受ける可能性があります。

* DNSPOOQ - JSOF（DNSpooq公式サイト）
* DNSpooq - Cache Poisoning and RCE in Popular DNS Forwarder dnsmasq（JSOFのテクニカルホワイトペーパー）
* Dnsmasq - network services for small networks.（dnsmasq公式サイト）
* dnsmasqにおける「DNSpooq」脆弱性の公開について（JPRSの注意喚起）

DNS Security Extensionsの略称。
DNS応答に電子署名を追加し、問い合わせ側で検証することでDNSの攻撃耐性を向上させる、セキュリティ拡張機能です。DNSSECは、受け取ったDNSレコードの出自（送信元で登録したデータであること）・完全性（データの欠落や改ざんのないこと）を問い合わせ側で検証できるようにするための機能をDNSに追加します。

* JPRSトピックス＆コラム（No.013）：DNSSECの概要と今後の展開～「本当に正しい」を証明するために～（JPRS）
* JPRSトピックス＆コラム（No.014）：DNSSECに関するよくある質問と回答（基礎技術編―2011年2月版）（JPRS）

偽のDNS応答をフルサービスリゾルバー（キャッシュDNSサーバー）にキャッシュさせることで、利用者のアクセスを攻撃者が用意したサーバーに誘導し、フィッシングや送信された電子メールの窃盗などを図る攻撃手法です。
DNSキャッシュポイズニングの例を、通常の名前解決の動作と比較する形で以下に示します。


攻撃者は、権威サーバーからの応答がフルサービスリゾルバーに届く前に発信元などを偽装した応答を送り込みます。送り込みに成功した場合（３’）、フルサービスリゾルバーに偽の応答内容がキャッシュされます（４’）。キャッシュされた偽の応答内容はスタブリゾルバー（DNSクライアント）への応答に使われ（５’）、以降、ユーザーのアクセスはキャッシュされた内容が無効になるまで攻撃者が用意したサーバーに誘導される（６’）ことになります。

* JPRSトピックス＆コラム（No.9）：新たなるDNSキャッシュポイズニングの脅威～カミンスキー・アタックの出現～（JPRS）
* キャッシュポイズニング攻撃対策：キャッシュDNSサーバー運用者向け―基本対策編（JPRS）
* 名前解決（Name Resolution）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）

自身ではDNSの非再帰的問い合わせを行わず、別のフルサービスリゾルバー（キャッシュDNSサーバー）に名前解決要求を転送するDNSサーバーです。

多くのホームルーターは、DNSフォワーダーの機能を備えています。DNSフォワーダーの使用には、以下のメリットがあります。

• ・フルサービスリゾルバー相当の機能を、簡易に実装できる
• ・あるネットワーク内の利用者が使うフルサービスリゾルバーが変更になった（例：接続先ISPを変更した）際も、DNSフォワーダーの設定のみを変更すればよい

Webブラウザーやアプリケーションにおいて、リンクで指定されたドメイン名を事前に名前解決することです。一部のWebブラウザーでは、DNSプリフェッチにより今後アクセスされる可能性の高いドメイン名を事前に名前解決しておくことで、実際にアクセスされた際のコンテンツ読み込みにかかわる時間の短縮を図ります。
また、一部のWebブラウザーにおいて、利用者がWebブラウザーのアドレスバーにURLを入力している途中で事前の名前解決を図ることがあります。この機能も、DNSプリフェッチと呼ばれます。
なお、一部のリゾルバーにおいて、フルサービスリゾルバーのキャッシュが期限切れになることを防ぐため、キャッシュが満了する直前に名前解決を行ってキャッシュデータを更新する仕組みが実装されています。この機能も、DNSプリフェッチと呼ぶことがあります。

* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 名前解決（Name Resolution）（JPRS）
* キャッシュ（cache）（JPRS）
* FROM JPRS 増刊号 vol.135 「第87回IETF Meeting報告（前編） ～DNS関連WGにおける話題～（▼キャッシュDNSサーバーの実装方式の工夫～HAMMER）（JPRS）
* DNS Prefetching - The Chromium Projects
* DNS プリフェッチの制御 | MDN
* プリレンダリングとプリフェッチのサポート

DNSの問い合わせ内容をチェックし、特定のドメイン名に対する利用者のアクセスをブロックする技術です。
ブロッキングの対象となるドメイン名の名前解決を要求された場合、フルサービスリゾルバー （キャッシュDNSサーバー）、もしくはその手前のネットワークは、そのドメイン名のIPアドレスに替えて不在応答や警告を表示するサイトのIPアドレスを応答します。
また、DNSブロッキングは、DNSにアクセス制御の情報を乗せ、アプリケーションでのアクセス制御に用いる手法を指すこともあります。その際に使われるアクセス制御の一覧表の一つに、「DNS-Based List（DNSBL）」があります。

* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 名前解決（Name Resolution）（JPRS）
* 不在応答（JPRS）

DNSを利用したDoS攻撃の一つです。送信元IPアドレスを偽った通常のDNS問い合わせをDNSサーバーに送ることでDNSサーバーが応答パケットを攻撃対象に送り、サービス不能の状態に陥らせます。

この攻撃手法では、攻撃者が送信元IPアドレスを攻撃対象のIPアドレスに偽装した問い合わせを通常のDNSサーバーに送ります。DNSサーバーは、攻撃対象に通常のDNS応答を返すため、攻撃者からみるとDNSサーバーが攻撃を反射（リフレクター（reflector）/ リフレクション（reflection））しているように見えます。DNSでは、問い合わせよりも応答の方が大きいため、小さなクエリパケットで大きな攻撃パケットを生成（攻撃を増幅）できることから「DNSアンプ攻撃（DNS Amplification Attacks）」とも呼ばれます。

* DoS攻撃（DDoS攻撃）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* JPRSトピックス＆コラム（No.3）：DDoSにあなたのDNSサーバーが使われる～DNSリフレクター攻撃の脅威と対策～（JPRS）
* 技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について（JPRS）

特定のネットワークやコンピューターに対して処理能力を上回る負荷を掛けたり、システムの脆弱性を突いたりする手法により、サービスの運用・提供を妨害する攻撃のことです。
DoS攻撃の一種にDDoS攻撃（Distributed Denial of Service attack）があり、攻撃元を分散させ複数の箇所から特定のネットワークやコンピューターを一斉に攻撃する手法です。
DoS攻撃は、常に新しい手法が編み出されており、攻撃規模や発生頻度が増大傾向にあります。

* オープンリゾルバー（JPRS）
* JPRSトピックス＆コラム（No.3）：DDoSにあなたのDNSサーバーが使われる～DNSリフレクター攻撃の脅威と対策～（JPRS）
* JPRSトピックス＆コラム（No.21）：Bot経由でDNSサーバーを広く薄く攻撃～DNS水責め攻撃の概要と対策～（JPRS）
* 技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について（JPRS）

Domain Name Dispute Resolution Policyの略称。
ドメイン名の登録・使用に関して生じた紛争を処理するための規則（基準）です。ドメイン名を先取りし商標権を持つ人に対して高額で売りつけようとする「サイバースクワッティング」をはじめ、不正の目的によるドメイン名の登録・使用に起因する紛争を解決するために、権利者の申立てに基づいて速やかに当該ドメイン名の取り消しまたは移転することを目的としています。
DRPは一般的に、ドメイン名紛争処理方針について記述した文書と、ドメイン名紛争処理方針のための手続規則の二つの文書から成ります。扱う範囲はドメイン名の不正の目的による登録・使用に限定されており、裁定結果は裁判の判決とは異なり拘束力を持つものではありません。これを、ミニマル・アプローチと呼び、正当な権利者間の紛争は、従来の裁判や仲裁等で扱うことになります。
DRPには、「.com」や「.net」、「.org」などのgTLDに適用されるUDRP（Uniform Domain Name Dispute Resolution Policy：統一ドメイン名紛争処理方針）、JPドメイン名に適用されるJP-DRP（JPドメイン名紛争処理方針）の他、ドメイン名の登録者がそのドメイン名を別のレジストラに移転した際や移転しようとした際に適用されるTDRP（Transfer Dispute Resolution Policy）や、さまざまなドメイン名における登録の適格性に関するものなどがあります。
DRPは、gTLDの増加に伴い、その種類を増やしています。

* JP-DRP（JPドメイン名紛争処理方針）（JPRS）
* UDRP（ユーディーアールピー）（JPRS）
* gTLD（分野別トップレベルドメイン）（JPRS）
* ドメイン名紛争処理方針（DRP）（JPNIC）
* Domain Name Dispute Resolution Policies

親ゾーンに設定される、子ゾーンのDNSKEYリソースレコードを参照するリソースレコードです。親ゾーンのDSリソースレコードの内容と子ゾーンのDNSKEYリソースレコード（KSK公開鍵）の情報が一致することで、DNSSECの信頼の連鎖が構築されます。
DSリソースレコードのゾーンファイルにおける表現は以下の通りです。

• 
  ・key tag ： 鍵のIDで、子ゾーンのDNSKEYリソースレコードに対応します。


• ・algorithm ： DNSSECアルゴリズム番号（※1）を示し、RSASHA256であれば8を指定します。


• ・digest type ： 続くテキスト部分で使われているダイジェスト（※2）のアルゴリズムを示し、SHA-256であれば2を指定します。


• ・digest ： 子ゾーンのドメイン名と参照先のDNSKEYリソースレコードから生成されたダイジェストを指定します。

EDNSは、RFC 6891で定義されたDNSの拡張方式で、バージョン番号を示すためにEDNS0またはEDNS(0)と呼ばれます。EDNSは、512バイトよりも大きなメッセージサイズを通信コストの低い（通信にかかる負荷が小さい）UDPで扱えるように拡張し、フラグや応答コードも拡張します。また、DNS問い合わせに機能を追加できるようにします。
DNSをDNSSECやIPv6に対応させる場合、EDNS0への対応が必須とされています。詳しくは、「JPRSトピックス＆コラム（No.8）：『512の壁』を越える～EDNS0の概要と運用上の注意～」を参照してください。

* UDP（ユーディーピー）（JPRS）
* JPRSトピックス＆コラム（No.8）：「512の壁」を越える～EDNS0の概要と運用上の注意～（JPRS）
* DNS Tips：「EDNS0」とは何ですか？

Telephone Number Mappingを表す用語。
国際的な電話番号規格のE.164番号を、DNSを利用してインターネット上の資源を現す識別子（URI）に対応付ける、IETFで標準化されたプロトコルです。

Extensible Provisioning Protocolの略。ドメイン名やIPアドレスなど、レジストリが取り扱う多種多様なデータ（レジストリデータ）をレジストリ・レジストラ間で交換するためのプロトコルです。
レジストリ・レジストラモデルでは、レジストリは複数のレジストラに対し自組織で管理するデータベースへのアクセスを提供します。EPPは、レジストリデータのやりとりを円滑に行うためのプロトコルとして開発され、拡張性の高さを特徴としています。

* レジストリ（JPRS）
* レジストラ（JPRS）
* プロトコル（JPRS）
* インターネット10分講座：CRISP & EPP（JPNIC）

Fully Qualified Domain Name（完全修飾ドメイン名）の略称。
トップレベルドメイン（TLD）までのすべてのラベルを含むドメイン名のことをいいます。

* 「www.jprs.jp.」のように一番右の「.」までを記述したドメイン名は、絶対ドメイン名（Absolute Domain Name）と呼ばれます。

Governmental Advisory Committeeの略称。
ICANNの諮問機関の一つで、各国政府などからの代表メンバーによって構成されます。
GACは政府の立場からICANN理事会に対して助言を行っています。

* GAC
* ICANN関連 | 関連組織リンク集（JPRS）

Generic Names Supporting Organizationの略称。
ICANNの活動を支える支持組織の一つです。gTLDに関するポリシー案を策定し、ICANN理事会に勧告を行う役割を担います。
2002年のICANN改革を受け、旧DNSOの中からccTLDを除く六つのグループが旧DNSOを引き継ぐ形で組織化したものです。

* GNSO
* ICANN関連 | 関連組織リンク集（JPRS）

Generic Top Level Domainの略称。
一般的に、国や地域によらないトップレベルドメイン（TLD）で、「.com」や「.net」のように登録に特段の制限がないものと、「.aero」や「.post」のように登録に一定の要件が必要なものがあります。
gTLDは、「.com」「.edu」「.gov」「.mil」「.net」「.org」の六つで始まり、その後「.int」が加わりました。1998年にICANNが設立された後、二度の追加プロセスを経て15のTLDが追加導入されました。2012年1月から始まった新gTLDプログラムではそれまでのgTLDの追加とは異なる方式が採用され、その中で

ホスト名とIPアドレスの対応付けを行単位で記載したテキストファイルです。以下のようなフォーマットを持ちます。

初期のインターネットでは、HOSTS.TXTという名前のテキストファイルでネットワーク全体のホスト名とIPアドレスとの対応を管理していました。現在でも、さまざまな機器やOSはHOSTSファイルでローカルに名前解決する仕組みを持っています。

* 日本におけるインターネット資源管理の歴史：～ドメイン名とIPアドレスを中心とした日本のインターネットの歩み～ 第1章 資源管理とレジストリ（JPNIC）
* 名前解決（Name Resolution）（JPRS）

RFC 6797で定義される、WebサイトがWebブラウザーにHTTPSでのアクセスを指示することで、中間者攻撃を防止するための技術です。

アクセス先のWebサイトにHSTSが設定されていることをWebブラウザーが検知した場合、アクセス先として指定されたURIがhttp://で始まるものであった場合でも、有効期間内であればHTTPSでアクセスされます。

HSTSの有効期間は、Webサイト側からmax-ageディレクティブで指定します。max-ageの指定は秒単位です。また、オプションのincludeSubDomainsディレクティブを追加指定することで、アクセス先のドメイン名のサブドメインを含むWebサイトに対しても、HTTPSでのアクセスを指示できます。

HSTSではWebサーバーへのアクセス時に、以降のアクセスにおけるHTTPSの指示をWebブラウザーに通知します。そのため、指定されたURIがhttp://で始まるものであった場合、初回の接続時やHSTSの有効期間が経過した後は、HTTPでアクセスされることになります。

初回の接続時からHTTPSでのアクセスを指示する方法に「HSTSプリロード」があります。HSTSプリロードはRFC 6797では定義されていませんが、主要なWebブラウザーでサポートされています。

* 常時SSL化について（JPRSサーバー証明書発行サービス）

Internet Architecture Boardの略称。
IABはIETFに設置された委員会であり、ISOCの諮問機関の役割も担っています。IABはIETFの活動方針とインターネット標準化プロセスを監督し、RFC編集者を任命します。また、IETFのプロトコルパラメーターレジストリの管理も担当します。

* IAB
* 技術標準化推進団体およびその関連団体 | 関連組織リンク集（JPRS）

Internet International Ad Hoc Committeeの略称。
1996年にISOCを中心に、当時のｇTLDを巡るさまざまな課題の解決策を検討するために組織されました。1997年に発表された最終報告書の中で七つのgTLDの新たな創設などの提言を行いました。最終報告書を発表した後解散しています。

Internet Assigned Numbers Authorityの略称。
ドメイン名、IPアドレス及びAS番号、各プロトコルで使われるプロトコル名及び番号といったインターネット資源を管理する機能です。
IANAは、南カリフォルニア大学情報科学研究所（ISI）の故ジョン・ポステル（Jonathan Bruce Postel）氏が中心となり、1988年に設立されました。IANAはインターネットに関する最も古い機関の一つであり、その活動は1970年代にまで遡ることができます。
その後、1998年10月にICANNが設立され、IANAが行っていた各種資源のグローバルな管理・調整の役割は ICANNの一部局として引き継がれました。そのような経緯から、歴史的なことも含めインターネット資源を管理する機能を表す意味で使用されています。
ポリシーの策定と運用を分離する観点から、現在、IANA機能はICANNの子会社であるPTI（Public Technical Identifiers）が運用しています。

* About IANA
* Public Technical Identifiers (PTI)

Internet Corporation for Assigned Names and Numbersの略。
1998年10月に米国で設立された非営利法人です。ICANNの主な役割は、

・インターネットの三つの識別子の割り振りや割り当ての管理・調整
  - ドメイン名
  - IPアドレス及びAS番号
  - 各プロトコルで使われる名前及び番号
・DNSルートサーバーシステムの運用や調整
・これらの技術的機能に関連するポリシー策定の合理的かつ適切な調整

であり、組織は、理事会、三つの支持組織（Supporting Organization）、諮問委員会（Advisory Committee）、事務局などから構成されています。
ICANNは、インターネットの商用利用が進む中で浮上したドメイン名に対する競争原理の導入や商標権などの問題を解決し、グローバルなインターネット資源管理全般に責任を持つ団体として、インターネットコミュニティの支持のもと設立されました。

* ICANN
* ICANN情報（JPNIC）

Internationalizing Domain Names in Applicationsの略称。
国際化ドメイン名のアーキテクチャーと処理手順を規定しています。 具体的には、国際化ドメイン名対応のアプリケーションプログラム内部において、文字列の正規化（NAMEPREP）とASCII互換エンコーディング（Punycode）変換の処理を行うとしています。

The Internet Engineering Task Forceの略称。
インターネット技術の標準化を推進する団体で、1986年にIAB（Internet Architecture Board）によって設置されました。IETFにおける技術仕様はRFC（Request for Comments）として文書化され、広く参照されています。

* IETF
* 技術標準化推進団体およびその関連団体 | 関連組織リンク集（JPRS）
* JPRSトピックス＆コラム（No.22）：インターネット標準の作られ方～IETFにおける標準化とRFCの概要～（JPRS）

Internet Network Information Centerの略称。
1993年に全米科学財団（NSF）の資金援助により、ネットワークを円滑に運用・利用するための情報サービスを行う目的で設立された団体です。NSFではInterNICの設立に当たり、それぞれの業務について競争入札を実施し、結果としてドメイン名やIPアドレスなどの登録管理業務は、米国Network Solutions社に委託されました。
その後、IPアドレス関連の登録管理業務はARINに移管され、ドメイン名登録管理業務はICANNを中心とする現在の体制に移行しました。なお、InterNICという名称は、ICANNがドメイン名登録に関する情報を提供するWebサイトとして現在も残っています。

共通のサービス用IPアドレスを、複数のホストで共有する仕組みです。
通常、IPアドレスはホストごとに割り当てられますが、IP Anycastを利用することで一つのIPアドレスを複数のホストに割り当てることができます。共通のサービス用IPアドレス宛の通信は、IPアドレスを共有する複数のホストのうちいずれか一つに到達します。
これにより、利用者は同一のサービスを提供する複数のホストのうちネットワーク的に一番近いホストと通信することになります。IP Anycastの導入により、以下の効果が期待できます。

・負荷分散・冗長化：複数のホストや複数の拠点にリクエストを分散させることにより、負荷分散や冗長化を実現できます。
・応答時間の短縮：ホストを地域ごとに分散配置することで、応答時間を短縮させることができます。
・DoS攻撃の局所化：一カ所からのDoS攻撃はネットワーク的に一番近いホストのみに到達するため、他のホストは被害を受けません。
・DDoS攻撃の効果抑制：DDoS攻撃は複数のホストに分割されるため、その効果を抑制することができます。




インターネットにおけるIP Anycastは、経路制御との組み合わせにより実現されます。経路制御により、インターネット上に同一のIPアドレスを持つ複数のホストが存在しても、利用者から見てネットワーク的に近いいずれか一つのホストが選択されます。

* JPRSトピックス＆コラム（No.5）：DNSのさらなる信頼性向上のために～IP Anycast技術とDNS～（JPRS）
* DNS Tips：「IP Anycast」って何ですか？

Internet Protocolの略称。IPv4とIPv6が存在します。
インターネットは「IPによって相互に接続された巨大なコンピューターネットワークである」ということができます。IPは、OSI階層モデルにおけるネットワーク層のプロトコルです。経路制御とフラグメンテーションを基本機能とし、IPアドレスによって識別されたコンピューターに対して、IPパケットを送ります。上位プロトコルであるTCPと組み合わせ、TCP/IPとして用いられています。

ISPのネットワークにおいて、ユーザーに割り当てたIPアドレス宛のUDP53番ポートへの通信をブロックすることです。IP53Bは、ユーザー側で動作しているオープンリゾルバーを踏み台にした攻撃を防ぐことができます。53番はDNSサービスのためのポート番号であり、このポートへの通信をブロックすることで、それらのオープンリゾルバーへのアクセスをブロックできます。
なお、ユーザーが設置している権威サーバー（権威DNSサーバー）へのアクセスもブロックされます。



* OP53B（JPRS）
* JPRSトピックス＆コラム（No.21）：Bot経由でDNSサーバーを広く薄く攻撃～DNS水責め攻撃の概要と対策～（JPRS）
* ISP（アイエスピー）（JPRS）
* UDP（ユーディーピー）（JPRS）
* オープンリゾルバー（JPRS）
* DNSリフレクター攻撃（DNSアンプ攻撃）（JPRS）
* ランダムサブドメイン攻撃（DNS水責め攻撃）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

Internet Protocol Version 4の略称。
32ビットのアドレス空間を持ち、インターネットで標準的に用いられてきました。アドレスは通常、「202.11.16.167」のように8ビットごとに区切った四つの数字により表記します。
米国時間2011年2月3日、IANAのIPv4アドレス中央在庫の枯渇が発表されており、今後は次世代のプロトコルであるIPv6への移行が進むものと考えられます。

Internet Protocol Version 6の略称。
インターネットで標準的に用いられてきたIPv4のアドレス空間が、将来的に不足することを見据えて作成された通信プロトコルです。2の128乗という膨大なアドレス空間を持ち、アドレスは「2001:df0:8:7::80」のように表記されます。

* プロトコル（JPRS）

IP（インターネットプロトコル）を使用してインターネットに接続するコンピューターを識別するためのアドレスです。IPv4アドレスとIPv6アドレスが存在します。
IPアドレスはコンピューターのネットワークインターフェースごとに割り当てられます。

IPv4ネットワークでは、IPパケットを中継する時、通過するリンクまたはネットワークで扱える最大転送単位（MTU：Maximum Transmission Unit）に従って、大きなIPパケットを分割することです。

IPフラグメンテーションは、サイズの大きなIPパケットを、そのIPパケットのサイズより小さなMTUを持つネットワークを通して中継する際に必要となる仕組みです。MTUを超えるIPパケットは、MTUを超えないサイズに分割されます。分割されたIPパケットは、以降、分割されたまま転送されます。
分割されたIPパケットを再構築し、元の形に戻すのは最終的な受信側の役割です。
IPv6ネットワークでは経路途中におけるIPフラグメンテーションは禁止され、事前に送信元が経路途中のMTUを超えないようにIPパケットを送り出します。

Internet Societyの略称。
1992年に設立された非営利の国際組織で、インターネット技術及びシステムに関する標準化、教育、ポリシーに関する課題や問題を解決あるいは議論することを目的としています。具体的には、イベント「INET」の開催や、IABやIETFの上位団体として、これらの団体の活動に対する支援を行っています。

* ISOC
* 技術標準化推進団体およびその関連団体 | 関連組織リンク集（JPRS）

Internet Service Provider（インターネットサービスプロバイダー）の略称。
インターネットへの接続サービスを提供している事業者のことを指し、「プロバイダー」と呼ばれることもあります。メールアドレスの付与やホームページ、ブログといった付加サービスも提供することが一般的になっています。

International Telecommunication Union（国際電気通信連合）の略称。
世界の電気通信に関する国際標準の策定を目的として設立された各国政府間の国際組織。国際連合の専門機関です。

* ITU
* 国連組織 | 関連組織リンク集（JPRS）

日本語ドメイン名協会の英文名称（Japanese Domain Name Association）の略称。
2001年7月に日本語ドメイン名の普及と関連ビジネスへの拡大を目的として設立された任意団体で、JPRSも会員としてその活動に携わりました。所期の目的を達成したことから、2007年5月をもって活動を休止しています。

* JDNA
* 日本語ドメイン名・国際化ドメイン名の関連組織 | 関連組織リンク集（JPRS）

地方公共団体情報システム機構の英文名称（Japan Agency for Local Authority Information Systems）の略称。地方公共団体が運営する組織として、地方公共団体の情報システムに関する事務を行っており、地方公共団体を対象としたLG.JPドメイン名の登録申請の取次業務も行っています。2014年4月1日に、LASDEC（財団法人地方自治情報センター）からJ-LISに組織が移行されました。

JPトップレベルドメイン名のゾーン（jpゾーン）を管理する権威サーバー（権威DNSサーバー）の呼称です。JP DNSは可用性を高めるため、2017年2月現在、八つのシステムで運用されています。
サーバー名と運用組織は以下の通りです。

JPRSが提供しているドメイン名登録等サービスの名称です。

* ドメイン・SSL取得管理サービス | JPDirect

JP Domain Name Dispute Resolution Policy の略称。
JPNICによって制定された、JPドメイン名に適用される紛争処理方針（ドメイン名の登録・使用に関して生じた紛争を処理するための規則（基準））です。裁判や仲裁とは異なる新たな紛争処理手段として制定され、簡易、迅速、低費用、非拘束（裁定結果は裁判の判決とは異なり拘束力を持たない）という特徴を持ちます。登録されたJPドメイン名について不服が出た場合に限り、事後的に、当該登録者が登録を認められるべきではない濫用的な者か否かの実質審査をするドメイン名登録の補完システムとして制定されました。
また、JP-DRPは、国際的な動きと歩調を合わせた形をとるという考えから、その判断基準や紛争処理手続きの特徴に関してUDRPと同様のミニマル・アプローチ（悪質性が極めて高いドメイン名登録を排除することのみに機能を限定した簡易・迅速な手続き）を採用しています。JP-DRPは、「JPドメイン名紛争処理方針」と「JPドメイン名紛争処理方針のための手続規則」の二つの文書から成り、JPNICが認定した紛争処理機関がJP-DRPの手続規則に基づき紛争処理手続きを行います。

* JPドメイン名紛争処理方針（JPRS）
* 「JP-DRPとは」（JPNIC）

Japan Network Information Centerの略称。
日本のインターネットを安定的に、円滑かつ的確に運用・管理していくための活動をする組織。具体的には、以下のようなことを行っています。

・情報発信を通じた、最新情報や共有すべき情報などの提供（普及啓発）
・NIR（National Internet Registry：国別インターネットレジストリ）としてIPアドレス・AS番号を管理
・インターネットに関する技術やインターネットガバナンスなどの国際調整に参画
・インターネットの基盤にかかわる技術やインターネットを円滑に運用するために必要となる新しい技術の調査、研究
・民間企業だけでは実現の難しい各種調整の場、実験の場の提供

2002年4月1日にJPドメイン名の登録管理業務を株式会社日本レジストリサービス（JPRS）に移管する以前は、JPNICがJPドメイン名の登録管理・運用サービスを行っていました。
JPNICの前身は、1991年に設立された任意団体の「JNIC」です。その後、1993年に任意団体JPNICに改組され、1997年に社団法人化しました。2013年4月1日に「一般社団法人（非営利型）」に移行し、現在に至ります。

* JPNIC（一般社団法人日本ネットワークインフォメーションセンター）

株式会社日本レジストリサービスの英文名称（Japan Registry Services Co., Ltd.）の略称。

* https://日本レジストリサービス.jp/
* https://jprs.co.jp/

「example.jp」や「example.co.jp」、「ドメイン名例.jp」などのように、日本を表すccTLD（シーシーティーエルディー）である「.jp」で終わるドメイン名の総称です。
JPドメイン名には、大きく次の3種類があります。JPドメイン名を登録できるのは日本国内に住所を持つ組織や個人に限られ、JPドメイン名の種類ごとに細かい登録要件が定められています。

JPRSが行うJPドメイン名登録管理業務の公平性及び中立性を実現するために、JPRS内に設置された委員会です。JPドメイン名登録管理業務移管契約に基づいて設置されています。
JPドメイン名諮問委員会は、JPRS取締役会からの諮問に対する答申に加え、取締役会に対する自発的な勧告を行い、説明を求めることができます。委員構成は、JPRSが任期ごとにJPドメイン名諮問委員会に諮問し、その答申を踏まえて任命しており、現在はJPNIC、JPドメイン名指定事業者、インターネットサービスプロバイダー（ISP）、一般企業、学識経験者、インターネットユーザー、日本国政府のそれぞれの分野から選出された委員によって構成されます。

* JPドメイン名諮問委員会（JPRS）
* JPドメイン名登録管理業務移管契約（JPRS）

Japan University Networkの略称。
1984年10月に東京大学、東京工業大学、慶應義塾大学の間を結ぶネットワークとして始動し、最終的には約700の機関を結ぶネットワークにまで成長しました。WIDE Projectの発足などを受け、1994年10月に発展的終了となりました。

2024年2月にドイツ国立応用サイバーセキュリティ研究センターATHENEの研究者チームが発表した、DNSSEC検証を行うリゾルバーをDoS攻撃可能な脆弱性です。本脆弱性にはCVE IDとして、CVE-2023-50387が割り当てられています。

DNSSECでは一つのゾーンに複数の鍵（DNSKEYリソースレコード）を設定でき、かつ一つのリソースレコードセット（RRset）に複数の署名（RRSIGリソースレコード）を追加できるように設計されています。これを利用することで、DNSSECによる保護を維持した鍵の更新（キーロールオーバー）や使用するアルゴリズムの変更（アルゴリズムロールオーバー）などの機能が実現されています。

KeyTrapではこの仕組みを利用し、鍵の識別に使われるKey Tag（鍵タグ：DNSKEYリソースレコードから計算される16ビットの数値）を意図的に衝突させた多数の鍵と、その鍵タグを参照する多数の署名を持つゾーンデータを名前解決させ、DNSSEC検証に多大な作業量を強いるように仕向けることで、リゾルバーのDNSサービスの妨害を図ります。

本脆弱性の緩和策として、DNSSEC検証において実装する作業量の総量制限が、リゾルバーの開発者やパブリックDNSサービスの運用者などにおいて実装・実施されています。

* DNSSEC（JPRS）
* DoS攻撃（DDoS攻撃）（JPRS）
* キーロールオーバー（JPRS）
* RRset（リソースレコードセット）（JPRS）
* DNSKEYリソースレコード（JPRS）
* RRSIGリソースレコード（JPRS）
* Key Tag（鍵タグ）（JPRS）
* KeyTrap – ATHENE（KeyTrap公式サイト）
* CVE Record | CVE（本脆弱性のCVE ID（CVE-2023-50387））
* BIND 9 Security Release and Multi-Vendor Vulnerability Handling, CVE-2023-50387 and CVE-2023-50868 – ISC（ISCによる解説）
* Remediating new DNSSEC resource exhaustion vulnerabilities（Cloudflareによる解説）

DNSSECにおいて、KSKおよびZSKの公開鍵に署名するための鍵です。
DNSSECでは運用上の理由から、KSK（Key Signing Key、鍵署名鍵）とZSK（Zone Signing Key、ゾーン署名鍵）という、2種類の鍵を使用することが一般的です。

KSKは、署名対象となるゾーンのDNSKEYリソースレコード（RRset）のみを署名する鍵で、署名にはKSK秘密鍵を用います。署名により、DNSKEY RRsetに対応するRRSIGリソースレコードが当該ゾーンに付加されます。



DNSSECでは、DNSKEY RRsetを署名する鍵に対応するDS RRsetが親ゾーンに登録されることで、親子間の信頼の連鎖が構築されます。一般に、DS RRsetの登録には親への依頼、つまり申請作業が必要です。申請作業にはコスト（所要時間、手間）がかかるため、その頻度を下げるためにDS RRsetに対応する署名鍵には、十分な強度（ビットサイズ、鍵長）が必要になります。

また、DNSSECでは、署名鍵そのものを含むゾーンの内容の更新時・署名の有効期間の満了時に、ゾーンの再署名が必要になります。その際、ゾーンに存在するリソースレコードの署名に要するコスト（システム負荷、所要時間）とゾーンに付加されるRRSIGリソースレコードのデータサイズ（それに伴うDNS応答のサイズ）を小さくするためには、署名鍵は比較的短い鍵長である必要があります。

この、「十分な強度（ビットサイズ、鍵長）」と「比較的短い鍵長」という相矛盾する要求は、以下のようなKSKとZSKの二つの鍵を使った運用により両立できます。

Latin American & Caribbean Country Code Top Level Domainsの略称。
1998年にスタートした中南米地域のccTLD連合組織です。レジストリ業務を運営していく上で必要となる情報を交換する場となっています。

DNSにおいて、権威サーバー（権威DNSサーバー）がゾーンを委任されているにもかかわらず、そのゾーンの情報を適切に返さない状態です。
lame delegationの状態は、名前解決の遅延や失敗が発生するだけでなく、ドメイン名の管理権限を奪われる「ドメイン名ハイジャック」を招く原因にもなり得ます。

* 権威サーバー（権威DNSサーバー）（JPRS）
* ゾーン（JPRS）
* 委任（JPRS）
* 名前解決（Name Resolution）（JPRS）
* DNSの健全な運用のために ～Lame Delegation編～（JPRS）
* lame delegationとは（JPNIC）
* インターネット10分講座：lame delegation（JPNIC）
* DNS Tips：「ゾーンがlame」ってどういう意味？

HTMLソースの中に「http」で記述されたリンクが残っている状態です。

常時SSL化した場合、URLはhttpsから始まるものに変更となります。そのため、HTMLファイル内の内部リンクやサイトマップに記載しているURLをすべてhttpsから始まるものに書き換える必要があります。特にimgタグや、cssを読み込むリンク先などでhttpから始まる絶対パスを使用し、一つのページ内でhttpsとhttpが混在する状態となった場合、「mixed content」という状態となり、ブラウザーによっては鍵マークが表示されなかったり、警告が表示され利用者の混乱につながることがあります。

mixed contentを避けるために、内部リンクのURLを

・一律「https://」から始まる絶対パスに書き換える
・絶対パスではなく、相対パス（もしくはルート相対パス）で記述する

のどちらかを行う必要があります。

なお、外部リンクに関しては、httpのURLで記載していても、mixed contentとなることはありませんが、スタイルシートや画像を外部から読み込んでおり、そのURLがhttpの場合はmixed contentとなってしまいます。読込先がhttpsに対応していればhttpsに書き換え、非対応の場合には外部からの読み込みを中止するなどの対策が必要です。特に動画や広告バナーなどがhttpのURLで記載してないか、注意してください。

ブラウザーに搭載された開発者向けのツールを用いることで、ソースコード上でmixed contentの原因となっている箇所を特定することができます。

※ mixed contentの解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* 常時SSL化について（JPRSサーバー証明書発行サービス）

mail exchange（メールサーバー、メールを配送するホスト）を指定するためのリソースレコードです。
MXリソースレコードの特徴として、配送における優先度を指定する「プリファレンス（preference）」があり、「配送先ホスト」ごとに指定されます。プリファレンスによる優先度は数字で示され、配送先が複数ある場合には、より小さなプリファレンスを持つホストが優先されます。これにより、配送するメールサーバーの優先度を指定でき、メールサービスの可用性向上が期待できます。
下記の例では、メールの配送先として二つのホストが存在し、この場合、優先されるホストはプリファレンスが「10」の「mx1.example.jp」となり、mx1.example.jpへの配送に失敗した場合に「mx2.example.jp」を使うという指定となります。


* NSリソースレコード（JPRS）
* Aリソースレコード（Aレコード）（JPRS）
* AAAAリソースレコード（AAAAレコード）（JPRS）

A Stringprep Profile for Internationalized Domain Namesの略称。
国際化ドメイン名にSTRINGPREPを適用するための規定です。アプリケーション内部でドメイン名として処理するに際しては、適切な正規化処理が必要であるため、この規定が定められています。

* 国際化ドメイン名（Internationalized Domain Name: IDN）（JPRS）
* 正規化（JPRS）
* STRINGPREP（ストリングプレップ）（JPRS）

Nominating Committee（指名委員会）の略称。
ICANN内の委員会で、事務総長と支持組織選出理事を除くICANN理事、ALAC（At-Large諮問委員会）委員、GNSO評議員、ccNSO評議員を選定する役割を担います。

あるゾーンの親ゾーンの委任情報（NSリソースレコード）が適切に設定されておらず、lame delegationになっていることを利用し、管理権限を持たない第三者がそのゾーン（ドメイン名）の乗っ取りを図る攻撃手法です。

外部のDNSサービスやホスティングサービスなどを利用する場合、そのサービスを利用するための委任情報を、親ゾーンに登録・設定します。例えば、example.jpの管理者がns-99.example.netで運営されるDNSサービスを利用する場合、jpゾーンに以下の委任情報を登録・設定します。

図1：委任情報の設定例

図2：lame delegationになった状態

図3：NS Takeoverによる攻撃が成立

図4：不要な委任情報の削除

DNSソフトウェアの一つで、オランダのNLnet Labsと、RIPE NCCにより共同で開発された権威サーバー（権威DNSサーバー）ソフトウェアです。NSDは、「Name Server Daemon」の略称です。
NSDは権威サーバーの機能のみに絞ったシンプルな実装が特徴であり、高い応答性能を持ちます。フルサービスリゾルバー（キャッシュDNSサーバー）の機能はありません。

* nlnetlabs.nl :: Name Server Daemon (NSD) ::
* nlnetlabs.nl :: Home ::
* RIPE NCC（ライプエヌシーシー）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* ルートサーバー（root servers）（JPRS）

あるゾーンに対する権威（オーソリティ）を持つ権威サーバー（権威DNSサーバー）を指定するためのリソースレコードです。ゾーンを委任する際に使用され、複数台の権威サーバーがある場合には、その数だけNSリソースレコードをゾーンファイルに記述する必要があります。

記述例）
example.jp. IN NS ns1.example.jp.
                IN NS ns2.example.jp.

委任情報は権威を持つ情報ではないため、権威を持つNSリソースレコード、グルーに対応するAまたはAAAAリソースレコードを委任先に記述する必要があります。委任情報と委任先のNS、A、AAAAの各リソースレコードが一致していない場合、実装によっては誤動作する可能性があるため一致させておく必要があります。
NSリソースレコードは、以下に示す二つの意味で使われます。

  ・親となる委任元が、子となる委任先を指定する
  ・委任先で、そのゾーンの権威サーバー（権威DNSサーバー）を記述する

* Aリソースレコード（Aレコード）（JPRS）
* AAAAリソースレコード（AAAAレコード）（JPRS）
* MXリソースレコード（MXレコード）（JPRS）
* ゾーン（JPRS）
* 親ゾーン（JPRS）
* 子ゾーン（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 親の心子知らず？ 委任にまつわる諸問題について考える ～ランチのおともにDNS～（JPRS）
* DNS Tips：NSリソースレコードについて教えてください

DNSサーバーに対するDoS攻撃手法の一つです。
攻撃者は、自身が管理権限を持つドメイン名（以下の例ではexample.com）の委任情報として、攻撃対象となるドメイン名（以下の例ではexample.jp）に、互いに異なる存在しないサブドメインを付加したドメイン名（fake-1.example.jp、fake-2.example.jp、…、fake-n.example.jp）を権威サーバー（権威DNSサーバー）に指定した、多数のNSリソースレコードを登録します。
この状態で攻撃者が準備したexample.comのドメイン名に対する名前解決が実行された場合、フルサービスリゾルバー（キャッシュDNSサーバー）から攻撃対象となるexample.jpの権威サーバーに、登録されたNSリソースレコードのドメイン名を名前解決するための問い合わせが行われます。攻撃者はフルサービスリゾルバーを利用して攻撃の規模を拡大し、example.jpの権威サーバーや名前解決を実行しているフルサービスリゾルバーを、サービス不能の状態に陥らせます。

* ランダムサブドメイン攻撃（DNS水責め攻撃）（JPRS）
* DoS攻撃（DDoS攻撃）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 委任情報（JPRS）
* NSリソースレコード（JPRS）
* 外部名（JPRS）
* 名前解決（Name Resolution）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* DNSリフレクター攻撃（DNSアンプ攻撃）（JPRS）
* NXNSAttack: upgrade resolvers to stop new kind of random subdomain attack | The CZ.NIC Staff Blog（CZ.NICによるNXNSAttackの解説記事）

OCSP（Online Certificate Status Protocol）は、証明書のステータス情報をリアルタイムに提供するプロトコルのことです。


※ OCSP（Online Certificate Status Protocol）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー/認証局運用規程（CertificatePolicy/Certification PracticeStatement）

ユーザーに割り当てられたIPアドレスから、組織外ネットワークのIPアドレス宛のUDP及びTCPの53番ポートへの通信をブロックすることです。53番はDNSサービスのためのポート番号であり、このポートへの通信をブロックすることで、組織内のユーザーがフルサービスリゾルバー（キャッシュDNSサーバー）を独自に動かしたり、外部のフルサービスリゾルバーや権威サーバー（権威DNSサーバー）にアクセスしたりすることをブロックします。
OP53Bはマルウェアによる不正なサイトへの誘導や、DNSを経由した情報漏えいを防止するために使われます。ただし、ISPが顧客向けネットワークにOP53Bを適用する場合、通信の秘密への配慮が必要になります。



* IP53B（Inbound Port 53 Blocking）（JPRS）
* UDP（ユーディーピー）（JPRS）
* TCP（ティーシーピー）（JPRS）
* ポート番号（port number）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* ISP（アイエスピー）（JPRS）

EDNS0により定義される、特殊なリソースレコードです。
通信中のDNSメッセージのadditionalセクション中にのみ存在し、クライアントが受け取り可能なメッセージサイズ（ペイロードサイズ）やフラグ、ステータスといった情報をやりとりする目的で使われます。EDNS0オプションにより、複数の機能や情報をOPT疑似リソースレコードに含め、相手に伝達することができます。

OPT疑似リソースレコードによる情報伝達にはEDNS0のサポートが必要であり、通信相手がEDNS0をサポートしているか否かは以下のように判定されます。

EDNS0をサポートした送信元は、OPT疑似リソースレコードを付加したDNSメッセージを通信相手に送信します。相手がEDNS0をサポートしている場合にはEDNS0が付加された応答が返るため、その相手との通信ではEDNS0が有効になります。相手がEDNS0をサポートしていないことを検知した場合、送信元はOPT疑似リソースレコードを付加しないDNSメッセージを再送し、その相手との通信ではEDNS0を無効とします。

* JPRSトピックス＆コラム（No.8）：「512の壁」を越える～EDNS0の概要と運用上の注意～（JPRS）
* EDNS0（イーディエヌエスゼロ）（JPRS）
* リソースレコード（JPRS）
* 応答 ※ DNSメッセージ形式の説明あり（JPRS）
* 問い合わせ（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

PKI（Public Key Infrastructure：公開鍵基盤）は、電子署名、暗号化、認証といったセキュリティ技術を実現するための、公開鍵暗号方式という暗号技術を用いる基盤のことです。


※ PKI（Public Key Infrastructure：公開鍵基盤）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

別のドメイン名空間を指し示すためのリソースレコードで、逆引きDNSや、DNSを用いたサービス発見（※）におけるサービスの列挙のために使われます。
以下に、IPv4及びIPv6アドレスにおける逆引きDNSの記述例を示します。

• IPv4の場合はIPアドレスの表記を逆順にした上で「in-addr.arpa.」を最後に付け加えます。
  2.2.0.192.in-addr.arpa. IN PTR mail.example.jp.


• IPv6の場合はニブル（4bit）ごとに区切ったIPアドレスをドットで連結し、逆順にした上で「ip6.arpa.」を最後に付け加えます。
  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.example.jp.

国際化ドメイン名（Internationalized Domain Name: IDN）をアプリケーションで扱えるようにするための仕組みの一つです。
具体的には、国際化ドメイン名の規格であるIDNA（Internationalized Domain Names in Applications）と共に使用されるよう設計された、Unicodeのコードポイント（文字ごとに割り当てられる固有の番号）を、ASCII文字のみを使用して表現する符号化方式（ASCII Compatible Encoding）です。
Punycodeは、Unicode文字列を一意かつ可逆的にASCII文字列に変換します。具体的には、ASCII文字はそのまま表現され、非ASCII文字は英数字とハイフンで構成されるASCII文字で表現されます。
Punycodeの符合化方式に従ってASCII文字に変換した結果にACEプレフィックス（接頭辞）「xn--」を付加したラベルを、「A-ラベル（A-label）」と呼びます。

* 日本語JPドメイン名のPunycode変換・逆変換 - 日本語.jp（JPRS）
* 国際化ドメイン名（Internationalized Domain Name: IDN）（JPRS）
* IDNA（アイディーエヌエー）（JPRS）
* Unicode（ユニコード）（JPRS）
* ASCII（アスキー）（JPRS）
* ラベル（JPRS）
* DNS Tips：国際化ドメイン名を使えるようにするための設定を教えてください
* Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)

RA（Registration Authority：登録局）は、CA（Certification Authority：認証局）の業務のうち、証明書発行に必要な情報の登録、CAに対する証明書発行要求等を行う主体のことです。


※ RA（Registration Authority：登録局）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

Request for Commentsの略称。
インターネットの技術標準を記した文書で、IETFにおける議論の後に策定されます。Internet-Draftの投稿、分野ごとのWGで議論が行われた後、文書化が必要と判断されたものはIESGに対してRFCにするように申請が行われ、審査の後にRFC番号が発行されます。RFCとなると恒常的にIETFのサーバーにおいて参照可能となります。

* JPRSトピックス＆コラム（No.22）：インターネット標準の作られ方～IETFにおける標準化とRFCの概要～（JPRS）

Réseaux IP Européens Network Coordination Centreの略称。
世界に五つあるRIR（地域インターネットレジストリ）の一つで、ヨーロッパ、中近東、北アフリカ、アジアの一部の地域のIPアドレスの割り振り・管理を行っています。
RIPE NCCの事務所はオランダのアムステルダムに置かれています。

* RIPE NCC
* RIRs | 関連組織リンク集（JPRS）

Réseaux IP Européensの略称。
広域IPネットワークに関心のあるすべての人に開放されたフォーラムです。RIPEの目的は、RIPE地域内のインターネットのオペレーションに必要な管理上及び技術上の調整です。

* RIPE
* オペレーターコミュニティ | 関連組織リンク集（JPRS）

Regional Internet Registry（地域インターネットレジストリ）の略称。
ICANNは世界を五つの地域に分け、それぞれの地域でIPアドレスの割り当て管理を行うレジストリ組織としてRIRを定めています。RIRは各国ごとのIPレジストリの上位に位置しています。RIRは、アジア太平洋地域のAPNIC、欧州・中近東地域のRIPE NCC、北米地域のARIN、中南米地域のLACNIC及びアフリカ地域のAfriNICとなっています。

同じドメイン名、タイプ（型）、クラスを持ち、データが異なるリソースレコードの集合です。
DNSは、ドメイン名、タイプ（型）、クラスを検索キーとするデータベースです。RRsetとなっているリソースレコードは一つの集合として扱われ、応答の際には設定されているすべてのリソースレコードを返す必要があります。また、応答に含まれるリソースレコードの並び順は不定です。
以下の例に示すように、example.jpのゾーンを複数の権威サーバー（権威DNSサーバー）に委任する際のNSリソースレコードの集合はドメイン名、タイプ、クラスが同じであることから、これがRRsetとなります。


* リソースレコード（JPRS）
* ゾーン（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* NSリソースレコード（JPRS）
* RRset（リソースレコードセット）（JPRS）

DNSSECにおいて、リソースレコードセット（RRset）に対する電子署名が格納されるリソースレコードです。RRSIGは、Resource Record digital SIGnatureを意味します。
DNSSECでは、権威サーバー（権威DNSサーバー）が応答にRRSIGリソースレコードを付加します。応答を受け取った側（バリデーター）は、付加されていたRRSIGリソースレコードと、別途取得したそのゾーンのDNSKEYリソースレコードを用いて（※）応答を検証します。
RRSIGリソースレコードのゾーンファイルにおける表現は以下の通りです。

例）

• ・type covered：署名対象のリソースレコードタイプを示します（例：IPv4アドレスであればAを指定）。
• ・algorithm： DNSSECのアルゴリズム番号である8を指定します。
• ・labels： ドメイン名のラベル数を示します（例：対象が「ns.example.jp」の場合、3を指定）。
• ・original TTL： 署名対象のリソースレコードのTTL値を指定します。
• ・signature expiration： 署名の有効期間終了時刻を指定します。
• ・signature inception： 署名の有効期間開始時刻を指定します。
• ・key tag： 署名を検証するDNSKEY リソースレコードの鍵のIDを指定します。
• ・signer’s name： 署名対象のRRsetのゾーン名を指定します。
• ・signature： Base64により符号化した署名を記述します。

Root Server System Advisory Committee（ルートサーバーシステム諮問委員会）の略称。
ICANNの諮問委員会の一つです。ルートサーバーシステムのオペレーションについて、ICANN理事会に対して助言を行います。RSSACは、ルートサーバー運用管理者などによって構成されています。

* RSSAC
* ICANN関連 | 関連組織リンク集（JPRS）

通信相手にデータを送信してから応答が返ってくるまでの時間（通信の往復時間）です。
多くのフルサービスリゾルバー（キャッシュDNSサーバー）は、問い合わせ先となる権威サーバー（権威DNSサーバー）が複数ある場合、それらのRTTをチェックし、RTTがより短かった権威サーバーを優先して選択します。このようにして名前解決にかかる時間の短縮を図っています。

* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 名前解決（Name Resolution）（JPRS）

2020年11月にカリフォルニア大学リバーサイド校と清華大学の研究者が発表した、DNSキャッシュポイズニングの手法です。ICMPの実装の特性を利用したサイドチャネル攻撃によって問い合わせのポート番号を外部から推測し、ソースポートランダマイゼーションの効果を減らすことで、攻撃成功の確率を向上させます。
本攻撃によるポート番号の推測には時間を要します。そのため、発表では攻撃可能な時間を確保するための追加の手段として、権威サーバーに問い合わせを大量に送り、DNS RRLを発動させることが挙げられています。
本攻撃の対策として、OSのICMP実装の改良、DNSSECの適用、リゾルバー側で攻撃を検知した際のTCPでの再問い合わせなどが挙げられます。

* DNSキャッシュポイズニング（JPRS）
* TCP/IP（ティーシーピーアイピー）（JPRS）
* DNSSEC（ディーエヌエスセック）（JPRS）
* ソースポートランダマイゼーション（JPRS）
* UDP（ユーディーピー）（JPRS）
* DNS RRLの概要と実装状況（JPRS）
* SAD DNS（SAD DNS公式サイト）
* CVE - CVE-2020-25705（本脆弱性のCVE-ID）
* SAD DNS Explained（Cloudflareによる解説）

サーバー証明書のSubjectAltNameフィールドを指します。

SANには、そのサーバー証明書を設定・使用するサーバーを示すドメイン名・IPアドレス・URIなどを記述し、それらの識別子（ID）をその証明書に関連付けます。SANは「サブジェクト代替名」を意味しており、証明書に関連付ける実体（entity）を記述するSubjectフィールドの情報を追加・置き換える形で、識別子を複数記述できます。

SANに複数の識別子を記述した場合、そのサーバー証明書はSANに記述したすべてのサーバーで設定・使用できます。複数記述できるため、SANs（サンズ）と呼ばれることもあります。

JPRSサーバー証明書発行サービスの「ダブルアドレスオプション」は、SANにサブドメインwww付き（例：www.example.jp）と、wwwなし（例：example.jp）の二つのドメイン名を記述することで実現しています。

* SANs（サンズ、Subject Alternative Names）（JPRS）
* ダブルアドレスオプション（JPDirect）
* サーバー証明書発行サービス（JPRS）

South Asian Network Operators Groupの略称。
南アジア（アフガニスタン、バングラデシュ、ブータン、インド、モルジブ、ネパール、パキスタン、スリランカなど）のネットワークオペレーターによるグループです。2003年1月の第1回開催以来、年2回のペースで会合を開き、ネットワーク運用関係の情報交換、議論を行っています。

* SANOG
* オペレーターコミュニティ | 関連組織リンク集（JPRS）

SAN（Subject Alternative Name）の複数形です。JPRSサーバー証明書発行サービスの「ダブルアドレスオプション」は、SANにサブドメインwww付き（例：www.example.jp）と、wwwなし（例：example.jp）の二つのドメイン名を記述することで実現しています。

詳細については、「SAN」をご覧ください。

* SAN（サン、Subject Alternative Name）（JPRS）
* ダブルアドレスオプション（JPDirect）
* サーバー証明書発行サービス（JPRS）

SCT（Signed Certificate Timestamp）は、サーバー証明書のデータが格納されたことを保証するタイムスタンプ情報です。


※ SCT（Signed Certificate Timestamp）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* Certificate Transparencyとは（JPRSサーバー証明書発行サービス）

SHA-256（Secure Hash Algorithm 256）は、電子署名に使われるハッシュ関数（要約関数）の一つです。
ビット長は256 ビット。で、データの送信側と受信側でハッシュ値を比較することで、通信途中で原文が改ざんされていないかを検出することができます。


※ SHA-256（Secure Hash Algorithm 256）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

Second Level Domainの略称。
ドメイン名はピリオドで区切られますが、右側から2番目の文字列がSLDです。「jprs.co.jp」の場合、SLDは「co」になります。

RFC 6066で定義される、一つのIPアドレスで複数のドメイン名のサーバー証明書を運用できるようにする、TLSの拡張機能です。

一つのIPアドレスが割り当てられたWebサーバーで複数のドメイン名のWebサイトを運用する、バーチャルホストと呼ばれる機能があります。SNIに対応することで、それぞれのバーチャルホストで運用されるWebサイトに、異なるサーバー証明書をインストール・運用できるようになります。
SNIを利用する場合、Webサーバー及びWebブラウザーの双方の対応が必要になります。

* バーチャルホスト（JPRS）
* サーバー証明書発行サービス（JPRS）

ゾーンの起点を示し、ゾーンの管理情報を指定するためのリソースレコードです。SOAリソースレコードは、一つのゾーンに一つだけ記述されます。

SOAリソースレコードの1行目の「ns1.example.jp.」は当該ゾーンを管理するプライマリサーバーの名前（MNAME）で、「root.example.jp.」は管理責任者のメールアドレス（RNAME）です。SOAリソースレコードにおける記述では、メールアドレスの“@”を“.”（ドット）に変更して記述します。いずれも、絶対名となるように最後にドットを付けます。
2行目の数字はゾーンデータのシリアルナンバー（SERIAL）で、通常、ゾーンデータを更新するたびに数を増やします。
3行目以降は時間を指定するためのフィールドで、いずれも秒数で指定します。

• ・REFRESH： セカンダリサーバーがプライマリサーバーにゾーン情報の更新を確認する間隔を指定
• ・RETRY： セカンダリサーバーがゾーン情報を更新できなかった場合に再度更新を試みる間隔を指定
• ・EXPIRE： ゾーン情報の更新ができない状態が続いた場合、セカンダリサーバーが持っているデータを継続して利用できる最大時間を指定
• ・Minimum： ネガティブキャッシュのTTLを指定

Sender Policy Frameworkの略です。電子メールの送受信において、送信者のメールアドレス詐称によるなりすましを防ぐことを目的とした仕組みの一つです。
SPFの基本的な仕組みは、以下の通りです。

【送信側】
メール送信側となるドメイン名の管理者は、メールを送信する可能性のあるメールサーバーの一覧（SPF情報）をDNSに登録します。
【受信側】
メール受信側は、以下の手順により、送信元のIPアドレスがそのドメイン名のメールサーバーとして使用可能かどうかを認証します。

1. 1. 受け取ったメールアドレスのドメイン名部分（＠の右側）を使用してDNS問い合わせを行い、登録されているSPF情報を取得します。得られたSPF情報から、メールを送信する可能性のあるメールサーバーの一覧を得ます。


2. 2. メール送信元のIPアドレスが、1.で得られたメールサーバーの一覧に含まれているかを検査します。送信元のIPアドレスが一覧に含まれていればPass（認証成功）として扱います。

Shared Registry Systemの略称。
ドメイン名の登録情報をレジストリとレジストラの間で交換するためのシステムです。SRSでは、独立した複数のレジストラがレジストリと情報交換可能です。

Security and Stability Advisory Committee （セキュリティと安定性に関する諮問委員会）の略称。
ICANNの諮問委員会の一つで、インターネットのネーミング及びアドレス割り振りシステムのセキュリティと完全性に関する問題について、ICANNコミュニティ及びICANN理事会に対して助言を行います。SSACは、ルートサーバー運用管理者、gTLD/ccTLD運用者、レジストラ、RIRsなどの技術関係者によって構成されています。

* 略称は2004年に「SECSAC」から「SSAC」に変更されました。

* SSAC
* ICANN関連 | 関連組織リンク集（JPRS）

Preparation of Internationalized Stringsの略称。
Unicodeの文字列を扱う際の正規化の方式を規定しています。同一の文字が複数の文字コードを持っていたり、特定の文字の組み合わせが異なる順序でも同じ表示となるといった、Unicodeの特性を克服するための規定です。

* 国際化ドメイン名（Internationalized Domain Name: IDN）（JPRS）
* 正規化（JPRS）
* NAMEPREP（ネームプレップ）（JPRS）

CDN（Content Delivery Network）サービスやWebサービスの利用開始時に設定したサブドメインのDNS設定がサービスの利用終了後も残ったままになっていることを利用し、ドメイン名の管理権限を持たない第三者が、そのサブドメインの乗っ取り（テイクオーバー）を図る攻撃手法です。

外部のCDNサービスやWebサービスを利用する際、利用に必要なCNAMEリソースレコードやA/AAAAリソースレコードの設定を、事業者側から求められる場合があります。例えば、example.jpの管理者がcdn.example.netで運営されるCDNサービスを利用し、campaign.example.jpというドメイン名で期間限定のWebサイトを公開する場合のCNAMEリソースレコードの設定例は、以下のようになります。

図1：CNAMEリソースレコードを用いた設定例

図2：Webサイトにアクセスできなくなった状態

図3：Subdomain Takeoverによる攻撃が成立

図4：不要なCNAMEリソースレコードの削除

Transmission Control Protocolの略称。
インターネットで利用される通信プロトコルの一つで、RFC 793で定義されています。
相手との接続（コネクション）を事前に確立し、通信相手ごとに通信の状態を管理する「コネクション型」と呼ばれる方式を採用しており、到達確認や再送処理も行います。
そのため、通信の信頼性が高くなりますが、通信コスト（負荷）も高くなるという特徴があります。

それに対してUDPは、通信を始める際の事前処理や通信中の状態確認を行わないため、通信コストが低く、遅延が少ないという特徴を持ちます。
このような特徴から、TCPはWebサイトの閲覧やメールの送受信で、UDPは音声や動画のストリーミングなどで使用されます。DNSでは、TCPとUDP双方の通信プロトコルを使用します。

* UDP（ユーディーピー）（JPRS）
* プロトコル（JPRS）
* コネクション型（JPRS）
* コネクションレス型（JPRS）

TCP/IPは、インターネットやLAN上で使用される標準的なプロトコル群です。トランスポート層プロトコルであるTCP（Transmission Control Protocol）とネットワーク層プロトコルであるIP（Internet Protocol）という二つの通信プロトコルからなります。
1970年代前半にビント・サーフ氏らによって開発が始められ、1983年に現在のインターネットの原型とされるARPANETに公式に採用されました。

DNSメッセージのHeaderセクション内に存在する、応答の際に意味を持つビットであり、truncation を意味します。TCビットの値が“1”であった場合、DNSメッセージがUDPで送信可能なサイズを超えたために「切り詰め」が起こったことを示します。
TCビットがセットされた応答を受け取った場合、問い合わせ送信元は同じ内容の問い合わせをTCPで送信します（TCPフォールバック）。


* DNS Tips：DNSパケットフォーマットと、DNSパケットの作り方
* 問い合わせ（JPRS）
* 応答（JPRS）

レジストリがドメイン名の登録情報についてすべての情報項目を保持し、レジストラも同等の情報を保持する管理方式（モデル）です。

2000年以降に新設されたgTLD（分野別トップレベルドメイン）はThickレジストリモデルを採用しています。

また、Thinレジストリモデルを採用しているTLD（.com、.net、.jobs）も、ICANNにおける検討結果を受けThickレジストリモデルへの移行が進められています（2017年10月現在）。

* Thinレジストリモデル（JPRS）
* gTLD（分野別トップレベルドメイン）（JPRS）
* 日本におけるインターネット資源管理の歴史 第7章 ICANNによるグローバルなドメイン名管理体制（JPNIC）
* Thin WHOIS/Thick WHOISとは（JPNIC）
* レジストリ（JPRS）
* レジストラ（JPRS）

レジストリがドメイン名の登録情報について最小限の情報項目（当該ドメイン名のネームサーバー、ドメインステータス、情報登録日及び管理レジストラなど）のみを保持し、それ以外の情報項目はレジストラが保持する管理方式（モデル）です。
レジストリ・レジストラモデルの導入にあたり、レジストリは小さくあるべきという考え方があり、.comや.netのレジストリはThinレジストリモデルで再構築されました。

※ レジストリがすべての登録者情報を保持するモデルは、Thickレジストリモデルと呼ばれます。

* Thickレジストリモデル（JPRS）
* gTLD（分野別トップレベルドメイン）（JPRS）
* 日本におけるインターネット資源管理の歴史 第7章 ICANNによるグローバルなドメイン名管理体制（JPNIC）
* Thin WHOIS/Thick WHOISとは（JPNIC）
* レジストリ（JPRS）
* レジストラ（JPRS）

Top Level Domainの略称。
ドメイン名において、ドットで区切られた文字列の一番右の部分（ラベル）のことです。

インターネットのドメインは、ルート（.）と呼ばれる頂点を持ち、そこから木を逆さまにしたような形（階層構造）で構成されています。ルートの最初の分岐（ルートの直下）がトップレベルドメイン（TLD）で、以降、セカンドレベルドメイン（2LD）、サードレベルドメイン（3LD）というように階層構造が構成されます。


* ラベル（JPRS）
* ルート（JPRS）

2021年5月にSIDN Labs、InternetNZ、南カリフォルニア大学情報科学研究所（USC/ISI）が連名で発表した、権威サーバーをDDoS攻撃可能な脆弱性です。

攻撃者は、自身が管理権限を持つ複数のドメイン名（以下の例ではexample.jpとexample.com）を準備し、それぞれの親ゾーン（以下の例ではjpとcom）に外部名の循環参照が発生する形で委任情報を登録しておきます。

（jpゾーンに登録）
example.jp. IN NS ns1.example.com.
（comゾーンに登録）
example.com. IN NS ns1.example.jp.

この状態で、攻撃者が準備したドメイン名（example.jpまたはexample.com）に対する名前解決を実行した場合、フルサービスリゾルバー（キャッシュDNSサーバー）において循環参照が発生することになります。もし、当該フルサービスリゾルバーにおいて循環参照の検知や外部名の参照回数の制限が設けられていない場合、権威サーバーへの問い合わせが無限に実行されることになります。

発表者からは、Google Public DNSとCisco OpenDNSがtsuNAMEに対し脆弱であった旨が報告されています（いずれも修正済み）。また、BIND 9、Unbound、PowerDNS Recursor 4.0以降では名前解決の動作に制限が設けられており、tsuNAMEの対象外である旨がそれぞれの開発元から発表されています。

本攻撃の対策として、委任情報の循環参照を検知するツールCycleHunterが公開されています。

* https://tsuname.io/（tsuNAME公式サイト）
* OARC 35 (Online) (6-7 May 2021): Public Disclosure DNS vulnerability · DNS-OARC (Indico)（OARC 35ワークショップの発表資料）
* GitHub - SIDN/CycleHunter: Python software that reads zone files, extract NS records, and detect cyclic dependencies（CycleHunter）
* TsuNAME DNS Vulnerability and BIND 9 - ISC（ISCによる解説）
* NLnet Labs - News - tsuNAME vulnerability and Unbound（NLnet Labsによる解説）
* TsuNAME vulnerability and PowerDNS Recursor | PowerDNS Blog（PowerDNSによる解説）

Time To Liveの略称。
DNSにおいて、リソースレコードをキャッシュに保持してもよい時間を秒単位で示す31ビットに符号化された整数で、ゼロまたは正の値（0から2147483647の値）を取ります。
TTLをゼロに設定した場合には、キャッシュしてはならないことを意味します。
たとえば、以下のようなリソースレコードがあったとします。

www.example.jp. 3600 IN A 192.0.2.1

2番目の「3600」がTTLで、この例では、このリソースレコードを受信した側では最大で3600秒（1時間）キャッシュしてよいということを示します。TTLはキャッシュに保持されたのち減少していき、ゼロになると当該リソースレコードがキャッシュから削除されます。

任意の値を保持するためのリソースレコードで、0オクテットから255オクテットまでの長さの値を複数保持できます。
TXTリソースレコードは汎用性の高さから、さまざまなプロトコルで使われています。例えば、迷惑メール対策で使われるSPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）では、設定内容や公開鍵を記述する際にTXTリソースレコードを使用しています。以下に、TXTリソースレコードを使用したSPFの設定例を示します。

User Datagram Protocolの略称。
インターネットで利用される通信プロトコルの一つです。相手との接続確立を行わずにデータを送信する「コネクションレス型」と呼ばれる方式を採用し、到達確認や再送処理などを行わないプロトコルです。
Webサイトの閲覧やメールの送受信などで使用されるTCPでは、相手との接続を事前に確立し、通信中の状態を確認するといった処理を行います。そのため、通信の信頼性が高くなりますが、通信コスト（負荷）も高くなります。それに対してUDPでは、通信を始める際の事前処理や通信中の状態確認を行わないため、通信コストが低く、遅延が少ないという特長を持ちます。
通信中のパケット紛失やデータ破損、到達順の不整合などが発生した場合の処理はUDPを使用するアプリケーション自身が担当する必要がありますが、一つのパケットで情報をやりとりできる場合には、数多くの通信相手に対して短時間（TCPの約3分の1）で応答を返すことができます。DNSでは、TCPとUDP双方の通信プロトコルを使用します。

* プロトコル（JPRS）
* TCP（ティーシーピー）（JPRS）
* DNSのメッセージサイズについて考える～ランチのおともにDNS～（JPRS）

Uniform Domain Name Dispute Resolution Policyの略称。
「.com」や「.net」、「.org」などのgTLDに適用されるDRP（ドメイン名紛争処理方針）です。裁判や仲裁とは異なる新たな紛争処理手段として策定され、簡易、迅速、低費用、非拘束（裁定結果は裁判の判決とは異なり拘束力を持たない）という特徴を持ちます。UDRPは、ドメイン名の登録・使用に関して生じた紛争を処理するための方針として、ICANN理事会が1999年8月26日に採択しました。
UDRPは、「統一ドメイン名紛争処理方針」と「統一ドメイン名紛争処理方針のための手続規則」の二つの文書から成ります。ICANN認定レジストラは、「統一ドメイン名紛争処理方針」を登録合意書に組み込まなければいけません。ICANNの認定した紛争処理機関は、「統一ドメイン名紛争処理方針のための手続規則」に従って紛争処理手続きを行います。
gTLDの登録者は、第三者からUDRPに基づく申し立てがあった場合には紛争処理機関の行う紛争処理手続きに参加し、その裁定結果に従うこととなります。

* Uniform Domain-Name Dispute-Resolution Policy
* WIPOによるドメイン名紛争統一処理方針(処理方針)についてのガイド
* gTLD取次サービス――統一ドメイン名紛争処理方針（JPRS）

DNSソフトウェアの一つで、フルサービスリゾルバー（キャッシュDNSサーバー）です。複数の組織によりプロトタイプとして開発された後、オランダのNLnet Labsによって実装されました。現在ではNLnet Labsが開発・保守を行っています。
Unboundはフルサービスリゾルバーとして十分な機能と性能を持ち、DNSSEC検証にも対応しています。

* Unbound
* nlnetlabs.nl :: Home ::
* Unboundの紹介とその運用（DNS Summer Day 2016）
* RIPE NCC（ライプエヌシーシー）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* DNSSEC（ディーエヌエスセック）（JPRS）

1993年に策定された文字コードの国際標準です。Unicode Consortiumが策定を行っています。
原則として数字しか扱えないコンピューターにおいて、文字を用いるためには文字コードが必要となります。Unicodeでは、世界中で使われている10万を超える文字を収録しています。

Uniform Resource Locatorの略称。
インターネット上でアクセス可能な情報の場所とアクセス方法をまとめて表す文字列です。「http://www.example.jp/」や「ftp://ftp.example.jp/」などがこれに当たります。上位概念にURI（Uniform Resource Identifier）があります。

ドメイン名やIPアドレスなどの登録者情報を、インターネットユーザーが参照できるようにするサービスです。Whoisの提供はレジストリやレジストラによって行われ、情報の公開範囲は各レジストリやレジストラの情報公開ポリシーに基づいて決められます。
Whoisを提供する目的には、以下のようなものがあります。

・ネットワークの安定的運用を実施する上で、技術的な問題発生の際の連絡のために必要なドメイン名やIPアドレスの管理者情報を提供
・ドメイン名の申請・届け出時に、同一ドメイン名や類似ドメイン名の存在を確認するために必要な情報を提供
・ドメイン名と商標などに関するトラブルの自律的な解決のために必要な情報を提供

*Whoisとは（JPRS）

Widely Integrated Distributed Environmentの略称。
オペレーティングシステム技術及び広域的なスケールにおける通信技術を基盤とした、新しい分散型のコンピューティング環境の確立を目指し、1988年に活動を開始したプロジェクトです。WIDE Projectでは研究活動のためのインターネット（WIDE Internet）を運用しています。また、JPRSは会社設立当初より同プロジェクトの研究活動に参加し、ルートサーバーのうち1台の管理運用を共同で行っています。

* WIDE Project
* インターネット・ドメイン名に関係する日本国内の団体 | 関連組織リンク集（JPRS）

World Intellectual Property Organizationの略称。
世界的な知的所有権の保護促進を目的とした国際連合（国連）の専門機関です。ドメイン名紛争処理方針であるUDRP（Uniform Domain Name Dispute Resolution Policy）の認定紛争処理機関の一つにもなっています。

* WIPO
* 国連組織 | 関連組織リンク集（JPRS）

World Wide Web（ワールドワイドウェブ）の略称。
インターネットで標準的に用いられるドキュメントシステムです。ハイパーテキストという概念に基づく分散型のシステムで、ドキュメントの記述には一般的にHTMLを用います。閲覧ブラウザーの普及が進んだ1990年代中頃以降、インターネットの爆発的な普及を牽引したシステムといえます。
WWWの技術標準は、World Wide Web Consortium（W3C）によって策定されています。

DNSSECにおいて、ゾーンのリソースレコードに署名するための鍵です。
DNSSECでは運用上の理由から、KSK（Key Signing Key、鍵署名鍵）とZSK（Zone Signing Key、ゾーン署名鍵）という、2種類の鍵を使用することが一般的です。
ZSKは、署名対象となるゾーンが権威を持つRRsetを署名する鍵で、署名にはZSK秘密鍵を用います。署名により、それぞれのRRsetに対応するRRSIGリソースレコードが当該ゾーンに付加されます。



また、ZSK公開鍵をDNSKEYリソースレコードの形式でゾーンに登録し、KSK秘密鍵で署名することにより、当該ゾーン内におけるKSKとZSKの間の信頼の連鎖を構築します。

DNSSECでは、DNSKEY RRsetを署名する鍵に対応するDS RRsetが親ゾーンに登録されることで、親子間の信頼の連鎖が構築されます。一般に、DS RRsetの登録には親への依頼、つまり申請作業が必要です。申請作業にはコスト（所要時間、手間）がかかるため、その頻度を下げるためにDS RRsetに対応する署名鍵には、十分な強度（ビットサイズ、鍵長）が必要になります。

また、DNSSECでは、署名鍵そのものを含むゾーンの内容の更新時・署名の有効期間の満了時に、ゾーンの再署名が必要になります。その際、ゾーンに存在するリソースレコードの署名に要するコスト（システム負荷、所要時間）とゾーンに付加されるRRSIGリソースレコードのデータサイズ（それに伴うDNS応答のサイズ）を小さくするためには、署名鍵は比較的短い鍵長である必要があります。

この、「十分な強度（ビットサイズ、鍵長）」と「比較的短い鍵長」という相矛盾する要求は、以下のようなKSKとZSKの二つの鍵を使った運用により両立できます。

管理対象の一部分を、別の管理者に委ねる仕組みのことです。
DNSでは、指定されたドメイン名を頂点とする別のゾーンを作ることを意味しており、委任するドメイン名のNSリソースレコードを親ゾーンに追加することで子ゾーンが作成されます。

上図で示した例では、example.jpゾーンがjpから委任されています。この時、example.jpゾーンを管理するのは委任された管理者です。example.jpゾーンの管理者は、たとえばexample.jpの中にabc.example.jpというサブドメインを作り、abc.example.jpゾーンの管理を別の管理者に委任することができます。この時、example.jpゾーンは、example.jpゾーンとabc.example.jpゾーンの二つに分割されます。このように、委任を行うことで新たなゾーンが作られ、その管理・運用を別の管理者が行うことになります。

* ゾーン（JPRS）
* NSリソースレコード（JPRS）
* DNS Tips：「委任」という仕組みが必要な理由を教えてください
* DNS Tips：「ゾーン」と「委任」と「権威」の関係について教えてください
* 親の心子知らず？ 委任にまつわる諸問題について考える～ランチのおともにDNS～（JPRS）

DNSにおける委任を作成するための情報で、委任するドメイン名のNSリソースレコードを親ゾーンに追加することで作成されます。
親ゾーンの権威サーバー（権威DNSサーバー）が返す委任情報には委任先のゾーンを管理する権威サーバー名が含まれ、必要に応じてグルーレコードが追加されます。

digコマンドによる委任情報の出力例）


* 委任（JPRS）
* NSリソースレコード（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* ゾーン（JPRS）
* グルーレコード（glue record）（JPRS）

重大な事件・事故に発展する可能性を持つ出来事や事件のことです。
一般に、インシデントは、アクシデント（accident：偶発事故）やハプニング（happening：出来事）とは区別されます。情報セキュリティ分野では、情報システムの運用におけるセキュリティ上の問題として捉えられる事象を指し、偶発的であるか意図的であるかは問題となりません。
インシデントの代表的なものに、情報流出、フィッシング、不正侵入、マルウェア感染、Webサイト改ざん、サービス不能攻撃（DoS攻撃）などがあります。
日本国内においてコンピュータセキュリティインシデントに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討や助言などを技術的な立場から行うJPCERT/CCでは、コンピュータセキュリティインシデントを以下のように定義しています。

Q3：「コンピュータセキュリティインシデント」とは何ですか？
A：コンピュータセキュリティに関係する人為的事象で、意図的および偶発的なもの (その疑いがある場合) を含みます。例えば、リソースの不正使用、サービス妨害行為、データの破壊、意図しない情報の開示や、さらにそれらに至るための行為 (事象) などがあります。
（「JPCERT/CC に関してよくある質問と答え」より引用）

*JPCERT/CC
*JPCERT/CC に関してよくある質問と答え――「組織概要」に関してよくある質問と答え
*CSIRTガイド - JPCERTコーディネーションセンター

インターネット全体を円滑に機能させるための体制、及び体制整備の活動のことをいいます。
狭義には、IPアドレス、ドメイン名などのネット資源の管理のあり方の意味で用いられます。現在、1998年に設立されたICANNが中心となり、インターネットガバナンスの実現を目指しています。

インターネットの基盤を構成するプロトコルに対し、DNSによる名前空間を提供するためのドメイン名で、トップレベルドメイン（TLD）として「.arpa」が割り当てられています。

.arpaは、元々はARPANETからの移行用のTLDとしてスタートしましたが、その後、IPアドレスの逆引きやENUMといったプロトコルでも用いられるようになり、「Address and Routing Parameter Area」を意味するドメイン名として再定義されました。
インフラストラクチャドメインの代表的な使用例を以下に示します。

• 
  in-addr.arpa（RFC 1035）： IPv4アドレスをドメイン名にマッピングする（IPv4の逆引き）


• ip6.arpa（RFC 3152）： IPv6アドレスをドメイン名にマッピングする（IPv6の逆引き）


• e164.arpa（RFC 6116）： E164番号（※）をインターネットURIにマッピングする（E164番号をインターネットURIに変換）

ドメイン名の登録管理におけるデータエスクローとは、ドメイン名の登録情報を第三者組織に預託することをいいます。その目的は、登録管理業務の別組織への移管があった場合に、移管先が登録管理業務を確実に実施できるようにすることです。

インターネット上のどのクライアントからの名前解決要求であっても実行してしまう状態のサーバーやネットワーク機器のことです。なお、ブロードバンドルーターやケーブルモデムといった機器に組み込まれているリゾルバーがオープンリゾルバーとなっているケースも存在します。
オープンリゾルバーは、大規模なDDoS攻撃への加担など、悪意のある第三者に意図せず利用されるリスクがあります。
一方、Google Puclic DNSやOpenDNSなど、管理されたオープンリゾルバーを提供しているサービスが存在します。これらは「パブリックリゾルバー（Public Resolvers）」と呼ばれることがあります。

* DNSサーバーの不適切な設定「オープンリゾルバー」について（JPRS）
* オープンリゾルバ(Open Resolver)に対する注意喚起（JPRS）
* オープンリゾルバ確認サイト（JPRS）
* DoS攻撃（DDoS攻撃）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* JPRSトピックス＆コラム（No.10）：DNSのしくみと動作原理～インターネットを支え続けるDNS～（JPRS）

コンピューティング及び情報通信の分野で、8ビット（bit）を示す単位のことです。1オクテット（octet）は、8ビットを表します。
コンピューターの開発当初において、情報量の単位であるバイト（byte）は、8ビットに固定されていませんでした。そのため、8ビットであることを明確に示すため、「オクテット」という用語を使うようになりました。

インターネットの住所に当たるドメイン名は、インターネット上のどこで使われても常に同じものを示す「一意性」を保障する必要があります。そのため、DNSはICANNが管理するルートサーバーを頂点とする階層構造を保つ必要があります。
オルタネート・ルートは、独自のルートサーバーを立ち上げ、ICANNの管理下にないドメイン名空間を構築したものです。オルタネート・ルートの存在によって、ドメイン名の一意性が保障できない可能性があるため、問題視されています。

委任先のネームサーバーの名前を分類するために使われる用語で、内部名でない名前の総称です。
詳細については、「内部名」をご覧ください。

* 内部名（JPRS）
* ネームサーバー（DNSサーバー）（JPRS）
* ゾーン（JPRS）
* グルーレコード（glue record）（JPRS）
* DNS Tips：「内部名」と「外部名」とは何ですか？

2008年にDan Kaminsky（ダン・カミンスキー）氏が発表した、DNSキャッシュポイズニング攻撃の効率を劇的に向上させる手法です。
従来の攻撃手法と異なり、攻撃対象の名前にランダムなラベルを付加した名前を用いることで、連続での攻撃を可能にしました。さらに、2008年にBernhard Muller（ベルンハルト・ミュラー）氏によってカミンスキー型攻撃手法に利用可能な攻撃のパターンが発表され、DNSキャッシュポイズニング攻撃のリスクが高まりました。
カミンスキー型攻撃手法の対策としては、フルサービスリゾルバー（キャッシュDNSサーバー）におけるソースポートランダマイゼーション、ソースアドレスランダマイゼーション、アクセス制御による利用者の限定、DNS Cookiesの利用などが挙げられます。
また、攻撃対象のドメイン名がDNSSECによって保護されている場合、DNSSEC検証をすることでDNSキャッシュポイズニング攻撃により注入された偽の応答を検知できます。

* JPRSトピックス＆コラム（No.9）：新たなるDNSキャッシュポイズニングの脅威～カミンスキー・アタックの出現～（JPRS）
* DNSキャッシュポイズニング（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* オープンリゾルバー（JPRS）
* ソースポートランダマイゼーション（JPRS）
* DNSSEC（ディーエヌエスセック）（JPRS）

公開鍵暗号方式を用いた「秘密鍵」と「公開鍵」の鍵ペアを生成する際に行われる手続きのことです。
JPRSでは、jpゾーンのDNSSEC署名に用いるための鍵ペア生成の手続きを「.jp DNSSECキーセレモニー」と呼んでいます。

* IANA - Root KSK Ceremonies
* .jp DNSSECキーセレモニーの実施について（第1回）（JPRS）
* .jp DNSSECキーセレモニー 作業手順書（2010年10月4日(月) 実施 第1回用）（JPRS）
* .jp DNSSECキーセレモニーチェックシート（JPRS）
* ルートゾーンにおけるKSKの管理方法（JPRS）
* DNSSEC（ディーエヌエスセック）（JPRS）

公開鍵暗号方式において、使用中の鍵ペアを別の鍵ペアに交換（ロールオーバー）することを表します。以下では、DNSSECのキーロールオーバーについて説明します。
DNSSECでは、暗号の危殆化（きたいか：守る対象が危険にさらされること）を避けるために定期的なキーロールオーバーが推奨されています。.jpゾーンでは、ZSK（Zone Signing Key：ゾーン署名鍵）については月次で、KSK（Key Signing Key：鍵署名鍵）については年次で更新を行っており、KSKの生成については作業が手順通りに実施されていることを第三者立ち会いの上、確認する仕組み（.jp DNSSECキーセレモニー）を採用しています。

*DNSSECとは（JPRS）
*JPドメイン名におけるDNSSEC運用ステートメント（JP DPS）（JPRS）

DNSを用いて、IPアドレスに対応するドメイン名を調べることです。
たとえば、「192.0.2.1」というIPアドレスに対応する「mail.example.jp」というメールサーバーのドメイン名を調べることを「192.0.2.1を逆引きする」といいます。
逆引きは、主にサーバー側においてアクセス元を判別したり、分析したりする際に使われます。また、逆引きで得られたドメイン名を正引きし、得られたIPアドレスを元のIPアドレスと比較することで、通信相手の存在や出自をある程度の信頼性で確認することができます。ただし、正引き、逆引きはそれぞれ異なったゾーンで管理され、その内容はそれぞれのゾーンの管理者に委ねられることから、双方の内容は必ずしも一致しないことに注意が必要です。

* 正引き（JPRS）
* 問い合わせ（JPRS）
* DNS Tips：「正引き」と「逆引き」って何ですか？

リゾルバーにおいて、名前解決で得たリソースレコードセット（RRset）を一時的に保持する仕組みです。
DNSでは、階層構造の頂点であるルートを起点として名前解決を行います。（図1）。ルートを管理するルートサーバーから毎回名前解決を行うのは負荷が高く、時間がかかるため、名前解決で得たリソースレコードをキャッシュに一時的に保持し、次回以降の名前解決時に使用することで名前解決の効率化を図ります（図2）。
キャッシュという仕組みを導入することで、以下に示す効果を得ることができます。

情報の暗号化と復号に共通の鍵を用いる暗号方式です。
共通鍵暗号では、暗号化と復号に同じ鍵を使用します。そのため、情報交換をする相手と事前に安全な方法で共通鍵を共有し、管理する必要があります。共通鍵が外部に漏れると、通信内容の秘匿性が保てなくなります。

共通鍵暗号は、暗号化や復号のための計算負荷が軽いという特長から、大量のデータの処理に向いています。DNSでは、ゾーン転送の安全性を確保するためのTSIG（Transaction SIGnature）で共通鍵暗号を使用しています。

* 公開鍵暗号（JPRS）
* DNSにおける秘密鍵のトランザクション認証(TSIG)（JPRS）

1998年1月に米国商務省が発表した文書「インターネットの名前及びアドレスの技術的管理の改善についての提案」のこと。
米国がそれまでにインターネットの整備に多大なコストを払ってきたことが述べられ、米国政府がインターネット資源管理への積極関与を検討していると受け取られたため、さまざまな議論や批判を呼びました。この議論の結果がホワイトペーパーへとつながりました。

権威サーバー（権威DNSサーバー）が、委任先のネームサーバーの名前を応答する際に追加する情報です。具体的には、ネームサーバーの名前に対応するIPアドレスです。
グルーレコードは、ネームサーバーの名前が委任先のドメイン名で管理されている場合にのみ必要になります。グルーレコードを追加することで、名前解決におけるループの発生を防ぎます（図1、図2）。
グルーレコードは委任情報の一部であり、権威を持たないという点に注意してください。



* 権威サーバー（権威DNSサーバー）（JPRS）
* ネームサーバー（DNSサーバー）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 名前解決（Name Resolution）（JPRS）
* 権威（オーソリティ）（JPRS）
* ゾーン（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* DNS Tips：グルーレコードで付加する情報とは

DNSにおいて、あるゾーンの管理権限を持っていることを表す言葉です。ルートゾーンを階層の頂点とし、親ゾーンから委任された権威サーバー（権威DNSサーバー）は、そのゾーンの完全な情報と子ゾーンへの委任情報を持ち、そのゾーンに対する「権威を持つ」と表現されます。

* ゾーン（JPRS）
* ルートゾーン（JPRS）
* 親ゾーン（JPRS）
* 子ゾーン（JPRS）
* 委任（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

公開鍵と秘密鍵という、対になる2種類の鍵（鍵ペア）を用いる暗号方式・暗号技術をいいます。

公開鍵暗号で実現される代表的な技術として、暗号通信と電子署名が挙げられます。
暗号通信では、受信者が鍵ペアを作成し、暗号化のための公開鍵を外部に公開して、復号のための秘密鍵を外部に漏れないように厳重に管理します。送信者が受信者の公開鍵でデータを暗号化して受信者に送り、受信者が自身の秘密鍵でデータを復号することで、送信者が作成したデータの機密性（受信者のみが内容を読めること）を実現できます（図1）。
暗号通信では、公開鍵は暗号化鍵、秘密鍵は復号鍵とも呼ばれます。

図1：暗号通信

電子署名では、送信者が鍵ペアを作成し、検証のための公開鍵を外部に公開して、署名のための秘密鍵を外部に漏れないように厳重に管理します。送信者が自身の秘密鍵で署名したデータを受信者に送り、受信者が送信者の公開鍵でデー
タの署名を検証することで、送信者が作成したデータの出自（送信者が作成したデータであること）と完全性（データの欠落や改ざんがないこと）を検証できます（図2）。
電子署名では、公開鍵は検証鍵、秘密鍵は署名鍵とも呼ばれます。

図2：電子署名

DNSでは、DNSSECの電子署名とその検証に公開鍵暗号技術を使用しています。

* 共通鍵暗号（JPRS）
* DNSSEC（ディーエヌエスセック）（JPRS）
* 電子署名（Digital Signature）（JPRS）

JPドメイン名において、運用上のトラブルを解決する際の連絡先として、登録者情報の代わりにインターネット上（Whois）で公開される連絡先情報です。
登録者自身の連絡先情報を登録する以外にも、登録者自身が情報を公開することを望まない場合には、登録者に適切に連絡を行える連絡先を連絡窓口として登録することができます。

英数字（ASCII）以外の文字を含むドメイン名、また、そのための技術規格です。日本語JPドメイン名は、国際化ドメイン名の一つです。
国際化ドメイン名は、英数字以外の文字をドメイン名として使いたいという要望から生まれました。既存のDNSとの互換性を維持するため、DNSでは国際化ドメイン名のラベル（U-ラベル）を決められた規則で英数字に変換します。変換の際に国際化ドメイン名であることを示す識別子として「xn--」というプレフィックス（接頭辞）を付けます。国際化ドメイン名では、「xn--」を含んだラベルを「A-ラベル（A-label）」と呼びます。
ラベルの変換例を以下に示します。

相手との接続（コネクション）確立を行わずデータを送信する方式です。通信を始める際の事前処理や通信中の状態確認を行わないため通信の信頼性は高くありませんが、その分、通信コスト（負荷）が低く、遅延が少ないという特長を持ちます。UDP（User Datagram Protocol）は、インターネットで使われる代表的なコネクションレス型プロトコルです。
DNSは、UDP及びTCPを使った通信を行います。


* コネクション型（JPRS）
* DNS（ディーエヌエス）（JPRS）
* UDP（ユーディーピー）（JPRS）

相手との接続（コネクション）を事前に確立し、通信相手ごとに通信の状態を管理する方式です。通信の状態を管理するため通信の信頼性が高くなりますが、その分、通信コスト（負荷）も高くなります。TCP（Transmission Control Protocol）は、インターネットで使われる代表的なコネクション型プロトコルです。
DNSは、UDP及びTCPを使った通信を行います。


* コネクションレス型（JPRS）
* DNS（ディーエヌエス）（JPRS）
* UDP（ユーディーピー）（JPRS）

DNSにおいて、名前解決を依頼（要求）する問い合わせです。通常、問い合わせ元はスタブリゾルバー（DNSクライアント）で、問い合わせ先はフルサービスリゾルバー（キャッシュDNSサーバー）です。

DNSでは、「再帰的問い合わせ」と「非再帰的問い合わせ（反復問い合わせ）」という二種類の問い合わせによって名前解決が行われます。

* DNS Tips：「再帰問い合わせ」と「非再帰問い合わせ」の違いを教えてください
* DNS Tips：DNSの問い合わせと応答について教えてください
* 名前解決（Name Resolution）（JPRS）
* 非再帰的問い合わせ（non-recursive query）（JPRS）
* 応答（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

認証局が提供するサービスの一つで、Webサイトの運営者が自分のWebページに設置するものです。サイトシールを設置することで、その認証局による認証を受けていることをWebサイトの訪問者にアピールすることができます。

Webサイトの訪問者が設置されたサイトシールをクリックすることで、サーバー証明書の有効性・内容などを確認できます。

サイトシールの提供の有無・提供されるサービスの仕様は、認証局や発行される証明書の種類により異なります。JPRSのサーバー証明書発行サービスでは、サイトシールを標準で提供しています。

* サイトシールについて（JPRS）
* サーバー証明書発行サービス（JPRS）

ドメイン名を、不正な目的で登録・使用すること。具体的には、以下のような行為を指します。

ドメイン名空間において、他のドメインを含むドメインがある時、含まれているドメインは、そのドメインのサブドメインです。ドメインはドメイン名空間の中の部分的な名前空間を指します。
たとえば、以下の図はドメイン名空間とサブドメインの関係を表しており、「co.jp」と「example.co.jp」、「example.jp」はいずれも「jp」のサブドメインです。

* ドメイン（JPRS）
* ドメイン名（Domain Name）（JPRS）

新しいドメイン名空間の登録開始に先立ち、レジストリにより設けられる特別な申請受付期間のことです。
ドメイン名は先願制（申請の先着順）による登録が原則ですが、先願制では混乱が生じる可能性があると考えられる場合に、先願制による登録の開始に先立って「サンライズ期間（sunrise period）」及び「ランドラッシュ期間（landrush period）」と呼ばれる期間が設けられます。

JPドメイン名における指定事業者は、ドメイン名登録者とJPRSの間に入ってドメイン名登録に関する窓口業務を行います。JPRSと指定事業者契約を結んだ事業者は、ドメイン名登録の取り次ぎだけでなく、自社の各種サービスと組み合わせて登録者に対する窓口サービスを提供することが多くなっています。

* 指定事業者とは（JPRS）
* ドメイン名の管理指定事業者の変更（JPRS）

常時SSL化（常時HTTPS化）は、Webサイトの一部のみをHTTPS化するのではなく、Webサイト全体をHTTPS化することです。

従来はログインページやクレジットカード決済ページなど、Webサイト上でパスワードや個人情報等を入力するページのみをHTTPS化して通信を保護することが一般的でした。

しかし近年、インターネットにおけるセキュリティ意識の高まりやGoogle Chromeなどの主要なブラウザーでの対応を受け、Webサイト全体をHTTPS化することが求められています。

※ 常時SSL化（常時HTTPS化）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* 常時SSL化について（JPRSサーバー証明書発行サービス）

自身で名前解決ができないため、通常、フルサービスリゾルバー（キャッシュDNSサーバー）に名前解決の実行を委ねるリゾルバーです。プログラムをコンパクトにできることから主として利用者側の端末で動作し、アプリケーションとの橋渡しを行います。
例えば、Webブラウザーがドメイン名に対応するIPアドレスを調べる場合、そのWebブラウザーがスタブリゾルバーを呼び出します。スタブリゾルバーは、フルサービスリゾルバー（キャッシュDNSサーバー）に対して問い合わせを行い、得られた応答結果をWebブラウザーに返します。


* 名前解決（Name Resolution）（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* 再帰的問い合わせ（recursive query）（JPRS）
* 非再帰的問い合わせ（non-recursive query）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

国際化ドメイン名において、文字列の表現形式を一つにすることを正規化といいます。一つの文字が複数の表現を持つ場合に、基準に沿ってそのドメイン名の表現方式を変換します。例えば、「JPRS.JP」や「JＰＲＳ。ＪＰ」などが正規化されると「jprs.jp」となります。

* 国際化ドメイン名（Internationalized Domain Name: IDN）（JPRS）
* 正規化（JPRS）
* NAMEPREP（ネームプレップ）（JPRS）
* STRINGPREP（ストリングプレップ）（JPRS）

DNSを用いて、ドメイン名に対応するIPアドレスやメールサーバー名などを問い合わせることです。
コンピューター同士が通信をする際に、インターネットではIPアドレスが使われます。一般に、IPアドレスは覚えにくく、かつ変更される可能性があるため、利用者はより覚えやすく、IPアドレスの変更によらず同じ名前が使用できるドメイン名を使用します。たとえば「mail.example.jp」というドメイン名を正引きすることで、「192.0.2.1」というメールサーバーのIPアドレスを得ます。
正引きは、Webサイトの閲覧やメールの送信、その他インターネットにおける一般的な通信において広く使われています。

* 逆引き（JPRS）
* 問い合わせ（JPRS）
* DNS Tips：「正引き」と「逆引き」って何ですか？

ゾーン転送を使用して、ゾーンデータを得る権威サーバー（権威DNSサーバー）です。
権威サーバーは、多重化することで負荷分散や冗長化を図ることができます。多重化する際には、扱うゾーンデータのマスターを管理する権威サーバーを用意し、そのゾーンデータをコピーして別の権威サーバーを動かします。この時、コピー元の権威サーバーが「プライマリサーバー」で、コピー先の権威サーバーが「セカンダリサーバー」となります。


* DNS Tips：プライマリ、セカンダリの使い方を教えてください
* 権威サーバー（権威DNSサーバー）（JPRS）
* ゾーン（JPRS）
* プライマリサーバー（マスターサーバー）（JPRS）

DNSにおいて、問い合わせごとに、フルサービスリゾルバー（キャッシュDNSサーバー）が権威サーバー（権威DNSサーバー）に送る問い合わせパケットのソースポート番号（発信元のポート番号）をランダムに変化させる手法です。
ソースポートランダマイゼーションは、DNSキャッシュポイズニングの攻撃成功率を下げることを目的としています。多数のポート番号をランダムに使うことにより、攻撃者が偽の応答を注入しにくくなります。


* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* 名前解決（Name Resolution）（JPRS）
* キャッシュポイズニング攻撃対策：キャッシュDNSサーバー運用者向け―基本対策編（JPRS）
* DNS Tips：ソースポートランダマイゼーションとは何ですか？

DNSにおいてゾーンの情報を定義するテキストファイルで、ゾーン内のリソースレコードをテキスト表現した形で構成されます。
ゾーンファイルは、権威サーバー（権威DNSサーバー）に設定され、ゾーンの管理情報や権威サーバーが応答する内容を記述します。以下に、ゾーンファイルの例を示します。


* 権威サーバー（権威DNSサーバー）（JPRS）
* ゾーン（JPRS）
* リソースレコード（JPRS）
* 応答（JPRS）

権威サーバー間でゾーン情報を同期するための手法の一つです。
ゾーン転送は、以下の手順で実行されます。

「example.co.jp」のように、セカンドレベルでドメイン名を登録している組織の種類（属性）を表し、サードレベルに名前（文字列）を登録するタイプのJPドメイン名です。
co.jp（企業）の他には、or.jp（財団法人など）などがあります。登録の際にはローカルプレゼンス（国内住所要件：日本国内に登録者の住所があること）を満たすことが必要になり、法人（組織）のみ登録することができます。更に、一つの法人（組織）が登録できるドメイン名を一つに制限しています（一組織一ドメイン名の原則）。

* 属性型JPドメイン名の種類と対象

組織認証型（OV：Organization Validation）は、証明書の申請者が、証明書に記載のドメイン名の利用権を有することに加え、Webサイトの運営者・運営組織の法的実在性を認証した証明書です。

※ 組織認証型（OV：Organization Validation）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書の種類（JPRSサーバー証明書発行サービス）

国際化ドメイン名は、研究が始まった当初「多言語ドメイン名」と呼ばれていました。
しかし、ドメイン名は「多言語化」されるのではなく、さまざまな文字列が扱えるように「国際化」するのが正しいとして呼び方が変わりました。

都道府県名、政令指定都市名、市区町村名を利用したドメイン名のことです。
組織・個人が登録できる「一般地域型ドメイン名」と、地方公共団体が登録できる「地方公共団体ドメイン名」があります。

EXAMPLE.CHIYODA.TOKYO.JP
東京都千代田区に所在・在住する組織・個人が登録できる一般地域型ドメイン名

METRO.TOKYO.JP
東京都が登録できる地方公共団体ドメイン名

なお、2012年3月31日をもって新規登録の受け付けを終了いたしました。
http://jprs.jp/whatsnew/notice/2011/20110926-geo.html

証明書を発行する認証局の実在を認証するための証明書です。ルートCA証明書からの認証パスを構築するため、証明書を発行する認証局の上位の認証局が発行します。

中間CA証明書は、サーバー証明書と共にWebサーバーにインストールする必要があり、通常、証明書を発行した認証局から入手します。JPRSのサーバー証明書発行サービスでは、中間CA証明書をこちらで公開しています。

* 中間CA証明書について（JPRS）
* サーバー証明書発行サービス（JPRS）

通信を行う二者間に第三者が割り込み、通信を盗聴したり、通信に介入したりする攻撃手法です。
中間者攻撃が成立した場合、通信内容の盗聴、内容の差し替えなど、さまざまな攻撃が可能になります。
DNSにおける中間者攻撃には、クライアントのDNS問い合わせを盗聴し、本物の応答がクライアントに届く前に偽の応答を送り込むことで内容を差し替えるといったものがあります。

DNSにおける中間者攻撃への対策としては、DNSSECやTSIG（Transaction SIGnature）、DNS over TLSなどが挙げられます。

* DNSSEC（ディーエヌエスセック）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* 公開鍵暗号（JPRS）
* DNSにおける秘密鍵のトランザクション認証(TSIG)（JPRS）

DNSにおいて、問い合わせが行われたドメイン名とタイプ（型）に一致するリソースレコードを返す応答です。リソースレコードにはAやAAAA、MXなどさまざまなタイプがありますが、例えば、www.example.jpのIPv4アドレスを問い合わせる場合、指定するタイプはAとなり、www.example.jpのAリソースレコードが応答として返されます。

※通常応答でも、不在応答になるものがあります。DNSでは、応答に含まれるRCODE（Response code）がゼロ（0）のものを通常応答として扱います。ただし、通常応答であっても、問い合わせが行われたドメイン名とタイプ（型）に一致するリソースレコードが応答に含まれない場合があります。Answerセクションが空の通常応答（NODATA）は、不在応答として扱われます。

* 応答（JPRS）
* 不在応答（JPRS）
* リソースレコード（JPRS）
* Aリソースレコード（Aレコード）（JPRS）
* AAAAリソースレコード（AAAAレコード）（JPRS）
* MXリソースレコード（MXレコード）（JPRS）
* ネガティブキャッシュ（negative cache）（JPRS）
* サブドメイン（JPRS）
* DNS Tips：「再帰問い合わせ」と「非再帰問い合わせ」の違いを教えてください
* DNS Tips：DNSの問い合わせと応答について教えてください

データに対し、出自の認証と完全性を検証できるように、データの作成者が付加する情報です。データの利用者は、電子署名を検証することにより、以下の二つを確認できます。

DNSサーバーに対し、知りたい名前と型（例えば「example.jpのIPv4アドレス」や「example.comのIPv6アドレス」）に対応するリソースレコードを問い合わせる行為または、その際に送信されるメッセージです。
DNSの問い合わせには、2種類あります。スタブリゾルバー（DNSクライアント）が名前解決を依頼する「再帰的問い合わせ（recursive query）」と、フルサービスリゾルバー（キャッシュDNSサーバー）が名前解決を実行する「非再帰的問い合わせ（non-recursive query）」（反復問い合わせ（iterative query））です。



* 応答（JPRS）
* リソースレコード（JPRS）
* 再帰的問い合わせ（recursive query）（JPRS）
* 非再帰的問い合わせ（non-recursive query）（JPRS）
* JPRSトピックス＆コラム（No.10）：DNSのしくみと動作原理～インターネットを支え続けるDNS～（JPRS）
* DNS Tips：DNSの問い合わせと応答について教えてください

「example.aomori.jp」、「ドメイン名例.東京.jp」のように、その構造に全国47都道府県の名称を含むJPドメイン名です。
汎用JPドメイン名と同様、登録の際にはローカルプレゼンス（国内住所要件：日本国内に登録者の住所があること）を満たすことが必要になりますが、個人・法人（組織）を問わずいくつでも、どの都道府県名についても登録することができます。また、セカンドレベルとサードレベルにはASCII・日本語のどちらの文字も使用可能です。
都道府県型JPドメイン名の活用により、Webサイトやメールのアドレスから地域とのつながりを直接的に示すことができます。

* 都道府県型.jp
* 都道府県型JPドメイン名について
* 都道府県型JPドメイン名の日本語2LDについて

証明書の申請者が、証明書に記載のドメイン名の利用権を有することを証明する証明書です。

※ ドメイン認証型（DV）の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書の種類（JPRSサーバー証明書発行サービス）

ネットワークやコンピューターを、インターネット上で一意に特定するための識別子の一つです。ドメイン名では、たとえば「example.co.jp」のように名前（ラベル）をドットで連結した文字列によって対象を記述します。ドメイン名は、URL（Webサイトのアドレス）やメールアドレスなどの一部として使われます。
ドメイン名は、階層構造を導入するために「ラベル」と呼ばれる部分的な名前をドット（.）でつないだ形により構成されます。図に示すように、左側のラベルほど階層が深くなるように設計されています。

当初、ドメイン名に使える文字は英数字とハイフンのみでしたが、その後、IDN（国際化ドメイン名）が標準化され、「ドメイン名例.jp」のように日本語を含め世界中のいろいろな文字が使えるようになっています。

* ドメイン名ってなに？（JPRS）
* IDN（国際化ドメイン名）（JPRS）

gTLDが提供する「AGP（Add Grace Period：登録猶予期間）」という制度を乱用し、アクセス数を期待できるドメイン名を選別する行為です。
AGPは、本来は手続き誤りで意図しないドメイン名を登録してしまったユーザーを救済するための制度で、登録後でも一定期間内に取り消しを行えば登録料が課金されません。その点に着目し、一度に大量のドメイン名を登録し、アクセス数の少なかったドメイン名のみを登録猶予期間内で取り消します。
結果として、一般のユーザーが希望するドメイン名が取りづらくなる、大量の登録・取り消しの繰り返しによってレジストリやレジストラのシステム負荷が増大している、などの問題が指摘されています。

ドメイン名の管理権限を持たない第三者が、不正な手段でドメイン名を自身の支配下に置くことです。
ドメイン名ハイジャックに成功した場合、攻撃者が準備した偽サイトにアクセスが誘導され、フィッシング、Webサイト閲覧者に対するマルウェアの注入、クッキーの改変、電子メールの窃盗、SPFレコードの偽装によるなりすましメールの発信など、さまざまな行為に悪用される可能性があります。
代表的なドメイン名ハイジャックの方法には、以下のものがあります。

DNSSEC検証を行う際に、信頼の連鎖の起点となる情報で、バリデーター（※）ごとに設定されます。
DNSの階層構造はルートを起点としているため、通常はルートのDNSKEYリソースレコードまたは対応するDSリソースレコードをトラストアンカーとして指定します。

※DNSSEC検証を行うフルサービスリゾルバー（キャッシュDNSサーバー）やスタブリゾルバー（DNSクライアント）が該当します。

* DNSSEC再入門（3）：キャッシュDNSサーバのDNSSEC対応
* DNSSECを利用するリゾルバーのためのトラストアンカーの設定方法について
* DNSSEC（ディーエヌエスセック）（JPRS）
* リソースレコード（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* ルートゾーン（JPRS）

委任先のネームサーバーの名前を分類するための用語で、以下に示す二つの文脈で使われます（RFC 7719 「In-bailiwick」）。

クライアントからの問い合わせに応じて、ネームサーバーから情報を取り出すことを言います。名前解決の例として、ドメイン名に対応するIPアドレスの検索や、メールサーバー名の検索などがあります。

* JPRSトピックス＆コラム（No.10）：DNSのしくみと動作原理～インターネットを支え続けるDNS（JPRS）
* DNS Tips：名前解決とは何ですか？

日本語JPドメイン名は汎用JPドメイン名及び都道府県型JPドメイン名の一形態で、これまでのASCII文字（半角英数字）に加えて、漢字・平仮名・片仮名の使用が可能なドメイン名です（例：ドメイン名例.jp）。国際化ドメイン名（IDN）の技術を用いています。

* 国際化ドメイン名（IDN）（JPRS）
* 日本語JPドメイン名に関する各種情報提供サイト「日本語.jp」

旧工業所有権仲裁センター。日本弁理士会と日本弁護士連合会が設立した機関であり、知的財産権に関する裁判外の紛争解決を行っています。
JPドメイン名紛争処理手続きを実施する現時点で唯一の機関です。申立人から、他人が登録しているJPドメイン名について登録移転またはその登録の取り消しの請求があった場合、中立公正な1名または3名構成のパネルにその裁定が委ねられます。

「ネームサーバー」は、文脈により二つの意味で使われます。
一つはNSリソースレコードにより指定されるサーバーで、権威サーバー（権威DNSサーバー）を指します（下図*1）。もう一つはDNSのサービスを提供するサーバーで、権威サーバーに加え、フルサービスリゾルバー（キャッシュDNSサーバー）も含みます（下図*2）。

また、後者の意味では「DNSサーバー」という呼称もあります。
DNSサーバーは、DNSプロトコルによるサーバー、すなわち権威サーバーに加え、フルサービスリゾルバーも含む呼び方です（下図*2）。インターネットへの接続の際、「DNSサーバーのIPアドレスはxxx.xxx.xxx.xxxです」という形でスタブリゾルバー（DNSクライアント）に設定を行うことがありますが、その場合のDNSサーバーは一般的にフルサービスリゾルバーを指します。


* 権威サーバー（権威DNSサーバー）（JPRS）
* プロトコル（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* JPRSトピックス＆コラム（No.10）：DNSのしくみと動作原理～インターネットを支え続けるDNS～（JPRS）

DNSにおいて、検索対象が存在しなかったことを示す不在応答のキャッシュです。
DNSでは、通常応答と同様に不在応答もキャッシュし、同じドメイン名やリソースレコードに対する問い合わせを抑制するように作られています。このキャッシュを「ネガティブキャッシュ」と呼びます。

* リソースレコード（JPRS）
* 名前解決（Name Resolution）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* DNS Tips：キャッシュとネガティブキャッシュって何ですか？
* RFC 2308：Negative Caching of DNS Queries (DNS NCACHE)

一つのIPアドレスに対して複数のドメイン名を設定することをバーチャルドメインといいます。一つのIPアドレスに複数のドメイン名が割り当てられるため、DNSの正引きと逆引きが一致しなくなります。

1台のサーバーで複数のドメイン名を運用する技術のことです。
通常ならば、Webサーバーやメールサーバーを運用するためにはドメイン名の数以上のサーバーが必要となりますが、バーチャルホストを利用することでサーバーの数を減らすことができます。

元データから、ハッシュ関数と呼ばれるあらかじめ定められた計算手順により求められた値です。ダイジェスト値とも呼ばれます。

ハッシュ値を求めるハッシュ関数(※)には、元データが1ビットでも異なれば大きく異なるハッシュ値が生成される（同じハッシュ値になることが実用上ない）方式が選ばれます。
また、ハッシュ関数が持つ一方向性関数（逆関数の計算が不可能または極めて困難）という性質により、ハッシュ値から元データを復元することはできません。
そうした特徴から、パスワードの保管や、データ送受信における完全性（欠落などのないこと）の確認などで利用されます。

以下に、受信者が受け取ったデータが送信者側の元データと同じものかを確認するために、ハッシュ値を利用する例を示します。
送信者から受け取ったハッシュ値と送られてきたデータから生成したハッシュ値が一致すれば、通信途中でデータの欠落が無かったことを確認できます。



※ たとえば、DNSSECではDSリソースレコードの生成においてハッシュ関数SHA-256を使用できます。この際生成されるハッシュ値の長さは、256ビット（32バイト）の固定長になります。

* DNSSEC（ディーエヌエスセック）（JPRS）
* DSリソースレコード（ディーエスリソースレコード）（JPRS）

「example.jp」のように、セカンドレベルに名前（文字列）を登録するタイプのJPドメイン名です。
登録の際にはローカルプレゼンス（国内住所要件：日本国内に登録者の住所があること）を満たすことが必要になりますが、個人・法人（組織）を問わずいくつでも登録することができます。また、従来のASCII文字（半角英数字）に加えて、漢字・ひらがな・カタカナを用いた日本語ドメイン名を使えることも大きな特長です。

DNSにおいて、スタブリゾルバー（DNSクライアント）　からの名前解決の依頼（要求）に応じて名前解決を実行するための問い合わせです。通常、問い合わせ元はフルサービスリゾルバー（キャッシュDNSサーバー）で、問い合わせ先は権威サーバー（権威DNSサーバー）です。

DNSでは、「再帰的問い合わせ」と「非再帰的問い合わせ（反復問い合わせ）」という二種類の問い合わせによって名前解決が行われます。

* DNS Tips：「再帰問い合わせ」と「非再帰問い合わせ」の違いを教えてください
* DNS Tips：DNSの問い合わせと応答について教えてください
* 名前解決（Name Resolution）（JPRS）
* 再帰的問い合わせ（recursive query）（JPRS）
* 応答（JPRS）
* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）

正規のドメイン名を用いたアクセスの名前解決を乗っ取り、攻撃者が準備した不正なWebサイトに利用者を誘導することで、認証情報や機密情報を盗むことを目的とした詐欺の一種です。
攻撃者が名前解決を乗っ取る方法の例として、ドメイン名ハイジャックやDNSキャッシュポイズニングなどが挙げられます。

* ICANN Acronyms and Terms（ICANNによるファーミングの解説）
* フィッシング（phishing）（JPRS）
* ドメイン名ハイジャック（JPRS）
* DNSキャッシュポイズニング（JPRS）

証明書の発行時に申請者がドメイン名の利用権を持っていることを確認するための方法です。

認証用のファイルを証明書を設定するWebサーバーに設定いただき、そのファイルを認証局が確認する認証方法です。

※ ファイル認証の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* 認証方法について（JPRSサーバー証明書発行サービス）

DNSにおいて、問い合わせが行われたドメイン名とタイプ（型）に一致するリソースレコードが存在しないことを示す応答です。そのドメイン名を管理する権威サーバー（権威DNSサーバー）は該当するリソースレコードが存在しない場合、以下の2種類の不在応答のいずれかを返します。

ゾーン転送の転送元となる権威サーバー（権威DNSサーバー）です。
権威サーバーは、多重化することで負荷分散や冗長化を図ることができます。多重化する際には、扱うゾーンデータのマスターを管理する権威サーバーを用意し、そのゾーンデータをコピーして別の権威サーバーを動かします。この時、コピー元の権威サーバーが「プライマリサーバー」で、コピー先の権威サーバーが「セカンダリサーバー」となります。


* DNS Tips：プライマリ、セカンダリの使い方を教えてください
* 権威サーバー（権威DNSサーバー）（JPRS）
* ゾーン（JPRS）
* セカンダリサーバー（スレーブサーバー）（JPRS）

フルサービスリゾルバー（キャッシュDNSサーバー）がルートゾーンのネームサーバー情報（※）をルートサーバーに問い合わせ、受け取った情報を使って自身の保持するルートネームサーバー情報を更新することです。
ルートサーバーのIPアドレスが追加・変更された場合、フルサービスリゾルバーの管理者がそれぞれのネームサーバー情報を手動で変更します。しかし、一部のフルサービスリゾルバーの管理者はこうした変更を行わず、新しいIPアドレスが参照されない場合があります。プライミングを実装したDNSソフトウェアを利用することで、このような場合でもルートサーバーのIPアドレス変更が反映されるようになります。
現在普及しているフルサービスリゾルバーの多くは、プライミングクエリ（ルートゾーンに対するNSリソースレコードの問い合わせ（ルート“.”のNS））を実行するように実装されています。

※ 現在のNSリソースレコードセット（RRset）とルートサーバーへのアクセスに必要なIPアドレスの一覧

* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 名前解決（Name Resolution）（JPRS）
* ルートゾーン（JPRS）
* ルートサーバー（root servers）（JPRS）
* ネームサーバー（DNSサーバー）（JPRS）
* NSリソースレコード（JPRS）
* RRset（リソースレコードセット）（JPRS）
* BIND（バインド）（JPRS）
* Unbound（アンバウンド）（JPRS）

スタブリゾルバー（DNSクライアント）から送られる「名前解決要求」を受けて、他の権威サーバー（権威DNSサーバー）に対して「非再帰検索（反復検索）」という形で問い合わせを行い、その結果をスタブリゾルバーに応答として返すリゾルバーです。



ネームサーバーから情報を取り出し、クライアントに応答として返すもの を「リゾルバー」と呼びます。リゾルバーのうち、「リカーシブモード」と呼ばれる動作を行い、内部にキャッシュを持っているものを「フルサービスリゾルバー」と呼びます。リカーシブモードとは、DNSクエリを受信した際に、キャッシュの内容から答えるか、他の権威サーバー群に問い合わせを行うモードです。
フルサービスリゾルバーは、名前解決をする際、同じ問い合わせを何度も繰り返すという非効率を避けるために、名前解決の際に得られた情報を内部にキャッシュして再利用します。
なお、「キャッシュDNSサーバー」がフルサービスリゾルバーを示す用語として使われる場合がありますが、厳密にフルサービスリゾルバーのみを示す用語とはならないことに注意が必要です。その理由は、性能向上を図るために、権威サーバーにおいても自身のキャッシュを使用するソフトウェアが存在することによります。

* 名前解決（Name Resolution）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 応答（JPRS）
* 問い合わせ（JPRS）
* JPRSトピックス＆コラム（No.10）：DNSのしくみと動作原理～インターネットを支え続けるDNS～（JPRS）

必要な規則・習慣・手順などを文章化し、体系的にまとめた取り決めのことです。コンピューターの世界では、コンピューター同士で通信をする際の取り決めを「通信プロトコル（または「プロトコル」）」と呼びます。
通信プロトコルには、実際にどのような状況において、どのような型のデータを、どのような順番で送るといったことが具体的に記され、通信を円滑に進める際に重要な役割を担います。インターネットにおける代表的な通信プロトコルの種類には、通信規格の「IP」や「TCP」、「UDP」、Webコンテンツの送受信に用いられる「HTTP」、メールの配送に用いられる「SMTP」などがあります。

* JPNIC用語集 プロトコル関連（JPNIC）

TCP/IPを使った通信においてサービスを識別するための番号で、以下に示す三つに分類されます。

サーバーやサーバーの一部を貸し出すサービスのことを一般に「ホスティングサービス」と呼びます。Webサーバーやメールサーバーの設備を独自に持たない場合でも、ホスティングサービスを利用することでWebサイトの運営などが行えるようになります。

ネットワークに接続されているルーター、パソコン、サーバーなどのすべての機器それぞれのことをホストといいます。

1998年6月5日に米国商務省が発表した文書「インターネットの名前及びアドレスの管理」の通称です。同年1月の「グリーンペーパー」に対するさまざまな意見の一部が反映されており、ドメイン名やIPアドレス管理のための国際的な非営利法人の設置を含む、インターネット資源の管理についての提案が行われています。この「ホワイトペーパー」がICANNの設立につながっていきました。

インターネット上で相手に電子メールを送るための「住所」のことです。
「info@jprs.jp」のように表記し、「@」記号の前が個人を識別するユーザー名、「@」記号の後ろがドメイン名になります。

証明書の発行時に申請者がドメイン名の利用権を持っていることを確認するための方法です。

申請時に指定したメールアドレス宛に、認証メールを送付します。
認証メールに記載されている案内にしたがって、手続きを進める認証方法です。

※ メール認証の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* 認証方法について（JPRSサーバー証明書発行サービス）

汎用JPドメイン名を導入する際、導入時の紛争・混乱を低減するために事前登録申請制度を実施しました。このうち、既に属性型JPドメイン名として登録済みのJPドメイン名、商標・商号などの権利者、個人のフルネームの申請を受け付けた期間が優先登録申請期間です。サイバースクワッティングなどによる紛争を未然に防止することに貢献しました。

すべての有効なドメイン名が、インターネットにつながるアプリケーション、デバイス、システムによって矛盾なく受け入れ、検証、保存、処理、表示されるべきであるという考え方のことです。
ユニバーサルアクセプタンスの実現により、世界中の利用者が例外なく、それぞれの言語でインターネットを問題なく使えるようになることが期待されます。

* Universal Acceptance - ICANN
* ICANN（アイキャン）（JPRS）
* ドメイン名（Domain Name）（JPRS）
* 国際化ドメイン名（Internationalized Domain Name: IDN）（JPRS）
* ドメイン名や電子メールアドレスを扱う技術者の皆様へ ～ユニバーサル・ アクセプタンス クイックガイド日本語訳公開～

ドメイン名の登録希望者が登録できない文字列を予約ドメイン名といいます。
JPドメイン名では、国際的な政府間機関、都道府県名、行政・司法・立法に関連する名称、インターネットの管理に関連する組織名や日本語ドメイン名のASCII互換表現に混乱を及ぼすもの、普通名詞など、ドメイン名の登録希望者が登録できない文字列を予約ドメイン名として定めています。

DNSサーバーに対するDDoS攻撃手法の一つです。DNSの問い合わせ名にランダムなサブドメインを付加することでフルサービスリゾルバー（キャッシュDNSサーバー）のキャッシュ機能を無効化し、攻撃対象となる権威DNSサーバーに問い合わせを集中させることにより、権威DNSサーバーやフルサービスリゾルバーをサービス不能の状態に陥らせます。
「Water Torture（水責め）」という呼び名は、2014年にこの攻撃について報告した米国Secure64 Software社が、かつて中国などで行われていた「Chinese Water Torture（中国式水責め）」を命名の由来としたことによります。
ランダムサブドメイン攻撃では、問い合わせ元のIP アドレスを詐称する必要がなく、攻撃に用いられる問い合わせと通常の問い合わせとの区別がつかないことから、根本的な対策を実施しにくいという問題があります。また、ISPの顧客が使っているホームルーターに欠陥がある場合、ISPのフルサービスリゾルバーにACL（Access Control List）が導入されていても十分な防御ができません。現時点における代表的な攻撃対策には、

・本来必要なアクセス制限がされておらず、外部から不正使用可能な状態になっているDNSサーバー（オープンリゾルバー）を減らしていく
・欠陥を持つホームルーターなどの機器を悪用されないようにするため、ISP 側でIP53B（Inbound Port 53 Blocking）を実施する
・フルサービスリゾルバーにおいて、フィルタリングや問い合わせレートによる制限などの攻撃の影響を緩和する仕組みを導入する
・監視の強化や、攻撃を検知する仕組みを導入する

といったものがあり、関係者による対応が進められています。

*JPRS トピックス＆コラム（No.21）：Bot経由でDNSサーバーを広く薄く攻撃～DNS水責め攻撃の概要と対策～（JPRS）

フルサービスリゾルバー（キャッシュDNSサーバー）が名前解決の際に、キャッシュの内容から答えるか、必要に応じて他の権威サーバー（権威DNSサーバー）に問い合わせを行う形式（モード）です。リカーシブモードで動作し、キャッシュを持つリゾルバーをフルサービスリゾルバーと呼びます。
DNSにおいてフルサービスリゾルバーは、スタブリゾルバー（DNSクライアント）からの名前解決要求（再帰検索要求）を受け付ける役割を担います。フルサービスリゾルバーは、名前解決をする際に、権威サーバーに同じ問い合わせを何度も繰り返すという非効率を避けるため、名前解決の際に得られた情報を内部にキャッシュして再利用します。


* フルサービスリゾルバー（キャッシュDNSサーバー）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* 問い合わせ（JPRS）
* 応答（JPRS）
* 名前解決（Name Resolution）（JPRS）

DNSにおいて、ドメイン名に関連付けられた情報（レコード）のことです。リソースレコードにはさまざまな種類があり、それぞれに役割と記述のルールが決められています。省略形として単に「レコード」と書く他、「RR」や「RRs」が使われます。
リソースレコードに関する知識は、ゾーンファイルの作成やDNSの動作を確認するといった場面で必要となります。リソースレコードは、ゾーンファイル内においてはテキスト形式で表現され、通常は1行で記述されます。IPv4アドレスやIPv6アドレスの両方がある時のように、特定のドメイン名に複数の情報がある時には、それぞれ、そのためのリソースレコードを使って記述されます。リソースレコードの基本的な構造を、以下の図で示します。

TTLが省略された場合は、前方で指定された「$TTL制御ステートメント」の値が適用されます。クラスは、通常「IN（the Internet systemの意味）」が使われます。代表的なリソースレコードのタイプは、以下の通りです。各リソースレコードの詳細については、当該項目や関連するRFCなどを参照してください。

リポジトリは、CA（Certificate Authority）証明書及び証明書失効リスト（CRL）などを格納し公表するデータベースのことです。


※ リポジトリの解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* JPRSサーバー証明書認証局証明書ポリシー（Certificate Policy） （JPRSサーバー証明書発行サービス）

システムやWebブラウザーがトラストアンカーとして利用する、ルートCA証明書を格納する場所です。

多くのシステムやWebブラウザーでは、利用者がルートCA証明書を追加・削除できます。
以下に、Windows 10において、ルートCA証明書ストアを表示した結果を示します。


* サーバー証明書発行サービス（JPRS）

DNSにおける階層構造の頂点となるルートゾーンを提供する権威DNSサーバー群のことです。米国で設立された民間の非営利法人であるICANN（Internet Corporation for Assigned Names and Numbers）が管理・運用の責任を負い、各ルートサーバーを担当する組織間における緩やかな連携の下、各組織が独自にサーバーの運用を行っています。ルートサーバーはアルファベット順にAからMまでの13システムが稼働しており、AとJを除き、それぞれが異なる組織によって運用されています（表）。WIDEプロジェクトとJPRSは、ルートサーバーの一つであるMルートサーバーを共同運用しています。
ルートサーバーは、DNSにおける名前解決の起点となる重要なサーバーです。そのため、信頼性や応答性能の向上、障害発生時の対策などを目的としたIP Anycast技術の導入が進められており、550を超えるサーバーが稼働しています（2017年10月現在）。



* root-servers.org
* ルート（JPRS）
* JPRS トピックス＆コラム（No.6）：インターネットの根幹を支える～ルートサーバーの状況とMルートサーバー～（JPRS）

DNSにおける階層構造の頂点となるゾーンのことです。ルートゾーンは各TLDの委任情報（委任先の権威DNSサーバーに関する情報）を保持しており、DNSの名前解決において起点となる重要な役割を果たします。ルートゾーンのゾーンデータを持つ権威DNSサーバーを、「ルートサーバー」と呼びます。
ルートゾーンの管理は、IANA（Internet Assigned Numbers Authority）の重要な役割の一つです。たとえば、ルートゾーンには「JPゾーンの管理は、ネームサーバーであるa.dns.jp、b.dns.jp、c.dns.jp、d.dns.jp、e.dns.jp、f.dns.jp、g.dns.jpに委任している」、「それぞれのネームサーバーのIPアドレス」という委任情報を格納しています。

* 委任（JPRS）
* IANA（アイアナ）（JPRS）
* 権威サーバー（権威DNSサーバー）（JPRS）
* Root Zone Database（IANA）
* Delegation Record for .JP

個々の登録者からドメイン名の登録申請を受け付けたり、登録者からの要求に基づいてドメイン名のデータベース（レジストリデータベース）への情報登録を行う機関がレジストラです。
レジストリは一つのトップレベルドメインにつき一つですが、レジストラは複数存在することが一般的です。これにより、サービス面や価格面で競争が働く仕組みになっています。

ドメイン名やIPアドレス、AS番号といったインターネット資源の登録・割り当てを担当する組織（登録管理機関）のことです。ドメイン名のレジストリと、IPアドレスやAS番号のレジストリを担当する組織は異なる場合があります。
ドメイン名のレジストリは、登録済みドメイン名の情報と登録者情報を管理しています。ドメイン名を必要としているユーザーは、希望する文字列を決め、ドメイン名レジストリに登録申請を行います。レジストリは申請を受け取ると、登録規則を満たしているかを審査し、その名前が未登録であることを確認します。その後、申請を受理し、登録済みのドメイン名としてレジストリデータベースに追加することにより、そのドメイン名の一意性を保証します。
IPアドレスやAS番号のレジストリは、未分配のIPアドレスブロックと分配済みのIPアドレスブロックの両方を、「一意性」「登録」「経路集成」「節約」「公平性」という五つの原則に従って管理します。IPアドレスの分配にあたっては、管理原則に則った運用が行われるか、希望するIPアドレスの数が適切かなどをあらかじめ審査し、必要な分配量を決定します。そして、分配したアドレスをデータベースに登録管理することにより、そのアドレスの一意性を保証します。
ドメイン名のレジストリは、ドメイン名をIPアドレスに変換（正引き）するための権威サーバー（権威DNSサーバー）を運用し、IPアドレスやAS番号のレジストリは、IPアドレスをドメイン名に変換（逆引き）するための権威サーバーを運用します。
日本を表すTLD（トップレベルドメイン）である「jp」のレジストリは株式会社日本レジストリサービス（JPRS）であり、日本国内に割り振られたIPアドレスやAS番号のレジストリは一般社団法人日本ネットワークインフォメーションセンター（JPNIC）です。

* 権威サーバー（権威DNSサーバー）（JPRS）
* 正引き（JPRS）
* 逆引き（JPRS）
* TLD（トップレベルドメイン）（JPRS）
* JPNIC（ジェーピーニック）（JPRS）
* 日本におけるインターネット資源管理の歴史～ドメイン名とIPアドレスを中心とした日本のインターネットの歩み～第1章 資源管理とレジストリ（JPNIC）

ドメイン名の登録情報（登録者の氏名、組織名、ネームサーバー設定など）が意図せず書き換えられることを防ぐために対象ドメイン名の情報変更を制限する、レジストリが提供するオプションサービスの一つです。

* レジストリロックサービス（JPRS）
* レジストリ（JPRS）

ドメイン名の登録者を、国内に住所を有する組織や個人に限定する原則です。ローカルプレゼンスを採用するか否かは、それぞれのトップレベルドメイン（TLD）レジストリの登録ポリシーに委ねられます。
JPドメイン名は、日本に割り当てられた国別トップレベルドメイン（ccTLD）であり、日本のインターネットユーザーのために提供するドメイン名であるという位置付けを明確にするために、登録者は日本に住所を有する組織や個人であることを登録の際の要件としています。

* JPドメイン名規則一覧（JPRS）

「*.example.jp」のように、コモンネームの一番左のラベルにアスタリスク（*）を指定したサーバー証明書です。

ワイルドカード証明書は「www.example.jp」「login.example.jp」「member.example.jp」のように、アスタリスクと同一階層のサブドメインのみが異なるすべてのサーバーにインストールできます。

JPRSの提供するワイルドカード証明書では、「*.example.jp」の証明書を「example.jp」のようにアスタリスク（*）を除いたホスト名のサーバーでも利用できます。そのため、1枚のワイルドカード証明書でこれらのサーバーすべてをHTTPS化でき、コストや作業工数を削減することができます。

※ ワイルドカード証明書の解説は現在準備中です。記述内容は、以下の参考リンクより抜粋したものです。

* ワイルドカード証明書について（JPRSサーバー証明書発行サービス）