• DOH 和 DOT
  • IPV6 协议
  • IPV6 演示
  • amp
  • dns
  • amp

  • DOH 和 DOT

    • DNS介绍

      DNS over TLS（缩写：DoT）是通过传输层安全协议（TLS）来加密并打包域名系统（DNS）的安全协议。此协议旨在防止中间人攻击与控制DNS数据以保护用户隐私。

      DNS 的分布式数据库是以域名为索引的，每个域名实际上就是一棵很大的逆向树中路径，这棵逆向树称为域名空间（domain name space）。

      基本上，所有Internet通信都依赖于域名系统（DNS），DNS首先将人类可读的Internet目的地或服务映射到IP地址，然后两个端点建立连接以交换数据。如今，大多数DNS查询和响应都是以明文形式传输的，因此容易受到窃听和流量分析的攻击。过去的工作表明，DNS查询可以揭示智能家居中从浏览活动到用户活动的所有内容。为了减轻其中一些隐私风险，已提出了两种新协议：HTTPS上的DNS（DoH）和TLS上的DNS（DoT）。这些协议不是以明文形式发送查询和响应，而是在客户端和解析器之间建立加密的隧道。这种根本的体系结构更改对DNS的性能以及内容交付都有影响。我们发现，尽管DoH和DoT响应时间可以比常规DNS（Do53）更长，但是就页面加载时间而言，DoT可以比两种协议都更好地执行，并且DoH最多只能与Do53区别开来。但是，当网络条件恶化时，使用Do53加载网页的速度最快，与DoH相比，平均速度快了将近0.5秒。此外，在很多情况下，网页可能根本无法通过DoH加载，而可以通过DoT和Do53成功加载。我们的深入分析揭示了各种机会，例如通过机会性部分响应和有线格式缓存，可以轻松提高DNS性能。

    • DOT

      DNS over TLS（缩写：DoT）是通过 传输层安全协议 （TLS）来加密并打包域名系统 （DNS）的安全协议。此协议旨在防止中间人攻击 与控制DNS数据以保护用户隐私。

      RFC 7858 及RFC 8310 定义了DNS over TLS。截至2018年，Cloudflare、Quad9与CleanBrowsing均向大众提供支持DNS over TLS的公共DNS解析服务。2018年4月，Google宣布Android P将包含对DNS over TLS的支持。PowerDNS的DNSDist也宣布在其最新的1.3.0版本中添加了对DNS over TLS的支持。BIND用户也可以通过stunnel代理提供DNS over TLS服务。

    • DOH

      DNS over HTTPS（缩写：DoH）是一个进行安全化的域名解析 的方案，当前尚处于实验性阶段。其意义在于以加密的HTTPS协议进行DNS解析请求，避免原始DNS协议中用户的DNS解析请求被窃听或者修改的问题（例如中间人攻击）来达到保护用户隐私的目的。Google及Mozilla基金会正在测试这一协议，作为其提高网络安全性的努力的一部分。

      当前，该方案由IETF支持，其规范文档以 RFC 8484 的名义发布。2018年9月5日发布的Firefox 62正式版加入了这项功能，但需要用户手动开启。

    • DOH 实施方案

      DNS over https用于DNS解析器的递归DNS解析。 解析器（DoH客户端）必须能够访问托管查询端点的DoH服务器。基于HTTPS的DNS缺乏操作系统的本机支持。 因此，希望使用它的用户必须安装附加软件。 三种使用场景很常见：

      1.在应用程序中使用DoH实现：某些浏览器具有内置的DoH实现，因此可以绕过操作系统的DNS功能来执行查询。 缺点是应用程序可能无法通过错误配置或缺乏对DoH的支持来通知用户是否跳过DoH查询。

      2.在本地网络中的名称服务器上安装DoH代理：在此方案中，客户端系统继续使用传统（端口53或853）DNS来查询本地网络中的名称服务器，然后通过到达来通过DoH收集必要的回复 互联网中的DoH服务器。 此方法对最终用户是透明的。

      3.在本地系统上安装DoH代理：在此方案中，操作系统配置为查询本地运行的DoH代理。 与前面提到的方法相反，需要在希望使用DoH的每个系统上安装代理，这可能需要在更大的环境中付出很多努力。

      4.为操作系统安装DoH解析插件

      在所有这些方案中，DoH客户端不直接查询任何权威名称服务器。 相反，客户端依赖于使用传统（端口53或853）查询的DoH服务器来最终到达权威服务器。 因此，DoH不具备端到端加密协议的资格，只有逐跳加密且仅在始终使用DNS over TLS时才有资格。

    • DNS over TLS（DoT）VS DNS over HTTPS（DoH）

      虽然这两种标准都对DNS请求进行了加密，但是两者之间有一些重要的区别。互联网工程任务组（IETF）将DNS over HTTPS定义为RFC 8484， 将DNS over TLS定义为RFC 7858和RFC 8310。通过TLS加密和身份验证，DNS over TLS使用TCP作为基本的连接协议。 而DNS over HTTPS则使用HTTPS和HTTP/2进行连接。这是一个重要的区别，因为它会影响使用的端口。 DNS over TLS有自己的端口853。DNS over HTTPS则使用端口443，这是HTTPS流量的标准端口。

      虽然拥有专用的端口听起来像是一种优势，但在某些情况下，实际上恰恰相反。DNS over HTTPS可以隐藏在其它加密流量中，但DNS over TLS请求全都来自一个唯一的端口，网络层的任何人都可以很容易地看到它们，甚至可以阻止它们。当然，无论内容还是响应，请求本身是加密的。因此，你不知道被请求的是什么，但是它们知道你在使用DNS over TLS。

      HTTPS上的DNS（DoH）是第二种IETF安全协议，用于解决DNC客户端和DNS服务器通信的安全性。DoH在IETF RFC 8484中进行了记录。TLS上的DNS和HTTPS上的DNS都提供了DNS客户端和DNS服务器之间的加密，从而实现了数据保密性和完整性。但是，DoH使用与其他HTTP-S流量相同的TCP端口，即端口443。因此，很难从其他HTTP-S流量中识别DoH。

      但是，DoH具有局限性，因为某些支持DoH的应用程序也可能故意忽略本地DNS客户端配置。例如，Mozilla的Firefox浏览器在某些版本中具有对DoH的实验性支持。 启用后，Firefox将忽略任何本地DNS配置，并通过HTTP-S直接将DNS查询发送到Cloudflare。 这会绕过任何本地安全机制，例如RPZ，并使用户的DNS解析对其IT组织而言是不透明的。 由于现在设备上的一个应用程序（即Firefox）使用与其他应用程序不同的DNS服务器，这也增加了解决DNS问题的复杂性。

      协议 端口 RFC 原理
      DNS over TLS（Dot） 853 RFC 7858
      RFC 8310       		工作在传输层，使用TCP协议来传输DNS协议
      DNS over HTTPS（Doh) 443 RFC 8484 工作在应用层，借助HTTPS/ HTTP/2来传输DNS协议

  • IPV6 协议

    • 简介

      IPv6是英文“Internet Protocol Version 6”（互联网协议第6版）的缩写，用作互联网的网络层协议。用它来取代IPv4主要是为了解决IPv4地址枯竭问题，同时它也在其他方面对于IPv4有许多改进。IPv6的设计目的是取代IPv4，然而长期以来IPv4在互联网流量中仍占据主要地位，IPv6的使用增长缓慢。在2017年7月，通过IPv6使用Google服务的用户百分率首次超过20%。

    • 可支持IPV6的操作系统

      • Windows： Windows 7、Windows 8.x、Windows 10，默认开启IPv6；
      • Linux： 内核2.6.x、内核3.x、内核4.x 已经支持IPv6（需要手动开启）；
      • iOS：IOS9开始已经支持IPv6 Only，2016年苹果已经强制要求app必须支持IPv6。

    • IPv6地址分三种类型

      • 单播地址：用来唯一标识一个接口，类似于IPv4的单播地址。发送到单播地址的数据报文将被传送给此地址所标识的接口。
        主要有三大类:

        1、可聚合的全局单播地址（Aggregatable global unicast address)

        • 可在全球范围内路由和到达的，相当于IPv4的公网地址。
        • 前三个bit是001，例如：2000::1:2345:6789:abcd（一般看到2与3开头的IPv6地址都是全局单播地址）。

        2、链路本地地址（Link-Local Address）

        • 用于同一个链路上的相邻节点之间通信，相当于IPv4里面的169.254.0.0/16地址。
        • IPv6的路由器不会转发链路本地地址的数据包。
        • 前10个bit是1111 1110 10，由于终末是64bit的接口ID，所以它的前缀总是FE80::/64
        • 链路本地地址一般是自动生成的

        3、独特本地单播地址（Unique Local Address）

        • 独特本地地址的作用类似于IPv4中的私网地址，只能在本地网络内部被路由转发而不会在全球网络中被路由转发。
        • 独特本地地址前缀FC00::/7。
      • 组播地址：用来标识一组接口（通常这组接口属于不同的节点），类似于IPv4的组播地址。发送到组播地址的数据报文被传送给此地址所标识的所有接口。
      • 任播地址：用来标识一组接口（通常这组接口属于不同的节点）。发送到任播地址的数据报文被传送给此地址所标识的一组接口中距离源节点最近（根据使用的路由协议进行度量）的一个接口。

      说明：IPv6中没有广播地址，广播地址的功能通过组播地址来实现。

    • IPv6地址的表示方法

      IPv6地址总长度为128比特，通常分为8组，每组为4个十六进制数的形式，每组十六进制数间用冒号分隔。例如：FC00:0000:130F:0000:0000:09C0:876A:130B，这是IPv6地址的首选格式。 为了书写方便，IPv6还提供了压缩格式，以上述IPv6地址为例，具体压缩规则为：

      • 每组中的前导“0”都可以省略，所以上述地址可写为：FC00:0:130F:0:0:9C0:876A:130B。
      • 地址中包含的连续两个或多个均为0的组，可以用双冒号“::”来代替，所以上述地址又可以进一步简写为：FC00:0:130F::9C0:876A:130B。
      • 需要注意的是，在一个IPv6地址中只能使用一次双冒号“::”，否则当计算机将压缩后的地址恢复成128位时，无法确定每个“::”代表0的个数。

    • IPv6地址的结构

      一个IPv6地址可以分为如下两部分：

      • 网络前缀：n比特，相当于IPv4地址中的网络ID
      • 接口标识：128-n比特，相当于IPv4地址中的主机ID

        接口标识生成方法：

        • 手工配置
        • 系统通过软件自动生成
        • IEEE EUI-64规范自动生成

        接口标识可以根据IEEE EUI-64规范将MAC地址（48bit）转化为接口ID。

        这种方式优点有：

        • MAC地址的独特性保证了接口ID的独特性
        • 设备自动生成，不需人为干预

        IPv6有三种不同类型的单播地址方案。 地址的后半部分(最后64位)始终用于接口ID。 系统的MAC地址由48位组成并以十六进制表示。 MAC地址被认为是在世界范围内唯一分配的。 接口ID利用MAC地址的这种唯一性。 主机可以使用IEEE的扩展唯一标识符(EUI-64)格式自动配置其接口ID。 首先，主机将其自己的MAC地址划分为两个24位的半部分。 然后16位十六进制值0xFFFE被夹在这两个MAC地址的两半之间，产生EUI-64接口ID。

        ipv6

        (从左数起的第7位，是U位，使用EUI-64格式的地址IPv6地址，U/L位为1，则地址是全球唯一的，如果为0，则为本地唯一)

      说明：对于IPv6单播地址来说，如果地址的前三bit不是000，则接口标识必须为64位；如果地址的前三位是000，则没有此限制。

    • 可聚合全球单播

      一般从运营商处申请到的IPv6地址空间为/48，三个最高有效位始终设置为001，再由自己根据需要进一步规划：

      ipv6

    • 本地站点地址 Site-local address

      类似IPv4中的私有地址。

      该地址以FEC0：：/10为前缀。也就是说最高10 bits固定为1111111011，紧跟在后面的是连续38 bits 的0。因此，对于站点本地地址来说，前48bits 总是固定的。在接口ID和高位48bits特定前缀之间有16bits 子网ID字段，供机构在内部构建子网。站点本地地址不是自动生成的，是手工配置的。

      站点本地地址只能够在本地或者私有环境中使用，不能访问公网。

      RFC 1884 定义了fec0::/10 地址块用于site-local地址,这些地址只能够在私有的IPv6“站点”内使用，但是草案对Site描述不清楚导致路由规则的混乱，因此RFC3879弃用了该地址块。

    • 唯一本地地址 Unique Local Address

      类似IPv4中的私有地址。

      ULA，唯一本地地址，概念上相当于私有IP，仅能够在本地网络使用，在IPv6 Internet上不可被路由。

      上面提到的站点本地地址由于起初的标准定义模糊而被弃用，而后RFC又重新定义了唯一本地地址以满足本地环境中私有IPv6地址的使用。

      在RFC4193中标准化了一种用来在本地通信中取代站点本地单播地址的类型。ULA拥有固定前缀FC00::/7，分为两块：FC00::/8暂未定义，FD00::/8定义如下：

      ipv6

      唯一本地地址具有如下特点：

      • 具有全球唯一的前缀（虽然随机方式产生，但是冲突概率很低）。
      • 可以进行网络之间的私有连接，而不必担心地址冲突等问题。
      • 具有知名前缀（FC00::/7），方便边缘设备进行路由过滤。
      • 如果出现路由泄漏，该地址不会和其他地址冲突，不会造成Internet路由冲突。
      • 应用中，上层应用程序将这些地址看作全球单播地址对待。
      • 独立于互联网服务提供商ISP（Internet Service Provider）。

    • 链路本地IPv6 单播地址

      类似于windows系统中IPv4的169.254.0.0/16地址（link-local IPv4 address）,它的有效范围仅仅在所处链路上。以FE80::/10为前缀，11-64位为0，外加一个64bits的接口标识（一般是EUI-64）。

      ipv6

    • 特殊地址

      ipv6

      如表所示，地址0:0:0:0:0:0:0:0/128不指定任何内容，称为未指定地址。 简化后，所有的0被压缩为:: / 128。

      在IPv4中，地址0.0.0.0与网络掩码0.0.0.0表示默认路由。 相同的概念也适用于IPv6，地址0:0:0:0:0:0:0:0，网络掩码全0表示默认路由。 应用IPv6规则后，此地址压缩为:: / 0。

      IPv4中的环回地址由127.0.0.1到127.255.255.255系列表示。 但在IPv6中，只有0:0:0:0:0:0:0:1/128表示环回地址。 环回地址后，可以表示为:: 1/128。

    • 与IPV4区别

      IPv6报文头部更精简了，字段更少了，对比起IPv4，有以下几个地方值得注意：

      • IPv6报文头部是定长（固定为40字节），IPv4报文头部是变长的。这个意味着，写代码处理IPv6数据报文的效率会提高很多）。
      • IPv6中Hop Limit字段含义类似IPv4的TTL。
      • IPv6中的Traffic Class字段含义类似IPv4中的TOS（Type Of Service）。
      • IPv6的报文头部取消了校验和字段：取消这个字段也是对IPv4协议的一个改进。当IPv4报文在网路间传输，每经过一个路由器转发就是修改TTL字段，就需要重新计算校验和， 而由于数据链路层L2和传输层L4的校验已经足够强壮，因此IPv6取消这个字段会提高路由器的转发效率。值得一提的是，在IPv6协议下，传输层L4协议UDP、TCP是强制需要进行校验和的（IPv4是可选的）。
      • IPv6报文头部中的Next Header字段表示“承载上一层的协议类型”或者“扩展头部类型”。
      ipv6 ipv6

      这里的含义与IPv4有很大的差别，需要加以解释：

      • 当IPv6数据报文承载的是上层协议ICMPv6、TCP、UDP等的时候，Next Header的值分别为58、6、17，这个时候和IPv4报文头部中的Protocol字段很类似。
      • 当不是以上3种协议类型的时候，IPv6报文头部紧接的是扩展头部。扩展头部是IPv6引入的一个新的概念，每个IPv6的数据报文可以承载0个或多个扩展头部，扩展头部通过链表的形式组织起来。当IPv6数据报文承载着扩展头部的时候，Next Header的数值为扩展头部的类型值。
      • 为什么要引入扩展头部这个概念，这里也是IPv6对IPv4改进的一个方面，用扩展头部取代了IPv4的可选项信息，精简了IPv6的头部，增强了IPv6的扩展性。

  • IPV6 演示

    说明：IPV6和SSL证书之间没有直接关联关系，访客只需要确认自己的客户端浏览器支持IPV6 即可访问IPV6的网站。而网站建设者也只需要保证自己网站有AAAA解析记录解析到了IPV6上，那么则可以让外部访客通过IPV6来访问自己的网站。当一个域名同时解析到了A记录和AAAA记录，那么访问的时候优先选择解析AAAA记录访问IPV6的地址。

    • 确认 Linux 是否支持 IPV6

      1、 使用 ifconfig 查看自己的 IP 地址是否含有 IPv6 地址。

      ipv6

      2、 查看服务监听的 IP 中是否有 IPV6 格式的地址：netstat -tuln

      ipv6

    • 确认 Windows 系统是否支持 IPV6

      可以通过 cmd 输入 ipconfig 指令查看

      ipv6

    • 确认 Nginx 系统是否支持 IPV6

      说明：Nginx从0.7.36之后开始支持IPv6。

      1、先在终端下输入指令：Nginx -V ，看看输出结果有没有–with-ipv6，没有的话就需要重新编译带有ipv6支持的nginx了。

      2、配置文件修改

      • 同时监听IPv4和IPv6地址
        编辑/etc/nginx/conf.d/default.conf，将server段的listen语句改成： 
        listen [::]:80;

        • 说明：从Nginx 1.3 的某个版本起，默认ipv6only是打开的，也就是上面的语句只会监听IPv6的端口而不会监听IPv4的端口。虽然Linux系统默认是监听IPv6的某个端口会同时监听对应的IPv4的端口，但是FreeBSD是默认分开IPv6和IPv4的。所以为了一致性的考虑（新版本Nginx必须推荐这样做），请使用分开监听的方法：

      • 单独监听IPV6，不监听IPV4 
        listen [::]:80 default ipv6only=on;
      • 监听一个特定的IPV6地址 
        listen [2607:f0d0:1002:51::4]:80;
      • 配置SSL证书，监听https 443端口 编辑原先监听https 443端口的配置文件，如/etc/nginx/conf/nginx.conf，修改listen语句为： 
        listen [::]:443 ssl;

      3、修改完成后，必须使用以下指令重启nginx服务（reload是不行的）

      service nginx restart

    • 确认 Apache 系统是否支持 IPV6

      说明：Apache 2.0版本开始支持IPv6。

      • 打开配置文件 
        # vi httpd.conf
      • 找到如下代码 
        Listen 1.2.3.4:80
      • 添加以下代码 
        Listen [2607:f0d0:1002:11::4]:80
      • 重新启动Apache 
        # service httpd restart

    • 确认 IIS 系统是否支持 IPV6

      说明：windows server 2003开始支持IPV6，需要自行安装 “Microsoft TCP/IP 版本6”。

      在域名网站绑定时，不设定ip地址就可以通过ipv6地址进行访问

      ipv6