Amazon Route 53 信頼性が高く、費用対効果に優れた方法でエンドユーザーをインターネットアプリケーションにルーティングする
Amazon Route 53 信頼性が高く、費用対効果に優れた方法でエンドユーザーをインターネットアプリケーションにルーティングする
今月中旬に、トルコ政府によるTwitter利用禁止措置をかいくぐるためにGoogle Public DNSが利用されているという記事がありました(参考)。 政府に対抗するために、Google Public DNSのIPv4アドレスである「8.8.8.8」が町中に落書きされていたようです。 しかし、そのGoogle Public DNSの成り済ましサーバがトルコ国内のほとんどのISPで運用されているとGoogleが発表しました。 Google’s Public DNS intercepted in Turkey そこでは、次のように書かれています。 But imagine if someone had changed out your phone book with another one, which looks pretty much the same as before, except
/etc/resolv.conf を編集しても上書きされてしまう。 lrwxrwxrwx 1 root root 29 5月 30 14:11 resolv.conf -> ../run/resolvconf/resolv.conf/etc/network/interfacesにdns-nameserversとして記述してしまう。 $ sudo vim /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loop
ども。こんばんは。 別にFortiGateあんまり関係ないのですが・・・。 ちょっと最近混雑する時間帯のOCNの速度が全然出ないのでDS-Liteにでも手を出そうかなと思っていろいろ調べています。 ただ、OCNのIPoE方式は、我が家にはまだ対応していない模様。 OCN IPv6インターネット接続機能(IPoE) 今後の提供予定について どうやら、「2017年7月24日以前にOCN 光をご利用開始したお客さま、2017年8月31日以前にOCN for ドコモ光をご利用開始したお客さま、2018年6月14日以前にOCN 光 with フレッツをご利用開始したお客さま」はまだ未対応らしい?です。 うーん。InterlinkのZOOT Nativeにでも契約してやろうかな。。。 さて、DS-LiteというかIPoE?を使ってVNEから出ていくためには、フレッツ・v6オプションとやらに申し込む必要
なんか接続が遅いなーと思いつつ、放置していた件。 接続一発目が遅いときの一番の原因は大概、DNSだったりするのだが、よくわからんまま放置モードが続いていた。 まあ、ログにも managed-keys-zone: No DNSKEY RRSIGs found for ‘.’: success とか出てたので多分DNSSECおかしいんだろうなーとは思っていたw ざっくりすると、ローカルの設定はそれなりに良かったぽい。 上流のDNS (forwarders) がDNSSEC未対応のため、というのが理由っぽい。 できればDNSはipv6経由でやりたいのだが、そういうわけにもいかない場合もあるということで。 とりあえず、ひかり電話ありのONUはDNSSEC対応っぽい。 ひかり電話なしのONUは対応していなかった。 ついでにBiglobeのDNSはDNSSEC対応とそうじゃないのがあるようで、bind
明けましておめでとうございます。 〜〜 2018.1.4 追記 以下、嘘になっちゃった内容があります〜〜 よく考えたら、bind の root ヒントファイルって、インストール時のそのままなんだよね。 インストール時のファイルが古いってだけだったので、root とかは全然間違ってなかった。 新年早々、失敗失敗…… 〜〜 2018.1.4 追記ここまで 〜〜〜 以下、嘘の情報がありますが自身の失敗を反省するため残しておきます。 昨年末は、いつの間にか自宅ローカルネットワークの NTP サーバが停止していたので、年末年始は実家からリモートで自宅ネットワークのログ監視システムを構築してました。 いや、いまも手探りで構築中なわけですが。 OpenVPN って、偉大。 それはともかく、他にエラーが無いかなって思って、ログを grep した結果。 daemon.log:Dec 31 10:17:13
2018年4月11日2019年1月30日 BINDのログに「unexpected RCODE ・・・」のようなログが大量に記録される 環境 Red Hat Enterprise Linux Server release 7.2 (Maipo) bind-chroot-9.9.4-51.el7_4.2.x86_64 問題 BINDのログに下記のようなログが大量に記録される 最悪の場合、ログがあふれる。 named[PID]: error (unexpected RCODE REFUSED) resolving named[PID]: error (unexpected RCODE SERVFAIL) resolving named[PID]: error (unexpected RCODE FORMERR) resolving 原因 自サーバのBINDが名前解決をしようとしたら予期しない
別名に対する正式名を指定するためのリソースレコードです。 ホスト名には、「canonical name(正式名)」以外に、「aliases(別名)」を付けることができます。DNSの名前解決では、CNAMEリソースレコードが見つかった場合、ドメイン名を正式名に置き換えて名前解決を継続します。ある別名に対する正式名は常に一つであるため、一つの別名に対し、正式名を二つ以上指定することはできません。 CNAMEリソースレコードは、以前はホスト名に別名を付ける手段として使われていました。現在では主にCDN (Contents Delivery Network)や、/24未満のIPv4アドレスの逆引きを設定する際に使われています。 別名は、例えば1台のサーバーで複数のサービスを提供している場合に、サービスごとにサーバーの名前を変えるときに使用します。サーバーの正式なドメイン名はservice.exam
ブラウザのアドレスバーで検索できて便利やん。でもね、会社でつかうのはやめとき。 mDNSで同じLAN居る人全員に、このアドレス知りませんか?って検索ワードで聞きおるで。 Firefoxは検索窓がアドレスバーの右にあるからアドレス… https://t.co/zhn1fKxxe2
最終更新日:2019/02/25 | すべてのドキュメントを読む 注意: このページが翻訳された後、英語バージョンのページがアップデートされています。 (2020/12/08) 英語で表示する Let’s Encrypt から証明書を取得するときには、ACME 標準で定義されている「チャレンジ」を使用して、証明書が証明しようとしているドメイン名があなたの制御下にあることを検証します。ほどんどの場合、この検証は ACME クライアントにより自動的に処理されますが、より複雑な設定を行った場合、詳細な仕組みについて知っておくと役に立つはずです。よく分からない場合には、クライアントのデフォルトの設定か、HTTP-01 を使用してください。 HTTP-01 チャレンジ 現在、最も多く使われているチャレンジです。Let’s Encrypt は ACME クライアントにトークンを発行し、ACME クライ
DNS サーバの BIND に、複数の脆弱性が存在します。 この脆弱性が悪用された場合、負荷上昇によるパフォーマンスの低下やリフレクション攻撃の踏み台として悪用されるなどの影響の他、意図しないサービスの停止が発生する可能性があります。 脆弱性を悪用した攻撃はまだ確認されていませんが、今後攻撃が発生する可能性があるため至急 DNS サーバ管理者はアップデートを適用して下さい。 9.16系列:9.16.0~9.16.2 9.14系列:9.14.0~9.14.11 9.12系列:9.12.0~9.12.4-P2 上記以外の系列:9.0.0~9.11.18 ※ 上記バージョン以外でも脆弱性の影響を受ける可能性があります。詳細はベンダに確認してください。 ※ ベンダはサポートを終了した系列のセキュリティパッチはリリースしないと発表しています。
本特集では、次世代DNSサーバソフトウェア「Unbound」にフォーカスし、機能や特徴を解説しながら、実際の運用ノウハウについてお届けします。第1回目はUnboundの基礎知識について解説します。 Unboundの概要 UnboundはBINDの代替を目指したDNSキャッシュサーバです。2008年5月20日に正式版1.0がリリースされました。オープンソースのソフトウェアとして公開されており、ライセンスはBSDライセンスです。 UnboundはNLnet Labsにより開発と保守が行われています。UnboundはVerisign labs、Nominet、Kirei、ep.netによりJavaで開発したプロトタイプを、NLnet LabsがCで実装し直したものです。ちなみに、NLnet Labsはルートサーバとしても利用されているDNSコンテンツサーバのNSDも開発しています。リリースされた
ドメインやホスト名に関する情報をDNSサーバから取得するコマンドといえば、やはりdigコマンドだろう。 いろいろとオプションのあるdigコマンドだが、今回は普段使ってて便利なオプションや使い方について残しておくことにする。 1.基本的な使い方 基本的には、以下のように該当のドメインを指定して名前解決をする際に利用する。 dig ドメイン名 blacknon@BS-PUB-UBUNTU-01:~$ dig orebibou.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> orebibou.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59998 ;; flags: qr rd ra ad; QUERY: 1, ANSWER:
注意事項 JPNICのWHOISではドメイン名関連の情報は検索できません。 JPRS WHOISをご利用ください。 利用については、WHOISとはのページもご覧ください。 検索方法や検索結果の見方の解説は以下のページをご参照ください。 JPNICのWHOIS検索へのアクセス方法 JPNICのWHOISにおけるIPアドレス検索方法 JPNICのWHOISにおけるAS番号検索方法 JPNICのWHOISにおける担当者情報・担当グループ情報検索方法
Cloudflareが以前より提供していたDNSサービス「1.1.1.1」のスマートフォンアプリ版に、安全性と高速さを高めるVPNサービス「Warp」を追加する予定だと発表しました。 Introducing Warp: Fixing Mobile Internet Performance and Security https://blog.cloudflare.com/1111-warp-better-vpn/ Cloudflare is adding a free VPN to its 1.1.1.1 app - The Verge https://www.theverge.com/2019/4/1/18290615/cloudflare-1-1-1-1-vpn-dns-resolver-security-privacy DNSサービス「1.1.1.1」に搭載されるVPNサービス「War
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く