並び順

ブックマーク数

期間指定

  • から
  • まで

361 - 400 件 / 772件

新着順 人気順

dnsの検索結果361 - 400 件 / 772件

  • 280blockerの暗号化DNSの詳細 | 280blocker

    最近公開した暗号化DNSサーバ(DoH)の運営や技術的な話です。 暗号化DNSサーバーはiOSの280blockerアプリ利用者だけに公開しています。最新版アプリの高度な設定から利用が可能でsafari以外の広告もブロックできます。サービスを利用するだけなら特に知らなくても良い話です。 DNSサーバ DNSサーバーは端末から問い合わせのあったサイトのドメイン名をipアドレスへ変換して応答する作業をしています。端末はその情報を利用して、閲覧したいサイトのIPアドレス宛にデータを要求します。 DNSサーバーがドメインの問い合わせに対してそのサーバーは存在しない(NXDOMAIN)という応答にすると、端末はデータが要求できなくなり、そのドメインとの通信をブロックできます。これがDNSサーバを利用した広告ブロックです。 ちなみにDNSサーバへの問い合わせの中で、広告系ドメインの問い合わせの割合はざ

      280blockerの暗号化DNSの詳細 | 280blocker
    • 数百万台のIoTや産業用デバイスに影響をおよぼす脆弱性「NAME:WRECK」

      IoTや産業用デバイス向けにセキュリティソリューションを提供するForescoutが、「NAME:WRECK」と呼ばれる数百万台のIoTや産業用デバイスに影響をおよぼす可能性のある脆弱性の存在を報告しています。 NAME:WRECK - Forescout https://www.forescout.com/research-labs/namewreck/ NAME:WRECK vulnerabilities impact millions of smart and industrial devices | The Record by Recorded Future https://therecord.media/namewreck-vulnerabilities-impact-millions-of-smart-and-industrial-devices/ How the NAME:W

        数百万台のIoTや産業用デバイスに影響をおよぼす脆弱性「NAME:WRECK」
      • DNS名前解決エラーもネガティブキャッシュする提案 (RFC 9520) - ASnoKaze blog

        2023/12/23 追記: RFC 9520 になりました == 「Negative Caching of DNS Resolution Failures」という提案が、Verisignの方らによって提案されています。 DNSの名前解決の結果はつぎのいずれかです。 1) 要求されたデータを含む応答 2) 要求されたデータが存在しないことを示す応答 3) ネットワークエラーや、データ不整合などの、有用な情報が得られない(失敗) 今回の提案では、(3)のエラーについても最低5秒間ネガティブキャッシュするよう要求します(5分以上キャッシュしてはいけない)。 RFC2308 「Negative Caching of DNS Queries」では、サーバが落ちていたり接続できない場合に、オプショナルでキャッシュする事が記述されてはいます。 モチベーション 提案仕様のなかで、DNSのエラーが起こり、

          DNS名前解決エラーもネガティブキャッシュする提案 (RFC 9520) - ASnoKaze blog
        • Google、「Chrome 78」で“DNS-over-HTTPS”を実験/DNSへの問い合わせをセキュアでプライバシーが保たれるHTTPS接続で

            Google、「Chrome 78」で“DNS-over-HTTPS”を実験/DNSへの問い合わせをセキュアでプライバシーが保たれるHTTPS接続で
          • AWS Load Balancer ControllerとExternalDNSを利用しています - ハウテレビジョンブログ

            こんにちは、SREチームの小川です。 「夏への扉」を読みました。過去・現在・未来の時間軸が最後にかち合った時には感動を覚えました。月並みですが、さすがSFの金字塔ですね。 今回は「外資就活への扉」である、ALB・Route53をSREがどのように管理しているか紹介したいと思います! はじめに 以前よりSREチームが「外資就活ドットコム」のインフラをEC2中心のものから、コンテナ中心のEKSへと移行したお話をしてきました。 今回はKubernetesを導入した際に、トラフィックの流入元であるALBをAWS Load Balancer ControllerとExternalDNSを利用して管理を行うようにしたお話しをします。 EKSのサービスをALBを利用して公開する際に、アプリケーションコンテナをNodePortで公開し、ALBがNodeGroupの特定のNodePortにリバースプロキシす

              AWS Load Balancer ControllerとExternalDNSを利用しています - ハウテレビジョンブログ
            • Terraform 1.0.1の新機能使ってみた | DevelopersIO

              先日、TerraformのVersion 1.0.1がGAになりました。新機能をチェックしてみたいと思います。 とはいっても、今回の新機能は1つだけ、かつ細かいアップデートのようです。JSONアウトプットにsensitive属性情報が追加されました。 JSONアウトプット? plan 通常terraform planを実行すると、applyした場合にどのような変更が発生するか(=plan結果)が出力されますよね。この時-out=<PATH>というオプションを追加すると、画面にplan結果を出力する代わりに、<PATH>位置にplan結果をバイナリファイルとして出力してくれます。バイナリなのでそのままファイルを見ることはできません。見るときはterraform show <FILE>というコマンドを使います。 $ terraform show plan-binary Terraform us

                Terraform 1.0.1の新機能使ってみた | DevelopersIO
              • Slackで接続障害、「1%未満のユーザー」に影響 DNS関連でトラブル

                10月1日午前1時30分ごろから、企業向けコラボレーションツール「Slack」で接続障害が発生している。11時00分現在、米Slack Technologiesは、1%未満のユーザーに接続障害が発生していると発表した。 同社では障害の原因について「DNS関連の問題を認識している」と説明。Slack側の変更により発生したものだという。この問題の解決には、ISP(インターネットサービスプロバイダー)がslack.comのDNSレコードのキャッシュをクリアする必要があるという。午前4時50分時点で、全てのユーザーの接続障害は、24時間以内に解決する予定と説明する。 最新のステータスでは「改善の兆しが見られる」として、Slackをリロードすることで、再度ロードできる場合があると案内。ただし、全てのユーザーがこの方法で解決されるわけではなく、引き続き不具合の解消を進めるとしている。 関連記事 Sla

                  Slackで接続障害、「1%未満のユーザー」に影響 DNS関連でトラブル
                • Firefox/Google Chromeに続き、Windowsでも“DNS over HTTPS”をサポートへ/将来的には“DNS over TLS”にも対応

                    Firefox/Google Chromeに続き、Windowsでも“DNS over HTTPS”をサポートへ/将来的には“DNS over TLS”にも対応
                  • Understanding DNS with ActionDispatch::HostAuthorization

                    2020 年 10 月 3 日開催の、Kaigi on Rails で発表した内容です。(発表時間 20 分) ## 2020/10/12 追記 このスライドの説明だけですと攻撃の特性がわかりづらかったので、個人ブログの以下の記事にて追加の説明を行いました。 https://yucao24hours.me/blog/2020/10/12/dns-rebindig-basics-revised/

                      Understanding DNS with ActionDispatch::HostAuthorization
                    • 「ネット世界の証明書の30%はLet’s Encrypt製」「3017年まで有効な証明書が1000件以上」など3億5000万件のSSL接続データセットからわかったことは?

                      by TBIT 「『最近のウェブで、SSLはどのように使われているのか』という既存データセットがなかったので自分で作った」というリー・バターマン(@leebutterman)さんが、その3億5000万件のSSL接続データセットを分析し、「どこの証明書が多く使われているか」やどういった暗号スイートが人気かという情報をまとめて公開しています。 Let’s Encrypt makes certs for almost 30% of web domains! RC4/3DES/TLS 1.0 are still used! Certs for hundreds of years! Analyzing hundreds of millions of SSL handshakes | Little Short Bulletins https://www.leebutterman.com/2019/08

                        「ネット世界の証明書の30%はLet’s Encrypt製」「3017年まで有効な証明書が1000件以上」など3億5000万件のSSL接続データセットからわかったことは?
                      • トップレベルドメイン(TLD)とサイバー犯罪に関する考察

                        By Janos Szurdi November 11, 2021 at 6:00 AM Category: Unit 42 Tags: Cybercrime, DNS, Phishing This post is also available in: English (英語) 概要 .com、.net、.xxx、.huなどのトップレベルドメイン(TLD)は、ドメインネームシステム(DNS)の名前付け階層の最上位に位置します。ユーザーがドメイン名(たとえばpaloaltonetworks.com)を取得しようとする場合、通常は、TLDに直接登録するか、1つ下の階層(たとえばgoogle.co.uk)に登録する必要があります。TLDの価格、登録制限、セキュリティ慣行、他のTLDとの字句の類似性(たとえば.cmと.com)などのTLDの特性やポリシーは、犯罪者が活動をしていく上でこれらのTLD

                          トップレベルドメイン(TLD)とサイバー犯罪に関する考察
                        • IIJ、世界100拠点以上のDNSサーバーを利用できる「IIJ DNSプラットフォームサービス」開始

                            IIJ、世界100拠点以上のDNSサーバーを利用できる「IIJ DNSプラットフォームサービス」開始 
                          • Cloudflare Zero TrustとRaspberry Piを使って自宅のPCをクラウド化する

                            この記事はEEIC Advent Calendar 2022 4 日目の記事として作成しました はじめに こんにちは。EEIC2022 の hososuke です。最近自作 PC をしたんですが、せっかく組んだ性能のいい PC を大学にいるときや、実家に帰省したときでも使えるようにしたいと思い、色々と試行錯誤したことをこの記事に書きたいと思います。 記事のタイトルを「自宅の PC をクラウド化する」なんて大げさに書いてしまいましたが具体的に行ったことは次の 3 つになります。 外出先からも自宅の PC に SSH 接続できるようにする 自宅の PC を遠隔で起動できるようにする 自宅の PC の状態(起動しているかどうか)を監視する 若干タイトル詐欺気味になってしまうのですが、もし興味があれば最後までお付き合いいただければと思います笑 概説 以下に、ネットワークの概略図を載せます。 まず、

                              Cloudflare Zero TrustとRaspberry Piを使って自宅のPCをクラウド化する
                            • DNS のセキュリティ改善計画に関する誤解を解く

                              .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

                                DNS のセキュリティ改善計画に関する誤解を解く
                              • DNSの代表的な弱点「メッセージ圧縮機能」――その理由と現状を振り返り、今後の針路を考える【Internet Week 2022】

                                  DNSの代表的な弱点「メッセージ圧縮機能」――その理由と現状を振り返り、今後の針路を考える【Internet Week 2022】
                                • iOS 15 iCloud Private Relay Vulnerability Identified

                                  Apple’s new iCloud Private Relay service allows users to hide their IP addresses and DNS requests from websites and network service providers. In this article, we’ll demonstrate how this security feature can be circumvented and discuss what users can do to prevent their data from being leaked. You’ll need to turn on iCloud Private Relay to test the vulnerability. At the moment iCloud Private Relay

                                    iOS 15 iCloud Private Relay Vulnerability Identified
                                  • 17年前から存在 ~「Windows Server」のDNS機能に致命的なリモートコード実行の脆弱性/自己増殖して感染を広げる“ワーム”への悪用も考えられるため、優先的な対処を

                                      17年前から存在 ~「Windows Server」のDNS機能に致命的なリモートコード実行の脆弱性/自己増殖して感染を広げる“ワーム”への悪用も考えられるため、優先的な対処を
                                    • 当社利用のドメイン登録サービスにおける不正アクセスについて(第二報)

                                      第一報に関してはこちらよりご確認ください QUOINE株式会社(本社:東京都千代田区、代表取締役:栢森 加里矢、以下当社)は、2020年11月15日に発表した不正アクセスに関する事象について、さらに社内調査を進めた結果を以下のように報告致します。 このような事態が発生し、お客様に多大なご迷惑をおかけしましたことをあらためて深くお詫び申し上げます。 なお本事案に関しましては適宜監督官庁へ報告を行っております。 1.発生事象 2020年11月13日、当社のコアドメイン名の1つを管理するドメインホスティングプロバイダー(GoDaddy社)において、当社アカウント・ドメインの登録情報が悪意のある第三者(以下、第三者)に変更されました。 これにより、第三者は当社のDNS(ドメイン・ネーム・システム)レコードを変更し、複数の内部の電子メールアカウントを制御できるようになり、当社のシステム・インフラの一

                                        当社利用のドメイン登録サービスにおける不正アクセスについて(第二報)
                                      • Facebook、約6時間にわたる障害の原因と対策を詳解

                                        米Facebookは10月5日(現地時間)、前日の日中に発生したInstagramやOculusも含むすべてのサービスに影響した障害について、その原因と復旧方法について説明した。 今回の停止は、前日簡単に説明したように、グローバルバックボーンネットワーク容量を管理するシステムによって引き起こされたものだが、約6時間にもわたり、非常に重要なことであるため、もう少し詳しく説明する価値があると考えたとしている。 グローバルバックボーンは、Facebook全社のコンピューティング施設を接続するネットワークで、世界中を数万マイルの光ファイバーケーブルで接続している。このインフラの保守のため、エンジニアは通常、バックボーンにオフラインで接続し、ファイバーの修理、容量追加、ルータのソフトウェア更新などを行う。 昨日の停止は、こうした定期的なメンテナンスの一環として、容量を評価するコマンドを発行したところ

                                          Facebook、約6時間にわたる障害の原因と対策を詳解
                                        • マイクロソフト、危険なドメイン「corp.com」を購入--悪用を防ぐ

                                          印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます セキュリティ研究者のBrian Krebs氏が米国時間4月7日に伝えたところによると、Microsoftはcorp.comという危険なドメイン名が悪人の手に落ちることを防ぐために、当該ドメイン名を購入したという。同社は購入した事実を認めているが、価格については明らかにしていない。 Krebs氏は2月、26年前にcorp.comドメインを購入したMike O'Connor氏が、170万ドル(約1億8500万円)の開始価格で同ドメイン名をオークションにかけたと伝えていた。このドメイン名が問題となるのは、企業の管理者が「Active Directory」を設定する際に任意のドメイン名として一般的なドメイン名(corp.com)を使用した場合、

                                            マイクロソフト、危険なドメイン「corp.com」を購入--悪用を防ぐ
                                          • Open DNS resolvers, from bad to worse | APNIC Blog

                                            Table 1 — Queries issued for systematic testing of amplification power of open resolvers. Let’s now dive into a couple of our findings. Redefinition of open resolvers Traditionally, network-attached devices are considered open resolvers if they respond to ‘A’ queries. However, our study shows that being open (as in answering ‘A’ queries) is not necessarily equivalent to successfully resolving othe

                                              Open DNS resolvers, from bad to worse | APNIC Blog
                                            • 「ネットの自由守れ」ブロックチェーン・ベースのDNSが始動

                                              ハンドシェイク・ネットワーク(Handshake Network)と呼ばれる野心的なパブリックブロックチェーン・プロジェクトは、数カ月のテストの後、ついにメインネットワークを立ち上げた。ハンドシェイク・ネットワークは、インターネット・ドメイン名の割り当て方法を改革しようとする開発者によるプロジェクトである。 ブラウザーにWebサイト名を入力すると、DNS(ドメイン名システム)と呼ばれるコンピューター・ネットワークが要求される。DNSはインターネット上のすべての名前を追跡するものだ。DNSは入力されたテキスト(例: www.technologyreview.com )をIPアドレスと呼ばれる数値の文字列に変換する。この番号により、ブラウザーはアクセスしようとしているWebサイトのサーバーを見つけてサーバーに接続できる。 DNSは階層的なグローバルネットワークで、階層の最上部にはいわゆるDNS

                                                「ネットの自由守れ」ブロックチェーン・ベースのDNSが始動
                                              • Domains having Hidden Open Resolvers

                                                隠れオープンリゾルバを放置している日本のドメイン 下記リストのドメインは一つないし複数の隠れオープンリゾルバがネットワーク内に見つかっているものです。ドメイン名の前の数字が見つかったリゾルバの数です。 (サブドメインは親ドメインに集約しています / PTR が複数ある場合は 1 つだけ選択しておりラウンドロビンで差し変わる場合があります) 隠れオープンリゾルバとはサーバにはアクセス制限がかけられているものの、ソース IP アドレスを詐称したクエリが到達してしまうものを指して私が名づけたものです。これらが属するネットワークは外部との境界ルータでソース IP アドレス詐称パケットをフィルタリングしていないと考えられ、調査対象のリゾルバを含むネットワークが各種ソース IP アドレス詐称攻撃に脆弱である可能性が高いと考えられます。(一部は真正のオープンリゾルバも含まれています) なおスキャン対象は

                                                • GitHub - spyboy-productions/CloakQuest3r: Uncover the true IP address of websites safeguarded by Cloudflare & Others

                                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                    GitHub - spyboy-productions/CloakQuest3r: Uncover the true IP address of websites safeguarded by Cloudflare & Others
                                                  • 東京リージョンでVPC Lambdaの高速起動が確認できたので改善効果を計測してみた | DevelopersIO

                                                    2019/9/16時点でAWSからはVPC Lambdaの改善適用完了のアナウンスはありません。 「なんか新アーキテクチャで起動してるっぽいから試しに測ってみるかー...」という程度のノリでの計測なので、アーキテクチャの段階移行の過程における一時的な計測結果として参考にするに留めて下さい。 実際にAWSから移行完了がアナウンスされる際は、今回の計測結果のような動作にならない可能性が高いことに留意して下さい CX事業本部@大阪の岩田です。 先日公式にアナウンスされたVPC Lambdaのコールドスタート改善、数ヶ月かけて徐々に適用とのことでしたが、先ほど東京リージョンで新アーキテクチャでのVPC Lambda起動が確認できました。 【速報】もうアンチパターンとは呼ばせない!!VPC Lambdaのコールドスタート改善が正式アナウンスされました!! VPC Lambdaのコールドスタートがどの

                                                      東京リージョンでVPC Lambdaの高速起動が確認できたので改善効果を計測してみた | DevelopersIO
                                                    • SPFレコードの書き方とは? 記述例を総まとめ - ベアメールブログ

                                                      Eメールは、多数の顧客へ効率よくアプローチできる優れた手段です。しかし近年、増え続けるスパムメールや「なりすましメール」の対策として迷惑メールフィルターが強化された結果、内容に問題がないメールにもかかわらず、メールが届かないケースが散見されます。メールの不達を防ぐためにも、送信ドメイン認証の導入は必須といえるでしょう。 とりわけ、送信ドメイン認証の中でも特に普及率が高いSPFについては、もし自社のドメインに導入していない場合は早急に実装すべきでしょう。ここでは、SPFレコードに関する基礎知識と具体的な実装方法(SPFレコードの記述方法)について紹介しています。 SPFとは? SPFとは SPF(Sender Policy Framework)とは、送信元IPアドレスの正当性を検証する送信ドメイン認証技術の方式です。メールはその仕組み上、送信元を偽る「なりすまし」が容易であり、標的型攻撃やフ

                                                        SPFレコードの書き方とは? 記述例を総まとめ - ベアメールブログ
                                                      • RubyKaigi 2022の会場ネットワークリポジトリを読み解く | うなすけとあれこれ

                                                        私がこれを書く動機 私はKaigi on Railsのオーガナイザーのひとりです。Kaigi on Rails 2023は物理会場にて開催されることが公開されました。そうなるともちろん、会場でのインターネットについてはどうなる、どうする、という問題が出てきます。それに備えて、先輩イベントであるRubyKaigiを参考にしようというわけで、自分の理解のために書くことにしました。 おことわり 私はRubyKaigi 2022のネットワークをお手伝いしましたが、ケーブルの巻き直し、APの設営、撤収時の諸々を手伝ったのみです。よってこれから言及する内容については、一般参加者に毛が生えた程度の事前知識しかありません。 またこれから読み解くコードにおいて、コメントする内容の正確性は一切ないものと思って読んでください。 RubyKaigiのネットワークについて RubyKaigiのネットワークにおけるL

                                                          RubyKaigi 2022の会場ネットワークリポジトリを読み解く | うなすけとあれこれ
                                                        • Akamai Status

                                                          Message and data rates may apply. By subscribing you agree to our Privacy Policy, the Atlassian Terms of Service, and the Atlassian Privacy Policy. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

                                                          • GitHub - natesales/q: A tiny command line DNS client with support for UDP, TCP, DoT, DoH, DoQ and ODoH.

                                                            Usage: q [OPTIONS] [@server] [type...] [name] All long form (--) flags can be toggled with the dig-standard +[no]flag notation. Application Options: -q, --qname= Query name -s, --server= DNS server(s) -t, --type= RR type (e.g. A, AAAA, MX, etc.) or type integer -x, --reverse Reverse lookup -d, --dnssec Set the DO (DNSSEC OK) bit in the OPT record -n, --nsid Set EDNS0 NSID opt --subnet= Set EDNS0 c

                                                              GitHub - natesales/q: A tiny command line DNS client with support for UDP, TCP, DoT, DoH, DoQ and ODoH.
                                                            • TechCrunch

                                                              EyeEm, the Berlin-based photo-sharing community that exited last year to Spanish company Freepik after going bankrupt, is now licensing its users’ photos to train AI models. Earlier this month,

                                                                TechCrunch
                                                              • Cloudflareにドメインを移管してみた | DevelopersIO

                                                                3. プライバシー保護 今回は個人用ドメインなのでプライバシー保護が必須でした。 Route 53、Cloudflareともにプライバシー保護に関する機能は存在するのですが、その内容は両者で異なります。 Route 53 Route 53には名前通り「プライバシー保護」機能がありドメインの連絡先情報を「レジストラの情報に置き替え」または「REDACTED FOR PRIVACYで置き替え」してくれます。 どちらの方法で置き換えられるのかはAWSにより自動的に決められます。 ドメインの連絡先情報のプライバシー保護の有効化/無効化 ただし、保護される内容はTLDにより異なるため都度ドキュメントで確認する必要があります。 今回の.techドメインでは 組織名を除くすべての情報が非表示になります。 .tech という扱いでした。 Cloudflare Cloudflareではデフォルトでプライバシ

                                                                  Cloudflareにドメインを移管してみた | DevelopersIO
                                                                • Snyk IaCでTerraformのドリフト検出をやってみた | DevelopersIO

                                                                  こんにちは!AWS事業本部コンサルティング部のたかくに(@takakuni_)です。 今回は、snyk iac describeコマンドを利用して、Terraformで作ったリソースのドリフト検出をしてみようと思います。 Snyk IaC describeコマンドとは snyk iac describeでは次の2つを検出できるコマンドです。Terraformのtfstate内のリソースとクラウドプロバイダーの実際のリソースを比較して検出するため、CloudFormationで書かれたファイルには使えません。 ドリフト(現在の状態とtfstateとの差異を検出) 該当リソースがIaC(Terraform)で管理されているかどうかを検出 今回は1つめのドリフトを検出してみようと思います。 やってみた 今回は次のコードを使用してドリフト検出を試してみようと思います。 注目いただきたいのが、「en

                                                                    Snyk IaCでTerraformのドリフト検出をやってみた | DevelopersIO
                                                                  • DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 〜前編〜 | さくらのナレッジ

                                                                    長野雅広といいます。 Twitter / GitHub は @kazeburo というIDでやっておりますので、フォローいただけたらと思っております。 現在はさくらインターネット株式会社のクラウド事業本部 SRE室というところで室長を務めさせていただいております。 ずっとWebアプリケーションの運用やSREをやっておりまして、ISUCONの本を書いたりもしているのですけれども、JANOGは実は初めての参加になりますので、ぜひよろしくお願いいたします。 今回は、DNS権威サーバのクラウドサービス向けに行われた攻撃および対策について、お話しさせていただきます。 SRE室の取り組み SRE室がどんなことをやっている部署かという話ですが、2022年7月、去年の夏に発足した、新しめの部署になります。ミッションとして、クラウドサービスの信頼性を高めるとか、お客様や社会のDXをしっかり支えるということを

                                                                      DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 〜前編〜 | さくらのナレッジ
                                                                    • “ドメイン名の終活”ちゃんとやってる? DNSの基本的な話から突っ込んだ話まで、無料で聴けるイベントが6月24日開催 「DNS Summer Day 2022」オンライン聴講の参加申し込み受付中

                                                                        “ドメイン名の終活”ちゃんとやってる? DNSの基本的な話から突っ込んだ話まで、無料で聴けるイベントが6月24日開催 「DNS Summer Day 2022」オンライン聴講の参加申し込み受付中
                                                                      • リモートワーク文脈で超低コスト擬似DNSを社内で提供しました。 - エニグモ開発者ブログ

                                                                        こんにちは、インフラチームの加藤です。 この記事は Enigmo Advent Calendar 2020の23日目の記事となります。 本記事では、リモートワーク環境のため、擬似DNSを社内提供したお話をします。 エニグモでは、今年の2月頃から全社的にリモートワークを開始しました。 それに伴いインフラチームでは、リモートワークのネットワーク周りの対応を行いました。 エニグモが運用しているサーバ群 エニグモの運用するサーバは、データセンター内に構築したものとAWSのものがあります。 情シスの足立さんが、SaaS導入を進めて下さったためオフィス内にサーバはほぼありません。 サーバへの疎通経路 オフィス・リモート環境共にVPN経由(+ファイアウォール)で、サーバ群へアクセス可能です。 リモートワーク開始後のサーバアクセスの問題 リモートワーク開始直後から、ネットワーク設定に関するお問い合わせと、

                                                                          リモートワーク文脈で超低コスト擬似DNSを社内で提供しました。 - エニグモ開発者ブログ
                                                                        • Doggo

                                                                          Features Human-readable output with color-coded and tabular format JSON output support for easy scripting and parsing Multiple transport protocols: DNS over HTTPS (DoH) DNS over TLS (DoT) DNS over QUIC (DoQ) DNS over TCP DNS over UDP DNSCrypt Support for ndots and search configurations from resolv.conf or command-line arguments Multiple resolver support with customizable query strategies IPv4 and

                                                                          • NTP.ORG.CN、サービス終了予定の福岡大学NTPサーバーなどをjp.ntp.org.cnに割り当てて使用しているとの指摘 | スラド IT

                                                                            中国で「高速で安定したNTPノードを提供する」とうたうNTP.ORG.CNが提供するノードの1つに福岡大学のNTPサーバーが含まれており、jp.ntp.org.cnに割り当てられているようだ(@tanyorgのtweet、ノード一覧ページ)。 さらに、NTP.ORG.CNでは提供終了に向けて動いている福岡大学(133.100.11.8)のほかNTT Americaの129.250.35.251が掲載されているが、これはPublic DNSではない(Aimless)。 別件として、パレスチナのISPと思われるntp.hadara.psにも福岡大学のIPアドレスが割り当てられていることも確認されている(@tanyorgの別tweet)。 過去のストーリーでも繰り返し語られているが、福岡大学やNTT AmericaのNTPサービスを関係者以外が使用することは迷惑行為であるため行ってはならない。日

                                                                            • 世界初NAT64/DNS64の実現、DNSサーバーはどう切り替えているのか? - BIGLOBE Style | BIGLOBEの「はたらく人」と「トガッた技術」

                                                                              あいさつ 平澤です。スプラトゥーン大好きエンジニアです。スプラトゥーン3のプレイ時間は500時間です🦑 今回は、『世界初への挑戦!インターネットを快適にするNAT64/DNS64とは?』をやったときに開発した技術をご紹介します。 style.biglobe.co.jp あいさつ NAT64/DNS64とは DNS64をどうやって使ってもらうか 実現したいこと 特許の概要 送信元IPアドレスを見てDNSサーバーを振り分け 実現できた もしもユーザーのDNSサーバーを自由に振り分けできたら BIGLOBEの特許出願事情 おわりに NAT64/DNS64とは BIGLOBEは快適なIPv6でのインターネット接続をおすすめしています。既存技術では、MAP-E機能付きのブロードバンドルーターがユーザーの負担となっていました。 ユーザーの負担が無いIPv6接続「NAT64/DNS64」で多くのユーザ

                                                                                世界初NAT64/DNS64の実現、DNSサーバーはどう切り替えているのか? - BIGLOBE Style | BIGLOBEの「はたらく人」と「トガッた技術」
                                                                              • Xユーザーのmipsparc@技術書典え19さん: 「【PyCon APAC 2023においてフリーWiFi使用者のDNS問い合わせが公にされていた件について私が行った問題提起についての謝罪】 問題提起したことについて、技術コミュニティに対する破壊行為であるとのご指摘が、PyCon JPスタッフをはじめ、様々な方から有形無形で寄せられました。また、もうスタッフをやらないとのお声や、本件とは無関係の私の過去の労働争議についての言及、リプライやDM等での中傷など、いち個人では到底抱えきれなくなったため、問題提

                                                                                • Route53にてDNS切り替え時の反映タイミングを検証してみた | DevelopersIO

                                                                                  こんにちはカスタマーソリューション部のこーへいです! 今回はRoute53のDNS切り替え作業時に、ドメインが新しいネームサーバーのAレコードを参照し、切り替えが反映されるまでの時間を検証してみました。 検証前までは反映タイミングは各レコードのTTLのみに依存するかと想定しておりましたが、実際はそうではなかったです。 結論 ドメインのネームサーバーを切り替えの反映には3つの要素を満たさなければならない NSレコードのTTLが切れること 名前解決に使用するネームサーバーを切り替え前から切り替え後のものを参照するようにさせるため NSレコードのTTLが切れないと、いつまでも切り替え前のネームサーバーからAレコードを取得してしまう AレコードのTTLが切れること 切り替え先のネームサーバーに登録されているAレコードの情報を取得するため AレコードのTTLが切れないと、いつまでもDNSキャッシュサ

                                                                                    Route53にてDNS切り替え時の反映タイミングを検証してみた | DevelopersIO