HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
QUICはTCPの代替ではない
ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え
DNS前史：HOSTS.TXTとドメイン名ができるまで
こんにちは、技術開発室の滝澤です。 先月（2022年7月）、『Software Design 2022年8月号』の特集記事『WebエンジニアのためのDNS速習講座』に『第2章：DNSの構成要素と名前解決のしくみ』という記事を寄稿しました。第1章でも滝澤が趣味で作成した資料『ドメイン名の歴史』が参考文献として掲載されていました。よい機会なので、ドメイン名ができるまでの歴史について文章としてまとめようと思い、この本ブログ記事を書きました。 なお、筆者自身はインターネットの原型であるARPANETや80年代のインターネットをリアルタイムには体験してはいないため、RFC（Request for Comments）やインターネット上にある当時のホストのアーカイブを元に調査した内容をまとめたものになります。 ARPANETの時代 1969年から1980年代初期にかけてのインターネットの原型となったAR
図解 X.509 証明書 - Qiita
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
MACアドレスの再利用は、みんなが思っているよりもはるかに一般的:Geekなぺーじ
MACアドレスは、原則として、一意に割り当てられるものです。 ネットワークインターフェースごとに、ひとつずつユニークな値をベンダーが付けるものとされています。 ただ、これは、あくまで「原則として」であって、実際は、MACアドレスが重複することもあります。 IPv6に関連するいくつかのRFCで、MACアドレスの重複への言及があります。 この記事では、MACアドレスの重複とIPv6アドレスの自動生成という、わりと限定された視点ではありますが、MACアドレスが一意とは限らない、という話を紹介します。 なお、この記事のタイトルである「MACアドレスの再利用は、みんなが思っているよりもはるかに一般的」は、RFC 7217に書かれている一文の日本語訳です。 MACアドレスの重複とIPv6アドレス生成の仕様 MACアドレスがIPv6アドレスの自動生成で使われる場合があります。 IPv6アドレス体系のRF
RFC 8725 JSON Web Token Best Current Practices をざっくり解説する - Qiita
ritou です。 今回は RFC 8725 JSON Web Token Best Current Practices を紹介します。 みんな大好き JWT (JSON Web Token) の BCP ときたらチェックせずにはいられないでしょう。 概要 JWTは 署名/暗号化が可能な一連のクレームを含む、URLセーフなJSONベースのセキュリティトークン です JWTは、デジタルアイデンティティの分野および他のアプリケーション分野の両方の多数のプロトコルおよびアプリケーションにて、シンプルなセキュリティトークンフォーマットとして広く使用/展開されています このBCPの目的は、JWTの確実な導入と展開につながる実行可能なガイダンスを提供することです ということで、何かのフレームワークでもプロトコルでもなければJWTを使ったユースケース考えたよって話でもなく、JWTを導入する上で基本的な部
『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』の予習・復習用情報 - Qiita
はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op
どれくらい自社ドメインがなりすまされているか、ご存知ですか? | IIJ Engineers Blog
IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 企業の情報システム部門でメールを担当されているみなさん、この問いに答えられる方は、どれくらいいらっしゃるでしょうか。 「そんなこと、気にしたこともない」という方も少なくないかもしれません。それもそのはず、これまで送信ドメイン認証を代表する SPF、DKIM は、送信者側が受信者側でどのように評価されたか知る術がありませんでした。ましてや、第三者の何者かが自社ドメインを勝手に使って誰かにメールを送っている、なんて知ることは不可能でした。 しかし、DMARC(RFC 74
ネットワーク構成の可視化ツール、ハイブリッドクラウド環境も対象に
共同研究の目的は、これまで人手に頼っていたネットワーク運用業務の効率化を目指すこと。複雑なネットワークに障害が発生したときの影響を確認するといった応用ももくろむ。 これまで単一製品では管理が難しかったハイブリッドクラウド環境なども対象にする。複数のサービスや領域をまたがるようなネットワークシステムへの応用も目指す。 標準トポロジモデルを利用する 今回の開発の下敷きとなる標準トポロジモデルとは、インターネット技術の標準化団体であるIETF（Internet Engineering Task Force）が2018年3月に発行したRFC 8345「A YANG Data Model for Network Topologies」とRFC 8346「A YANG Data Model for Layer 3 Topologies」で定義されたデータモデル。ネットワーク構成図に記述される機器間の接
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に
RESTful APIのデータフォーマットなどで広く使われているJSON。IETFはJSON仕様「RFC 8259」を発表。従来の仕様をブラッシュアップしつつECMAの仕様との統一も実現した、事実上最後のJSON仕様になると見られる。 IETFからJSON（ジェイソン）の仕様を示した「RFC 8259」（The JavaScript Object Notation (JSON) Data Interchange Format）が公開されました。 IETFにおけるJSON仕様は、これまで「RFC 7159」が参照されていましたが、RFC 8259の公開によりRFC 7159は廃止（Obsolete）となりました。 RFC 8259は、多数の実装と十分な運用実績を積み重ねたインターネット標準「STD 90」としても参照されます。 ECMAとの統一を実現。事実上最後のJSON仕様になると見られる
LinuxカーネルHack: ICMPエコー発、procファイルシステム着 (gdbのwatchを使うよ) - 佐野デジタル研究所
はじめに 前回に引き続き、ICMPまわりを追っていこうとしたら、大幅に脱線して、procファイルシステムに到着。 カーネルを少しいじりつつ、gdbの変数監視機能(watch)を利用することで、/proc/sys/net/ipv4/icmp_echo_ignore_allへの書き込みを監視することに成功した。 脱線のへの道のり ICMPエコーはicmp_echo関数によって処理される。 icmp_echo関数を見ると、net->ipv4.sysctl_icmp_echo_ignore_allフラグが立っていない場合は、 ICMPエコーを返さないようだ。 % cat net/ipv4/icmp.c [...] /* * Handle ICMP_ECHO ("ping") requests. * * RFC 1122: 3.2.2.6 MUST have an echo server that
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC日本語訳一覧