Google DomainsからCloudflare registrarにドメインとメールを移管した
Google DomainsがSquarespaceに買収されるので、持っているドメインとカスタムドメインのメールアドレスをCloudflare Registrarに移管した。 Cloudflare Registrar · Cloudflare Registrar docs 基本的にはCloudflare Registrarに表示される手順でやっておけば、問題は起きなかったので、よくできてると思った。 次のような手順で順番に移管していたので、移管時のメモ。 手順 Google Domainsの移行準備 Cloudflareのname serverを使うように移行する ドメインの移管 メールの転送設定 Google Domainsの移行準備 移管する前に、Google Domainに登録しているドメインの設定を変更しておく。 それぞれONになってると移管時に問題が発生する。 DNSSECを無
MagicDNS is generally available
Tailscale automatically assigns IP addresses for every unique device in your network, giving each device an IP address no matter where it is located. We further improved on this with MagicDNS, which automatically registers a human-readable, easy-to-remember DNS name for each device — so you don’t need to use an IP address to access your devices. This means you can access the device monitoring, ev
DNS前史：HOSTS.TXTとドメイン名ができるまで
こんにちは、技術開発室の滝澤です。 先月（2022年7月）、『Software Design 2022年8月号』の特集記事『WebエンジニアのためのDNS速習講座』に『第2章：DNSの構成要素と名前解決のしくみ』という記事を寄稿しました。第1章でも滝澤が趣味で作成した資料『ドメイン名の歴史』が参考文献として掲載されていました。よい機会なので、ドメイン名ができるまでの歴史について文章としてまとめようと思い、この本ブログ記事を書きました。 なお、筆者自身はインターネットの原型であるARPANETや80年代のインターネットをリアルタイムには体験してはいないため、RFC（Request for Comments）やインターネット上にある当時のホストのアーカイブを元に調査した内容をまとめたものになります。 ARPANETの時代 1969年から1980年代初期にかけてのインターネットの原型となったAR
以前やった社内向けDNS勉強会の資料を公開してみた | DevelopersIO
ども、ゲストブロガーの大瀧です。 クラスメソッド在籍中の2018年2月頃社内向けにDNS勉強会を全4回で開催したことがあり、そのときの資料がひょこっと見つかったので公開してみます。(正確には第3回は聖剛さん担当だったので一緒に公開してもらいました、感謝。) 第1回 DNS入門 : DNSのしくみ、キャッシュ 第2回 DNSコンテンツサーバー : DNSサーバーの分散構成とゾーンの委任 第3回 DNSセキュリティ : DNS関連の攻撃手法とDNSSEC 第4回 AWSのDNSサービス : Route 53とAmazon DNS DNSについての理解を深める一助にしていただければと思います。現職(SORACOM)でももちろん超重要な技術です！ 第1回 DNS入門 スライド共有サービス終了に伴い、公開終了 第2回 DNSコンテンツサーバー スライド共有サービス終了に伴い、公開終了 第3回 DNS
DNSの仕組みと調査方法について - embryo
仕事で外部のエンジニアに依頼したドメイン移行が正しく動作していなかったため、良い機会と思いDNSについて調べました。 名前解決の方法 そもそも名前解決とは何かというと、ドメインとIPアドレスを紐付けることです。手法として以下の2つが上げられます。 /etc/hostsに直接対応を記述する方法 /etc/resolve.confにDNSサーバーのIPアドレスを記述し、問い合わせる方法 今回はDNSサーバーによる名前解決について説明していきます。 DNSによる名前解決 ドメインツリーによる負荷分散 全世界に無数に存在するドメインの解決を一台のネームサーバーで担当するのは不可能です。そこでDNSでは下記のように、各階層に意味を持たせ、下位のドメインを管理させることで分散型の構造を構築しています。 ドメインツリー キャッシュサーバーによる高速化 クライアントからDNSサーバーに対してドメインを問い
Cloudflareの1.1.1.1が「DNS over Twitter」を開始。ドメイン名をツイートすると即座にIPアドレスを返答
Cloudflareの1.1.1.1が「DNS over Twitter」を開始。ドメイン名をツイートすると即座にIPアドレスを返答 高速なDNSサービス「1.1.1.1」をAPNICと協力して開始したことなどで知られるCloudflareが、新たなドメイン名解決サービスの「DNS over Twitter」を開始しています。 これは@1111Resolver宛てにドメイン名とレコードタイプをツイートすると、即座にIPアドレスを返答してくれる、というもの。 下記はCloudflareのエンジニアNick Sullivan氏のツイート。 The 1.1.1.1 resolver now supports a new protocol: DNS over Twitter! Just send your queries to @1111Resolver. We’re also working o
総務省｜報道資料｜DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性
この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 総務省では、ICANNからの依頼を受けて、内閣サイバーセキュリティセンターの協力の下、国内関係者への周知を実施しております。 この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN（Internet Corporation for Assigned Names and Numbers）が、DNS（ドメインネームシステム）において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵（ルートゾーンKSK）の更改を実施します。 これに伴い
CVE-2015-7547 glibc における getaddrinfo の脆弱性について – IIJ Security Diary
この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。本記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。 CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflow Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri
インターネットの根幹「DNS」に根本的欠陥が見つかる(dragoner) - 個人 - Yahoo!ニュース
このJPRSの発表に対し、この欠陥を発見した中京大学の鈴木常彦教授、前野年紀氏は「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」を懸念し、下記のブログ記事等でこの問題の危険性を訴えています。 この問題はインターネットの根幹に関わるものですが、どんな問題を孕んでいるのでしょうか。それを理解するために、まずはDNSの仕組みから見て行きましょう。 DNSの仕組みとDNSキャッシュサーバDNSとはインターネットの根幹に関わる仕組みで、目的のサーバにアクセスする為の重要な役割を持ちます。簡単に説明すると、"http://www.example.jp"というURLのサイトを見たい場合、それを管理するサーバのインターネット上の住所（IPアドレス）が必要になります。そこで、DNSサーバに上記URLのラベル（ドメイン）に相当する"www.example.jp"を管理するサー
（緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年5月30日更新）
--------------------------------------------------------------------- ■（緊急）キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について（2014年4月15日公開） ～問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨～ 株式会社日本レジストリサービス（JPRS） 初版作成 2014/04/15（Tue） 最終更新 2014/05/30（Fri） （対策に関するDNS運用者向け文書へのリンクを追加） --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
AWS News Blog
AWS Weekly Roundup – AWS AppSync, AWS CodePipeline, Events and More – August 21, 2023 In a few days, I will board a plane towards the south. My tour around Latin America starts. But I won’t be alone in this adventure, you can find some other News Blog authors, like Jeff or Seb, speaking at AWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New – Amazon EC2 H
「DNSが攻撃されてる！助けて！」→「いえいえ、アナタも攻撃に加担してます」:Geekなぺーじ
DNS Summer Days 2013の初日最後のセッションで面白い話が公表されていました。 JPCERT/CCに対して「うちのDNSが攻撃されています。助けて下さい」という問い合わせが来ることがあるらしいのですが、調べてみるとその大半がDDoSの踏み台として使われているのであって、実際は攻撃に加担してしまっているというものでした。 他者を攻撃するトラフィックを生成することで、自身の回線やサーバに負荷がかかってしまっている状態が凄くよくあるそうです。 「助けて！」と言っている人が、意図せずに誰でも使えるオープンリゾルバとして設定されており、攻撃者の踏み台にされているというものです。 キャッシュDNSサーバの設定を変更し、オープンリゾルバをやめると問題が解決することが多いとのことでした。 今年に入ってから、オープンリゾルバがDDoS攻撃の踏み台にされる話がインターネット通信業界で話題です。
人間はみなバグだらけ。完璧な人間なんていないことが遺伝子解析で証明される
人間はみなバグだらけ。完璧な人間なんていないことが遺伝子解析で証明される2012.12.26 12:3015,201 satomi ｢完璧な人間なんかいないさ｣と人を慰めることありますけど、あれって本当だったのね！ 英ケンブリッジ大学が179人のヒトゲノムを解読してみたら、本当に完璧な人間がひとりもいないことがわかりました！ DNAには欠陥があって無害なものもあれば病気となって現れる場合もある...というのはみなさんもご存知だと思いますが、｢平均的な人間はどれぐらいの欠陥を持ってるものなのか？｣という部分はこれまで曖昧なままでした。 ケンブリッジ大学のクリス・タイラー-スミス（Chris Tyler-Smith）博士はNPR放送にこう話してます。 ｢これは非常に面白い問題ですね。長年、間接的なアプローチによる推定の試みはなされてきました。重病が絡む変異体の推定数は、ほんの一握りしかないとい
たった5分でDNSの仕組みがわかる（？）物語 - ライフハックブログKo's Style
少女ジェシカが、遠い日本に暮らす親友ゆいに手紙を書きました。 すると飼い猫ポールがその思いを届けようと、窓から外へ飛び出します。 冒険の始まりです。 実はこの動画、たった5分でDNSの仕組みがわかる物語でした。 黒猫の不思議な旅 （ムダに）すごいクオリティ（笑）。 DNSの仕組み、わかりましたか？ ちょっと難しいかもですね…。 もっと詳しく知りたい方はこちら 詳しい解説もありますよ。 黒猫の不思議な旅.jp - それはメールを届けるための一瞬の物語 - Presented by.JPRS（株式会社日本レジストリサービス） まとめ この動画がどうだったかは別として、物事に興味を持ってもらったり、理解してもらうためには、「ストーリー」を使うのは良い手段ですね。 たとえば、この本。 「仕事について、お金について、考えてみようよ」なんていうより、このストーリーを読めば、自然と考えさせられます。興味
DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件
忍者ツールズ全サービスが表示不可となる障害につきまして | ドメイン取るなら お名前.com ドメイン取得 年間280円～ 忍者TOOLSは、お名前.comというドメイン名レジストラにninja.co.jpのドメイン情報を管理させていた。忍者TOOLSは、ninja.co.jpというドメインを、自社の様々なサービスに使っていた。そのサービスは、忍者TOOLSのユーザーが使うものである。 さて、お名前.comの主張では、忍者TOOLSのユーザーがお名前.comの規約違反を起こしたために、ユーザーの規約違反は、すなわちそのユーザーのサービス提供元の規約違反であるとし、事前の協議や警告すらなしに、一方的にninja.co.jpのドメイン情報を消したそうだ。 これは恐ろしく危険な事件である。問題は、DNSが階層的な中央管理をされたシステムである以上、この問題は仕組み上どうしようもないという事である
DNSブロッキングは筋が悪いのか？:Geekなぺーじ
日本で行われている児童ポルノブロッキングで採用されているのは、DNSキャッシュサーバがブロックリストに掲載されたFQDNの名前解決を行わないという、DNSキャッシュポイズニングという手法です。 この手法は、主にISPが提供するDNSキャッシュサーバにて行われているので、児童ポルノブロッキングを行っていないDNSキャッシュサーバを利用することで回避が可能です。 また、IPアドレスを直接指定して通信を行うことで回避することも可能です。 このような手法が採用されていることに関して、「アホじゃないの？」とか「ザルじゃないの？」という感想が述べられがちです。 昨日、以下のような記事が出ていましたが、それに対しても「仕組みを考えた奴はバカだろう」的なニュアンスの感想が散見されます。 児童ポルノ遮断、「ＩＰ直打ち」ですり抜け横行 : 社会 : YOMIURI ONLINE（読売新聞） 私の感想 「IPア
さくらDNSにサブドメインハイジャックを許す脆弱性
さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。 DNSサービスへのドメイン登録時における不具合について 障害内容 : 当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。 本問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。 この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。 (12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日（6月13日）には改修されましたので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバーなど設定確認を！ 今年9月は特に注意 「Internet Weekショーケース in 名古屋」の発表から
【インタビュー】過去最大300Gbps超のDDoS攻撃に悪用されたDNSの「オープンリゾルバー」とは 
「DNSの浸透待ち」は回避できる――ウェブ担当者のためのDNS基礎知識 