JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
本内容は、会合写真を加えたWebページからもご覧いただけます。 https://jprs.jp/related-info/event/2022/0830IETF.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2022/08/30━ ◆ FROM JPRS 増刊号 vol.205 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ 第114回IETF Meeting報告 ～IETF全般、第38回DNS-OARC Workshop、DNS関連WGにおける話題～ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2022年7月23日から29日にかけ、第114回IETF Meeting（以下、IETF 114）が、 米国フィラデルフィアの現地会場とオンラインによるハイブリッド形式で開催 されました。 今回のFROM JPRS増刊号では、IETF 114の状況に加え、その直後の7月30日から 31日にかけて同じ現地会場で開催された第38回DNS-OARC Workshop（以下、 OARC 38）から、FROM JPRS編集局が注目した興味深い話題についてもお伝えし ます。 ・開催の状況 ・IETF全般の話題から - 次々回のIETF 116は横浜で開催 - DNS-directorateの新設に伴うボランティアの募集 - IETFプロトコルバッジ・IETFサポーターバッジのライセンス条項制定 - edmプログラムの状況 ・OARC 38の話題から - nsec3-guidanceの影響と次回のDNS flag dayの提案 - オープンソースDNSベンダーからの状況報告 ・IETF 113以降に発行されたDNS関連のRFC - 大規模権威DNSサーバー運用者のための考慮事項（RFC 9199） - Oblivious DNS Over HTTPS（ODoH）の仕様（RFC 9230） - DNS over QUIC（DoQ）の仕様（RFC 9250） - リソースレコード処理に関する実装のアンチパターン（RFC 9267） - NSEC3パラメーター設定のガイダンス（RFC 9276） ・DNS関連WGの状況 - dnsop WGの状況 - dprive WGの状況 - add WGの状況 ・次回のIETF Meetingについて ◇ ◇ ◇ ■開催の状況 IETF 114には、世界各地から1,400人以上が参加しました。会合終了後の公式 発表によると現地参加者が622人、オンライン参加者が803人であったとのこと で[*1]、現地参加者の比率はIETF 113の約22%（314人）から、約44%に増加し ました。 [*1] IETF | Past meetings https://www.ietf.org/how/meetings/past/ 会合の時間は、開催地であるフィラデルフィアの時間帯（UTC-4）でスケ ジュールされました。 ■IETF全般の話題から ▼次々回のIETF 116は横浜で開催 IETF 114の全体会議（Plenary）で、次々回のIETF 116が2023年3月25日から 31日にかけ、横浜市のパシフィコ横浜で開催されることが発表されました[*2]。 [*2] 既にIETF 116の公式Webページが公開されています。 IETF | IETF 116 https://www.ietf.org/how/meetings/116/ 日本でのIETF Meetingの開催は、2002年のIETF 54、2009年のIETF 76、2015年 のIETF 94に続き、4回目となります。IETF 116は過去3回と同様、WIDE Projectがホストとなり開催されます。 ▼DNS-directorateの新設に伴うボランティアの募集 IETFには各分野の専門家の立場から提案をレビューする、Directorateという 仕組みがあります[*3]。 [*3] IETF | IETF Directorates https://www.ietf.org/about/groups/directorates/ 今回、DNS関連の各WGの冒頭でInternet Area（int）とOperations and Management Area（ops）のエリアディレクター（AD）[*4]から、IESG[*5]と DNS関連の四つのWG（add・dnsop・dnssd・dprive）のチェアが、IETF 114の開 催後に「DNS-directorate」を新設することに合意した旨が参加者に伝えられま した。 [*4] IETFの標準化作業はその内容により七つのエリアに分類され、各エリア にADが任命されます。ADは、エリア全体の方向性の決定やエリアに属す るワーキンググループ（WG）チェアの任命など、エリアの管理全般に対 する責任を負います。 [*5] Internet Engineering Steering Groupの略称。IETFのWGが所属する各エ リアのADにより構成され、IETFの活動と標準化プロセスの技術管理を担 当します。 DNSはインターネットの基盤技術の一つであり、DNS関連以外のWGの提案の中に も、DNSに関する内容が含まれることがあります。DNS-directorateはそれらの 提案の内容について、DNSの専門家の立場から早い段階でレビューするための 仕組みとして提案されたものです。 発表では2022年9月1日までに実施する次のステップとして、提案のレビューを 担当する小グループのボランティアと、毎週のチェックを担当する2名の事務 局を募集する旨が呼び掛けられました。 各WGの参加者からは、「新しいアイディアの提案を萎縮させるようにはしない で欲しい」「レビューで『DNSでこれを行うな』と言って良いか」などのコメン トがあり、後者についてはADから良いとする回答がありました。 ▼IETFプロトコルバッジ・IETFサポーターバッジのライセンス条項制定 IETFでは、特定のプロトコルの標準化活動への関与や、そのプロトコルを実装・ サポートしていることを示す「IETFプロトコルバッジ」と、IETFの活動を支援 していることを示す「IETFサポーターバッジ」を公開しています[*6]。 [*6] IETF | IETF Badges https://www.ietf.org/badges/ 今回のPlenaryで、これらのバッジの利用に関するライセンス条項を制定した 旨が発表されました[*7]。 [*7] ライセンス条項は、以下のURLで公開されています。 Licenses - IETF Trust https://trustee.ietf.org/assets/licenses/ ライセンス条項には、以下の内容が記述されています。Webサイトや印刷物な どでバッジを使う場合、当該ライセンス条項を遵守する必要があります。詳細 につきましては、リンク先のライセンス条項をご覧ください。 ・許可される使い方 - IETFの標準化活動への関与を示す - 製品・サービスにおいて、当該プロトコルのサポートを示す - IETFまたはその活動への支援を示す ・禁止される使い方 - バッジの形式・大文字小文字（capitalization）・比率・色を変更する - バッジの短縮・省略・改変、及び結合商標の一部として使用する - 製品・サービスの出自について、誤解を生じさせる - IETFの承認・後援がある旨の印象を与えたり、誤認させたりする - IETFまたは関連団体の活動を誤解させたり、軽蔑的に扱ったりする ▼edmプログラムの状況 IETF 114の期間中にIAB[*8]が主催する形で、edmプログラムのミーティングが 開催されました。 [*8] Internet Architecture Boardの略称。IABはIETFに設置された委員会で あり、ISOCの諮問機関の役割も担っています。IABはIETFの活動方針とイ ンターネット標準化プロセスを監督し、RFC編集者を任命します。また、 IETFのプロトコルパラメーターレジストリの管理も担当します。 edmは「Evolvability, Deployability, & Maintainability」に由来しており、 IETFが標準化するプロトコルの進化・普及・保守における戦略を策定・分析す る文書の作成に取り組むために創設された、IABのプログラムです[*9]。 [*9] Evolvability, Deployability, & Maintainability (edm) https://datatracker.ietf.org/group/edm/about/ edmでは、プロトコル拡張における設計上の考慮事項についてまとめたRFC 6709[*10]の更新・拡張を始めとする文書の作成に取り組んでいます。edmには IESGのメンバーと、実装を支援するツールチームが含まれています。 [*10] RFC 6709: Design Considerations for Protocol Extensions https://www.rfc-editor.org/info/rfc6709 今回のミーティングでは、IABが作成を進めている「The Harmful Consequences of the Robustness Principle（参考訳：堅牢性の原則の有害な 結末）[*11]」の状況が共有されました。本文書にはインターネットにおいて長 年重要視されてきた「送信では厳密に・受信では寛容に」という堅牢性の原則 がプロトコルのエコシステムに悪影響を与えた旨が書かれており、この原則は 長期的な観点では有害であり、回避すべきであることが示されています。 [*11] draft-iab-protocol-maintenance-08 - The Harmful Consequences of the Robustness Principle https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/ edmの活動はIETFの標準化活動の方針そのものに影響を与えるものであり、今後 の動向が注目されます。 ■OARC 38の話題から DNS-OARC[*12]はDNSのセキュリティ・安定性・理解の向上を目的とした、非営 利の会員組織です。JPRSは、2007年からDNS-OARCのメンバーとなっています。 [*12] Home | DNS-OARC https://www.dns-oarc.net/ DNS-OARCは情報交換を目的としたワークショップを定期的に開催しています。 今回のFROM JPRS増刊号ではOARC 38のプログラムの中から、DNSの運用に影響 する二つの話題をご紹介します。 ▼nsec3-guidanceの影響と次回のDNS flag dayの提案 10年以上に及ぶ大規模な運用経験の蓄積から、当初最適と考えられていた DNSSECの運用パラメーターの見直しが行われています。JPRSの米谷嘉朗が 「Are we ready for nsec3-guidance?」と題し、現状における最良の慣行 （Best Current Practice：BCP）RFCとして発行される予定のNSEC3パラメー ターの設定に関するガイダンス（nsec3-guidance）[*13]が運用に与える影響 と、その影響を回避するためにTLDの権威DNSサーバー・DNSSEC検証を実施する フルリゾルバー（バリデーター）・DNSコミュニティが実施すべき対応案につ いて説明しました。 [*13] RFC 9276・BCP 236として発行されました。 NSEC3の検証では外部からゾーン列挙[*14]を行いにくくするため、ハッシュ計 算を実行します。nsec3-guidanceではハッシュ計算の過剰な繰り返しによりバ リデーターのパフォーマンスが低下することを懸念し、権威DNSサーバーの設 定推奨値とバリデーターの動作について、以下のように定めています。 ・権威DNSサーバーで設定する繰り返し回数を0、ソルト[*15]を空とする （MUST） ・バリデーターは設定されている繰り返し回数が0より大きい場合、安全で ない（Insecure）、またはDNSSEC検証失敗（SERVFAIL）応答を返してよい （MAY） [*14] DNSSEC 関連情報 ～よくある質問～ / JPRS https://jprs.jp/dnssec/faq.html#q16 [*15] 元データを推測しにくくするため、ハッシュ値を計算する際に入力に付 加するランダムなデータのことです。 米谷は、2022年7月9日時点において1,148のTLDが1以上の繰り返し回数を設定し ており、nsec3-guidanceのRFCが発行され、バリデーターがSERVFAIL応答を返す ように設定された場合、TLDレベルでの大規模なDNSSEC検証エラーが発生する可 能性がある旨を示しました。 そして、その可能性を低減するため、それぞれの関係者が実施すべき対応案と して、以下を示しました。 ・TLDの権威DNSサーバーの関係者 - できるだけ速やかに、NSEC3パラメーターの設定をnsec3-guidanceが推 奨する内容に変更する ・バリデーターの関係者 - 本件においてInsecure応答やSERVFAIL応答を返すのはオプションであり、 導入は慎重に検討する その後、米谷から参加者に対し、本件は次回のDNS flag day[*16]の候補となり 得るのではないかという旨を提案しました。参加者からは「本件はDNSソフトウェ アベンダーだけが対応すればよいものではない」、「バリデーターの段階的な 移行を促すにはDNS flag dayは有用であろう」といった意見があり、提案に対 する関係者の認識を向上できました。 [*16] DNSに関する変更を歩調を合わせてグローバルに実施する日として、準 備を進めているDNS関係者により名付けられたイベントです。DNS flag dayはこれまで、2019年と2020年に実施されています。 DNS flag day https://dnsflagday.net/ 本件についてはDNS flag dayの実施時期・段階的な移行などについて、議論を 継続していく予定です。 ▼オープンソースDNSベンダーからの状況報告 「Open-source DNS Vendors Panel」において、オープンソースDNSソフトウェ アを開発している以下の4ベンダーから、それぞれの開発状況が発表されまし た。 ・CZ.NIC（Knot DNS・Knot Resolver） ・ISC（BIND） ・NLnet Labs（NSD・Unbound） ・PowerDNS.COM BV（PowerDNS Authoritative Server・PowerDNS Recursor） 各ベンダーからは各ソフトウェアにおける最近の開発状況と、カタログゾーン やZONEMD[*17]リソースレコード（RR）、エラーコードの拡張などといった新し い標準仕様の実装予定が、ロードマップとして示されました。 [*17] RFC 8976で定義される、DNSゾーンデータのメッセージダイジェストを保 持するためのリソースレコードです。 なお、RFC 9250として標準化されたDNS over QUIC[*18]への対応については積 極的なベンダーと慎重なベンダーがあり、慎重なベンダーは現時点において QUICのライブラリが十分に整っていないことをその理由に挙げていました。 [*18] DNS over QUICの概要については、本稿の「DNS over QUIC（DoQ）の仕 様」の内容をご参照ください。 詳細については、OARC 38公式ページで公開されている資料をご参照ください。 ▽BINDにおける委任情報の取り扱い変更に関する検討 本パネルにおいてISCから、BINDにおける委任情報（NS RR）の取り扱いを、現 在の委任先（子）の設定内容を優先する方式から、委任元（親）の設定内容を 優先する方式[*19]に変更することを検討している旨が発表されました。 [*19] RFC 2181で定められる方式では、子のNS RRの設定内容が優先されます。 なお、米国Akamai（旧Nominum）のCacheServeのように、名前解決にお いて子のNS RRを使わない実装も知られています。 本件はDNSの動作と運用に大きな影響を及ぼすため、ISCは公開の場で意見を募 集しています[*20]。 [*20] Consider parent-centric delegations (#3311) ・ Issues ・ ISC Open Source Projects / BIND ・ GitLab https://gitlab.isc.org/isc-projects/bind9/-/issues/3311 ■IETF 113以降に発行されたDNS関連のRFC 前回のIETF 113以降に発行された、DNS関連のRFCの内容をご紹介します。 ▼大規模権威DNSサーバー運用者のための考慮事項 ・RFC 9199: Considerations for Large Authoritative DNS Server Operators （Informational: draft-moura-dnsop-authoritative-recommendations） RFC 9199は、TLDの権威DNSサーバーのような大規模な権威DNSサーバーの運用 者が考慮すべき事項を、これまでの調査研究の結果に基づく形でまとめたもの です。本RFCはIETFのWGで標準化されたものではなく、情報提供 （Informational）として発行されています。 本RFCでは運用者の考慮事項として、以下の6項目を挙げています。 1. すべての権威DNSサーバーに、IP Anycast[*21]を展開する 2. 経路制御の最適化は、サーバーのロケーション数や多様性より重要であ る 3. 設計を改善するため、IP Anycastの集水域マップ（Catchment Maps） [*22]を収集する 4. DDoS攻撃対策において、二つの戦略（回避・緩和と吸収）を採用する 5. TTLを、可能な限り長くする 6. 親子間のTTLの違いを考慮する [*21] IP Anycastの詳細は、JPRS用語辞典をご参照ください。 https://jprs.jp/glossary/index.php?ID=0108 [*22] IP Anycastの各サーバーノードに、どの地域・ネットワークからアクセ スされているかを示すマップです。 ▼Oblivious DNS Over HTTPS（ODoH）の仕様 ・RFC 9230: Oblivious DNS over HTTPS （Experimental: draft-pauly-dprive-oblivious-doh） RFC 9230は、利用者のプライバシーを保護するために開発されたOblivious DNS over HTTPS（ODoH）の仕様を定義します。本RFCはIETFのWGで標準化され たものではなく、実験（Experimental）として発行されています。 ODoHではDNSクライアントとリゾルバーの間にプロキシを追加し、クライアン トとリゾルバーがエンドツーエンドでDNSデータを暗号化・復号することで、 利用者の問い合わせ元IPアドレスとDNS問い合わせ内容を同時に入手できない ようにします[*23]。 [*23] ODoHの概要については、2021年開催のInternet Week 2021における、 JPRSのランチタイムウェビナー資料もご参照ください。 DNSの「明日のカタチ」について考える～ランチのおともにDNS～ https://jprs.jp/tech/material/iw2021-lunch-l1-01.pdf#page=40 ODoHは、AppleのiCloud Private Relayで採用されています。 ▼DNS over QUIC（DoQ）の仕様 ・RFC 9250: DNS over Dedicated QUIC Connections （Standards Track: draft-ietf-dprive-dnsoquic） RFC 9250は、QUICを用いてDNSの通信を保護（暗号化）するための仕様（DNS over QUIC：DoQ）を定義します。DoQの仕様には、スタブリゾルバーとフルリ ゾルバー（キャッシュDNSサーバー）、フルリゾルバーと権威DNSサーバー、 ゾーン転送におけるQUICの使用が含まれます。 DoQをサポートしたフルリゾルバー・権威DNSサーバーは、デフォルトでは 853/UDPでQUICの接続を待ち受けます。DoQで送受信されるデータの内容は、 TCPによるDNS通信と同じ形式となります。 ▼リソースレコード処理に関する実装のアンチパターン ・RFC 9267: Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing （Informational: draft-dashevskyi-dnsrr-antipatterns） RFC 9267は、DNSクライアントのRRの処理において見られる、脆弱性を誘発する アンチパターン[*24]について記述しています。こうした脆弱性はそのDNSクラ イアントが動作する機器において、外部からのDoS攻撃やリモートコード実行な ど、不適切な動作につながる可能性があります。 本RFCは脆弱性「NAME:WRECK[*25]」を公開したセキュリティ研究者が、調査時 の分析で得られた結果をまとめたもので、IETFのWGで標準化されたものではな く、情報提供（Informational）として発行されています。 [*24] 処理・動作・構造などにおける、不適切な解決策の例をいいます。 [*25] 2021年4月に公開された、多数のIoTデバイス・制御機器などで使われて いる4種類のTCP/IPプロトコルスタックに存在する、9件の脆弱性を総称 したものです。これらの脆弱性はいずれも、ドメイン名圧縮・展開の実 装不備に由来します。 NAME:WRECK - Forescout https://www.forescout.com/research-labs/namewreck/ ▼NSEC3パラメーター設定のガイダンス ・RFC 9276・BCP 236: Guidance for NSEC3 Parameter Settings （Best Current Practice: draft-ietf-dnsop-nsec3-guidance） RFC 9276は、DNSSECの不在証明[*26]に用いられる、NSEC3パラメーターの設定 と取り扱いに関するガイダンスを提供します。本RFCはBCPとして、運用手法を まとめたものです。 [*26] リゾルバーに特定のドメイン名が存在しないことを通知する仕組みであ り、ドメイン名が問い合わされた特定のRRを持たないことを通知するた めに使用することもできます。 本RFCについては、本稿の「nsec3-guidanceの影響と次回のDNS flag dayの提 案」でも記載しています。 ■DNS関連WGの状況 ▼dnsop WGの状況 dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、 DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運 用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として います。 ▽DNSにおけるIPフラグメンテーションの回避 （draft-ietf-dnsop-avoid-fragmentation） JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーショ ン[*27]を回避するための提案です。 [*27] JPRS用語辞典｜IPフラグメンテーション（IP fragmentation） https://jprs.jp/glossary/index.php?ID=0180 本提案ではこれまでの議論の結果を受け、IPv4とIPv6においてPath MTU discoveryが失敗した、または不可能な場合のDNS/UDPの最大ペイロードサイズ の推奨値を1400とした上で、2022年7月26日から3週間のWGでの合意確認期間 （ワーキンググループラストコール（WGLC））が実施されています。 ▼dprive WGの状況 dpriveはDNS PRIVate Exchangeに由来しており、通信の暗号化によってDNSト ランザクションにおける機密性（confidentiality）を提供し、プライバシー を確保することを目的としています。 IETF 114では前回と同様、dprive WGは単独では開催されず、後述するadd WG の一部を割り当てる形で開催されました。 ▽権威DNSサーバーとの暗号通信が可能かをフルリゾルバーから検出する仕組 み （draft-ietf-dprive-unilateral-probing） フルリゾルバーと権威DNSサーバー間の通信の暗号化について、TCPとUDPの ポート853でDNS over TLSまたはDNS over QUICの権威DNSサーバーを動作させ、 フルリゾルバーでそれらのポートへの通信を試みることで暗号化の有無を検出・ 記憶する、シンプルな方式の提案です[*28]。 [*28] 本提案に至るまでの議論の経緯については、過去のドメイン名関連会議 報告をご参照ください。 https://jprs.jp/related-info/event/2022/0427ietf.html 本提案は、暗号化の検出・記憶における権威DNSサーバーとフルリゾルバーの 具体的な動作を、項目ごとに記述しています。発表ではそれらの動作について、 権威DNSサーバーではPowerDNS Authoritative Server、フルリゾルバーでは PowerDNS Recursorで実装を試していることが、開発者のPeter van Dijk氏か ら示されました。 ▼add WGの状況 addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プ ライベートネットワーク・VPNを含むさまざまなネットワーク環境において、 DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成 を目的としています。 ▽標準化作業の進捗状況 add WGでは、以下の3件の提案について標準化作業を進めてきました。 1. クライアントがDNSクエリ[*29]により、暗号化リゾルバー[*30]の構成を 検出する仕組みである、Discovery of Designated Resolvers（DDR） （draft-ietf-add-ddr） 2. 暗号化リゾルバーの構成を検出するためのDHCP及びIPv6 RAのオプション である、Discovery of Network-designated Resolvers（DNR） （draft-ietf-add-dnr） 3. 1と2を実現するためのSVCB RRの仕様（draft-ietf-add-svcb-dns） [*29] 特殊用途ドメイン名resolver.arpaを予約し、_dns.resolver.arpaに記 述されたSVCB RRを問い合わせてリゾルバーの構成を入手する仕組みが 提案されています。 [*30] 提案では、DNSクライアントとの通信が暗号化されたリゾルバーを暗号 化リゾルバー（Encrypted Resolver）、暗号化されていないリゾルバー を非暗号化リゾルバー（Unencrypted Resolver）と定義しています。 これまでの作業により、これらの提案はいずれもWGLCを終了し、IESGに送られ ました。これらが標準化されることで、スプリットホライズンDNS[*31]におけ る取り扱い[*32]などの残作業を除き、WGの当初の目的はほぼ完了することに なります。 [*31] スプリットDNS、またはスプリットホライズンDNS：送信元の状況（例： 送信元IPアドレス）の違いに応じ、特定のドメイン名の問い合わせに対 し異なる応答を返すように設定されている状況・環境を指します。 [*32] 本件の作業状況については、過去のドメイン名関連会議報告をご参照く ださい。 https://jprs.jp/related-info/event/2022/0427ietf.html ■次回のIETF Meetingについて 次回の第115回IETF Meeting（IETF 115）は、2022年11月5日から11日にかけて、 英国のロンドン及びオンラインのハイブリッドで開催される予定です。 ◇ ◇ ◇ ◎関連URI - IETF | IETF 114 Philadelphia https://www.ietf.org/how/meetings/114/ （IETF 114公式ページ） - IETF 114 Proceedings https://datatracker.ietf.org/meeting/114/proceedings （IETF 114議事録） - Domain Name System Operations (dnsop) https://datatracker.ietf.org/wg/dnsop/charter/ （dnsop WG公式ページ） - DNS PRIVate Exchange (dprive) https://datatracker.ietf.org/wg/dprive/charter/ （dprive WG公式ページ） - Adaptive DNS Discovery (add) https://datatracker.ietf.org/wg/add/charter/ （add WG公式ページ） - OARC 38 (30-July 31, 2022): Overview ・ DNS-OARC (Indico) https://indico.dns-oarc.net/event/43/ （OARC 38公式ページ） ━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━ ■会議報告：https://jprs.jp/related-info/event/ ■配信先メールアドレスなどの変更：https://jprs.jp/mail/henkou.html ■バックナンバー：https://jprs.jp/mail/backnumber/ ■ご意見・ご要望：from@jprs.jp 当メールマガジンは、Windowsをお使いの方はMSゴシック、macOSをお使いの方 はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。 当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、 ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。 また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、 リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに ご注意ください。 その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。 https://jprs.jp/mail/kiyaku.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 編集・発行：株式会社日本レジストリサービス（JPRS） https://jprs.jp/ Copyright (C), 2022 Japan Registry Services Co., Ltd.
Copyright©2001-2024 Japan Registry Services Co., Ltd.
