パスワードを忘れた? アカウント作成
13566121 story
インターネット

Cloudflare、APNICと協力してパブリックDNSサービス「1.1.1.1」を立ち上げ 74

ストーリー by hylom
検閲には協力するのだろうか 部門より

APNICとCloudflareがパブリックDNSサービスを開始した(公式サイトCloudflareの発表AMWINTERNET Watch)。

このパブリックDNSサービスは「1.1.1.1」および「1.0.0.1」というIPアドレスで提供されており、一般的なDNSサービスよりも高速で、かつプライバシー保護のために利用者のIPアドレスを記録しないとうたっている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • どっちにするんだ? (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2018年04月02日 19時33分 (#3386711)

    イチかバチかの選択だな

  • 1.1.1.1は、Cisco Wireless LAN Controllerとバッティングしてるらしい。
    https://twitter.com/whywaita/status/980723338413711365 [twitter.com]
    https://twitter.com/kuro_m88/status/980729190780567552 [twitter.com]
    https://twitter.com/kuro_m88/status/980729804432424965 [twitter.com]

    • ApresiaやALAXALAのネットワーク認証機能だと、認証サーバの設定例として 1.1.1.1 を使っているようですね。Cisco の真似だったのかな。
      親コメント
    • by Anonymous Coward

      1.0.0.0/8を解放する際に1.1.1.0/24と1.2.3.0/24は使わないことが決定したから、
      プライベートアドレスとはバッティングしないアドレスとして使われたんだろうね。

      まぁ、パブリックDNSは使えなくたって実害はないと考えることも出来るので諦めるしかないよね。

      • by Anonymous Coward

        「APNICと協力」ってのは、使わないことに決定したはずのアドレスを特例的に割り当ててもらった点だね。

        • by Anonymous Coward

          協力できた理由はゴミトラフィックが多かったせいで、協力の対価がゴミトラフィックの監視と統計みたいですね。
          1.1.1.1を使用するように説明しているドキュメントが多かったからこのようなことができたのかも?

        • by Anonymous Coward

          >特例的に割り当ててもらった点だね。

          割り当ててません。
          APNIC はアジア太平洋地域の管轄なので、
          使わないことに決定したはずのアドレスだろうがそうでなかろうが、
          アメリカ企業に割り当てることはありません。
          whois を見ればわかりますが、該当アドレスは現時点でも APNIC が保有してます。

      • by Anonymous Coward

        クライアントだけでなく、1.1.1.1が他のDNSサーバに問い合わせるときに、経路途中で不正なパケットとして落とされたりしないんだろうか

  • by minet (45149) on 2018年04月02日 20時47分 (#3386751) 日記

    https://1.0.0.1/ja-jp/ [1.0.0.1]
    https://1.1.1.1/ja-jp/ [1.1.1.1]

    こんだけ覚えやすいとドメイン名も要らないな。

    • by Anonymous Coward on 2018年04月02日 20時50分 (#3386756)

      DNSサーバーを提供するサービスの情報がDNSに頼るわけにもいかんじゃろ

      親コメント
    • by Anonymous Coward

      逆に、ホスト名の方を見慣れてると、1.1ってドメイン怪しすぎなんですけど〜とか言われないかな。

    • by Anonymous Coward

      Windows 7/8.1のIE11で開くと、
      subjectAltNameのIPAddressに対応していないのか
      不正な証明書であるとして表示できないですね。

      • by Anonymous Coward

        Windows 10だとたしかに問題ない。IEのSSL周りはschannelというOSのコンポーネントでIEには属さないから同じバージョンのIEでもOSによって異なるんだよな。
        なおsubjectAltNameが実際はIPアドレスなのにdNSNameという証明書はBR違反なので、取得不可能なはず

  • 1.1.1.1 はプライバシーを重視するため、EDNS Client Subnet には非対応 [cloudflare.com] なようです。

    1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers

    CloudFlare, Amazon CloudFront, Akamai などの CDN は、DNS 問い合わせに対して地域によって異なるIPアドレスを返すことで地理的に近いサーバに接続させる仕組みになっているわけですが、EDNS Client Subnet 非対応だとエンドユーザの地域 (IPアドレスの一部) が判別できないため、CDN を使っているサイトに接続する際には遠いサーバに繋がって「遅く」なることがあります。

    速さが目的なら、EDNS Client Subnet に対応している Google Public DNS (8.8.8.8) を使うか、素直に ISP の DNSサーバを使い続けるのが良いでしょう。

    • by Anonymous Coward

      それは権威サーバーにリクエストを送る必要がある場合でしょ? Google Public DNS同様にキャッシュしてるんじゃないの?

    • by Anonymous Coward

      調べもせずに半可通ぶるのはやめろ。

      google public dnsは8.8.8.8なフロントサーバ群は世界各地に分散配置してanycastしてたけど、
      権威サーバに対して反復検索するバックエンド群は少ない拠点に集約するといういびつな構成だったので、
      geolocation対応のCDNがバックエンドには近いけどクライアントからは遠いサーバを応答してくることがあった。

      1.1.1.1はちょっと調べたところではフロントエンドもバックエンドも同じところに配置されてる気配が濃厚。
      バックエンドとクライアントがはじめから近いところにいるので、
      ECSを使わなくてもCDNが遠いサーバを返答してくることはない。

      • by Anonymous Coward


        1.1.1.1がかつての8.8.8.8と同じように、遠いサーバを応答してくるという話じゃなくて、
        EDNS Client Subnet に対応しているDNSのほうがより早いって事じゃないの?

  • by Anonymous Coward on 2018年04月02日 19時15分 (#3386705)

    APNICが保有する1.1.1.1と1.0.0.1は、多くの人がテストなどでランダムなシステムに入力するため、絶えず大量の無意味なトラフィックにさらされているという。

    http://www.itmedia.co.jp/news/articles/1804/02/news074.html [itmedia.co.jp]

    でも、DNSとしての例示はそう簡単に見つからないだろうと検索してみた。

    nameserver 1.1.1.1 ←DNSサーバーじゃない

    https://blog.trippyboy.com/2011/google/google%E6%8F%90%E4%BE%9B%E7%84%... [trippyboy.com]

  • by Anonymous Coward on 2018年04月02日 18時11分 (#3386659)

    1.1.1.1 の ping 統計:
            パケット数: 送信 = 30、受信 = 30、損失 = 0 (0% の損失)、
    ラウンド トリップの概算時間 (ミリ秒):
            最小 = 33ms、最大 = 68ms、平均 = 38ms

    8.8.8.8 の ping 統計:
            パケット数: 送信 = 30、受信 = 30、損失 = 0 (0% の損失)、
    ラウンド トリップの概算時間 (ミリ秒):
            最小 = 24ms、最大 = 44ms、平均 = 26ms

    • Re:うーん (スコア:4, すばらしい洞察)

      by Anonymous Coward on 2018年04月02日 19時34分 (#3386713)

      なぜping?

      $ ping 1.1.1.1
      [略]
      rtt min/avg/max/mdev = 5.690/6.098/6.300/0.240 ms

      $ ping 8.8.8.8
      [略]
      rtt min/avg/max/mdev = 5.191/5.423/5.935/0.302 ms

      $ time dig @1.1.1.1 google.com
      ; > DiG 9.10.3-P4-Ubuntu > @1.1.1.1 google.com
      [略]
      real 0m0.042s

      $ time dig @8.8.8.8 google.com
      ; > DiG 9.10.3-P4-Ubuntu > @8.8.8.8 google.com
      [略]
      real 0m0.078s

      8.8.8.8よりは速そう

      親コメント
    • by fukapon (4131) on 2018年04月02日 18時44分 (#3386677) ホームページ

      ISP提供も1.1.1.1も8.8.8.8も30ms程度だった。んー。

      親コメント
    • まず、Google Public DNSは内部処理の都合遅延がちょっとある(要出展)という話があるので、そことの比較の問題があるだろうと思う。

      あと、IPoE IPv6環境でIPv6 DNSサーバでやってみたら、以下のようになった

      *** Cloudflare DNS
      $ ping 2606:4700:4700::1111

      Pinging 2606:4700:4700::1111 with 32 bytes of data:
      Reply from 2606:4700:4700::1111: time=8ms
      Reply from 2606:4700:4700::1111: time=5ms
      Reply from 2606:4700:4700::1111: time=6ms
      Reply from 2606:4700:4700::1111: time=6ms

      Ping statistics for 2606:4700:4700::1111:
              Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
      Approximate round trip times in milli-seconds:
              Minimum = 5ms, Maximum = 8ms, Average = 6ms

      *** Google Public DNS
      $ ping 2001:4860:4860::8888

      Pinging 2001:4860:4860::8888 with 32 bytes of data:
      Reply from 2001:4860:4860::8888: time=6ms
      Reply from 2001:4860:4860::8888: time=5ms
      Reply from 2001:4860:4860::8888: time=5ms
      Reply from 2001:4860:4860::8888: time=6ms

      Ping statistics for 2001:4860:4860::8888:
              Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
      Approximate round trip times in milli-seconds:
              Minimum = 5ms, Maximum = 6ms, Average = 5ms

      自分の環境の影響はそこそこ効いてきそうですね...

      --
      M-FalconSky (暑いか寒い)
      親コメント
    • by Anonymous Coward

      1.1.1.1 の ping 統計:
              パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
      ラウンド トリップの概算時間 (ミリ秒):
              最小 = 6ms、最大 = 7ms、平均 = 6ms

      8.8.8.8 の ping 統計:
              パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
      ラウンド トリップの概算時間 (ミリ秒):
              最小 = 7ms、最大 = 10ms、平均 = 8ms

      びみょー

    • by Anonymous Coward

      1.1.1.1 の ping 統計:
              パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
      ラウンド トリップの概算時間 (ミリ秒):
              最小 = 11ms、最大 = 12ms、平均 = 11ms

      8.8.8.8 の ping 統計:
              パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
      ラウンド トリップの概算時間 (ミリ秒):
              最小 = 12ms、最大 = 12ms、平均 = 12ms

      回線はソフトバンク光の1Gbps。
      まあ、どこからでも絶対に早いって保証なんて無理だろうしなぁ。

  • by Anonymous Coward on 2018年04月02日 18時24分 (#3386667)

    疑いだしたらキリがないですが
    こういうのを素直に信じられなくなりました
    ※契約プロバイダーのDNSが一時期不安定になって8.8.8.8使ってるから今更なんですが

    • by Anonymous Coward on 2018年04月03日 0時22分 (#3386847)

      Cloudflareすら信じられないのならウェブブラウザーを使ったらいかんと思うよ。割とマジで。

      親コメント
    • by Anonymous Coward

      どうせなら、Googleじゃない方にたまる方がいいかな、というのはある。
      ちょっとGoogleにデータ預けすぎ感が。なので、GoogleHomeも興味あるけどEcho使ってる。

      そこまでGoogleが嫌いなわけじゃないけど、気持ち悪さはある。想像以上のことまで知られてんだろうなぁ。

      • by Anonymous Coward on 2018年04月03日 9時37分 (#3386943)

        リスクを分散するのも手かもしれないが、比較的ましなところへまとめて預けるのも手だと思う。
        Google様に預かって頂いてるデータはアクティビティ管理で見れるが、Amazonなんて何を取得してるのかわかったもんじゃないし、削除したくてもコントロールできない。

        親コメント
    • by Anonymous Coward

      提供時は信じていいと思いますよ。
      ただ、普及してから告知したうえで変える可能性は否定できないですが。

  • by Anonymous Coward on 2018年04月02日 18時58分 (#3386690)

    DNSサーバを利用したことによるプライバシーと言われてもねぇ。
    (そういう事に文句付ける輩・団体のための措置なのかも知れませんが)

  • by Anonymous Coward on 2018年04月02日 19時28分 (#3386707)

    Google Public DNSの紹介・推奨記事は、ISPのDNSの使用をやめて、Google Public DNSだけを使用する記事ばかりな気がする。
    自分は、ISPのDNSが障害を起こした時に備え、Public DNSをバックアップとして設定してる。

    具体的には、使用している家庭用ルーターのDNS設定は、自動か手動で2つしか設定できない。
    だから、ルーターはISPの2つを自動設定にして、PCはルーターのDNSを最優先にしてPublic DNSを複数追加設定してる。

  • by Anonymous Coward on 2018年04月02日 21時22分 (#3386773)

    au.download.windowsupdate.com とかは国内のサーバを返してくれている模様
    round-trip min/avg/max/stddev = 4.668/9.502/20.120/5.285 ms

    www.google.com は西海岸のサーバに繋がってしまう模様
    round-trip min/avg/max/stddev = 238.061/238.471/239.327/0.508 ms

  • by Anonymous Coward on 2018年04月02日 22時33分 (#3386807)

    1.1.1.1
    ::ffff:101:101

    1.0.0.1
    ::ffff:100:1

    • by Anonymous Coward

      For IPv4: 1.1.1.1 and 1.0.0.1
      For IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001

  • by Anonymous Coward on 2018年04月02日 22時41分 (#3386810)

    自宅にフルリゾルバの1つや2つあるでしょ?

    • by Anonymous Coward

      unbound が動いているサーバが2台あるので、
      もう長いこと宅外のキャッシュサーバを使ってないな。

      2つの VPS に NSD 載せて動かしているコンテンツサーバも
      unbound と同居させててリゾルバはそれ使わせてるから
      やっぱり外部のキャッシュサーバは使ってない。

typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...