Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は Microsoft Azure Tech Advent Calendar 2024 の 8 日目の記事 です。 かつ、 こちらの記事は､Azure PoC部 Advent Calendar 2024の11日目の記事でもあります。 こんにちは、アーキテクトのやまぱんです。 補足コメントや質問、いいね、拡散、是非お願いします🥺！ 間違ってたら優しく教えてください！ 突然ですが、私は nslookup 使うなおじさんになりました。 結論からいうと、「nslookup の代わりに、PowerShell の Resolve-DnsN
ご無沙汰しております。11月6日に、CNAMEレコードを使って付与された1st-party cookieの規制機能を搭載したiOS14.2がリリースされましたので、その内容をまとめます。いつものことですがマーケティングよりブラウザの細かい話です。正式発表前なので誤りの可能性がありますがご了承またはご指摘ください。 規制の仕組みまず規制されるのは、AppleのWebKitエンジニアJohn Wilanderさん（ITPの発明家）が「Third-party CNAME cloaking」として定義するものです。 Third-party CNAME cloaking means a first-party subdomain resolves to a third-party domain which does not match the resolution for the top frame
MySQL 8.0.22 の新機能で DNS SRV レコードのサポートというのがあったので試してみた。 https://dev.mysql.com/doc/refman/8.0/en/connecting-using-dns-srv.html MySQLサーバー3台 (a.example.com, b.example.com, c.example.com)とそれに接続するためのクライアントの計4台を docker-compose で作成する。 Dockerfile FROM ubuntu RUN apt update RUN apt install -y mysql-client libmysqlclient-dev gcc unbound bind9-dnsutils RUN rm -f /etc/unbound/unbound.conf.d/root-auto-trust-ancho
こんにちは、滝澤です。 筆者の趣味として調べているDNSのプロトコルのここ数年のトピックについて紹介してみます。 ほぼ毎年、DNSに関連する新しいRFC（インターネットに関する技術仕様）が公開され、仕様が更新されたり、新しい仕様が追加されたりしています。 ここ数年のトピックについてまとめてみたいと思い立ち、この記事を書きました。 なお、この記事は2020年8月時点での情報となります。すべてを網羅しているわけではありません。 ちなみに、筆者は次のサイトを公開している人でもあります。 DNS RFCs ANYクエリーに対してRRsetをすべて返すわけではない 2019年1月に「RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」が公開されました。 このRFCでは、DNSレスポンダー（DNSレ
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
はじめに 先日、「IIJ DNSプラットフォームサービス」という新たな権威DNSサービスをリリースしました。プレスリリースはこちら。 そしたら、どーまえさんから「新サービスでやってるスゴいことについて記事書いてよ、それも主なものだけかいつまんで紹介するんじゃなくて細かいところまで全部！」とリクエストされました。「え、まじで全部書くんすか？！むっちゃ多いっすよ──。」 IIJのDNSサービスはかなり頑張ってるつもりですが、うちだけじゃなく、同業他社さんや、あるいは自前でDNSサーバを構築運用している企業さんにも頑張ってもらいたいんですよね。営業の立場からすると「ぜんぶIIJに任せてくれや」となるんでしょうけれど、売り文句にマルチプロバイダとあるように、IIJ単独じゃなくて複数のDNS事業者で同じゾーンを持つことで耐障害性を高めよう、ということも今回のサービスのポイントなのです。 IIJのサー
情報環境技術研究室の永井です。 今日はDNSのCNAMEの間違った使い方のお話です。 その間違った使い方がうちのサービスで使用されているかもっ!? DNSって? Domain Name System（ドメイン ネーム システム、DNS）はインターネットを使った階層的な分散型データベースシステムである。 1983年に情報科学研究所 (ISI) のポール・モカペトリスとジョン・ポステルにより開発された。 Wikipediaより一部抜粋 http://ja.wikipedia.org/wiki/Domain_Name_System 例えば、ライブドアのポータルサイトといえば「http://www.livedoor.com/」ですが、実際には「http://125.6.172.15/」というIPアドレスがインターネット上の住所になります。でも、こんな数字の羅列を一々覚えていられないので、DNSとい
ネームサーバーサービスとは 独自ドメインやIPアドレス用のネームサーバーを提供するオプションサービスです。 また、さくらのVPS・さくらの専用サーバ・ハウジングサービスをご利用の場合は、無料で利用可能なゾーンがございます。 ※さくらのクラウドをご利用の方はDNS(アプライアンス)のご利用をご検討ください。 詳しくは以下、前提条件をご参照ください。 前提条件 無料のネームサーバー ネームサーバーは以下のサービスをご契約の場合、無料で使えるゾーンがございます。 サービスにより、無料で使えるゾーン数は異なります。 追加でネームサーバーの利用をご希望の場合は、ネームサーバーサービスが必要です 以下のサービスには、新規提供を終了した「旧プラン」も含まれています。
1か月ほど前に「Cloudflare Resolver(1.1.1.1)でArchive.todayにアクセスできなワケ」を書いたが、最近また同じような話題で盛り上がっているようだ。 そこで著名なPublic DNSのバックエンドとECS (EDNS Client subnet)の有無について、権威DNSサーバを立ち上げてクエリログを確認してみた。 テスト条件テスト用DNSサーバ―にはICS BIND 9.12.4をインストールし、持て余していたgTLD（記事中ではexample.netに置き換えている）のゾーンを設定した。 テスト用クライアントにはWebARENAのVPSクラウド(157.65.27.7)にホスティングされているCMANインターネットサービスのnslookup(dig)テストを利用した。 Google Public DNS (8.8.8.8)client 173.194.
DNS ANAMEレコード / PowerDNS ALIASレコード 関連記事 PowerDNS ALIASレコード / TTL の 挙動確認 - tech memo (2019-05-08) はじめに CNAMEレコードの制約、ANAME レコードがなぜ必要なのか？ CNAMEレコードの制約 これらの制約を解決するANAMEレコード ANAME レコード 表示形式 と 専門用語 表示形式 専門用語 ANAMEレコードと、PowerDNS の ALIAS レコード について PowerDNS Authoritaive Server の ALIAS レコードを試してみる DNSレコードの準備 DNS lookupの実行 はじめに 「Address-specific DNS aliases (ANAME) 」というDNS関連の Internet Draft が、2017年よりIETFに提出され
■ KnotDNS _ 昨年の IW2018 の資料が公開されたようで。 _ 自分は Knot DNS の話をしたですよ。DNSSEC やりたいけどあんなの運用まわらん、とか、Let's Encrypt で DNS 認証させたいけど自動化できなくてめんどくさい、とか言ってる人いればぜひ Knot を使ってみてくださいませ。自動化できるよ。まあ、BIND でできないわけじゃないけど。いきない Knot に乗り換えるのが怖くても、資料にあるように、BIND やら NSD やら使い慣れたものを前段、後段に置いて三段構成にすれば、Knot をほとんど意識せず、これまでとほとんど変わらない感覚で自動化できるよ。 _ 資料に書こうか迷ったけど結局やめておいたネタ。 _ 資料では Let's Encrypt の dns-01 認証による証明書取得を自動化する方法について触れてるけど、そうはいってもうちの
なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
tech_team 2018年7月10日 JPNICからのお知らせ インターネットの技術 ■ はじめに DNSにはEDNSと呼ばれる拡張機能があります。このEDNSの実装が正しくないDNSサーバやネットワーク機器が、インターネット上に存在しています。これまで、いくつかのオープンソースのDNSサーバソフトウェアでは、EDNSの動作に不具合があるようなサーバ等に対しても名前解決ができるように、回避策が実装されていました。しかし「実装が複雑になりDNSの安定運用にも支障をきたすため、2019年2月1日以降のリリースから回避策の機能を削除することにした」というアナウンスがありました。 機能削除の予定日である2019年2月1日は “DNS flag day” と名付けられました。この記事では、その DNS flag day についてご紹介します。 ■ EDNS (Extension Mechanis
こんにちわ、株式会社はてなのシステムプラットフォーム部で SRE をやっている id:nabeop です。この記事ははてなエンジニア Advent Calendar 2018 の14日目の記事です。昨日は id:Pasta-K でした。 今日は hatena.ne.jp ドメインのゾーンを AWS Route 53 に移設するにあたって、AWS 初心者がどんなことを考えながら移設したかという話です。DNS ゾーンの移設の手順などについては既に様々な情報があるので、そちらを参照してください。 そもそもの始まり 僕は2018年3月に はてな に中途入社しました。入社して1ヶ月くらいたった4月のある日、「ねぇ、hatena.ne.jp というゾーンを AWS Route 53 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがな
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
仕事で外部のエンジニアに依頼したドメイン移行が正しく動作していなかったため、良い機会と思いDNSについて調べました。 名前解決の方法 そもそも名前解決とは何かというと、ドメインとIPアドレスを紐付けることです。手法として以下の2つが上げられます。 /etc/hostsに直接対応を記述する方法 /etc/resolve.confにDNSサーバーのIPアドレスを記述し、問い合わせる方法 今回はDNSサーバーによる名前解決について説明していきます。 DNSによる名前解決 ドメインツリーによる負荷分散 全世界に無数に存在するドメインの解決を一台のネームサーバーで担当するのは不可能です。そこでDNSでは下記のように、各階層に意味を持たせ、下位のドメインを管理させることで分散型の構造を構築しています。 ドメインツリー キャッシュサーバーによる高速化 クライアントからDNSサーバーに対してドメインを問い
はじめに 技術書典4にて「DNSをはじめよう」が販売され、400部あったはずの紙の本の在庫がなくなり、その後まもなくしてダウンロード用のカードも溶けるようになくなるという現象が発生しました。 自分も午後に会場入りして買いに行ったら「ダウンロード版も売り切れた」と言われショックを受けるものの、ダウンロード版については追加生産をしているとの事なので、ほどなくして再度ブースを伺ったら無事に買う事ができました。 尚、今現在もBOOTHにてPDF版が販売されています。 内容については「さぁDNS！」…の前にドメイン名の取得から丁寧に書いており、ドメイン名の取得からDNS設定の流れを体感するにはちょうどいい本ではないかなと。 なお、ドメインを利用する為にはレジストラやどこかのリセラー経由で登録料を払いドメイン名を登録してもらう必要があり登録手順も様々であるなか、お名前.comからの取得を例にして説明し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
