DNS cookie 初探[B君笔记][博客]

noscript{position: fixed}DNS cookie 初探dnsphpdns cookie创建时间：2023-04-08 22:13:11

我的理解

对比下http cookie，其相同的地方是可以用来标记、跟踪用户。
常见的，http cookie 工作范围的基础单位是单个浏览器，无法跨匿名模式，跨浏览器。
dns cookie 的工作单位是DNS服务器，如果在家庭环境，一般是路由器或者光猫。如果分配的是公网地址，那么此时刚好对应的这个IP。（当然，在部分情况下，有可能其他用户也和你从同个公共dns服务器返回解析内容，那么此时，会得到同个标记。）

http cookie

存放位置：浏览器
有效期：由cookie expire 控制或者被手动清除
更新：可以有服务器主动下发新的cookie以进行更新

dns cookie

存放位置：浏览器host cahce、本地DNS缓存、路由器DNS缓存等
有效期：由DNS TTL控制或手动清除
更新：无法主动更新，只能等记录失效

基于ipv6地址的实现

http://dnscookie.com/ 演示的是ipv4版本，文中提到一个/64 的ipv6 网段，只需要一个请求就可以识别，引起了我的兴趣。

思路

刚好手里有一个服务器，服务商给我分配了一个/64的ipv6地址段，这个网段有18,446,744,073,709,551,616个ip地址。
把这些地址都分配一个机器上，有请求过来则返回对应的 ipv6地址，并把请求地址和ipv6地址关联。
把一个域名如 dnscookie.bjun.tech 通过自建dns服务器，响应其中的一个ipv6地址。
当用户访问时，域名被解析，之后在DNS缓存的情况下，该用户将会访问缓存中的ipv6地址。
在正常情况下，用户在不同dns服务器解析下同时解析到一个ipv6的可能性几乎为0。

一些细节

自建dns服务器
之前刚好有做过尝试，见php实现简单的dns服务。其中随机生成ipv6地址代码如下：

$ip = '2602:ff62:fff:4082:'.dechex(rand(0,65535)).':'.dechex(rand(0,65535)).':'.dechex(rand(0,65535)).':'.dechex(rand(0,65535));

配置ipv6地址
默认配置的一个 2602:ff62:fff:4082::/64 地址，需要把其他ipv6地址也加入网卡才能被访问，全部添加我是不会的，这里我直接在随机生成ipv6地址后直接添加进网卡。（不确定添加多了会发送什么。）添加命令如下：
```
ip addr add {{ipv6}}/128  broadcast {{gateway}} dev eth0
```
获取接受请求的ipv6地址
由于使用了caddy作为web服务器，在获取接收请求的ipv6地址上有些困难，这里直接在caddy 前面做了tcp 转发，由php 接受tcp 请求后获取接入地址，再传递给php-fpm.

demo

dnscookie ipv6 demo

需要网络支持ipv6才能访问

更新记录：

2023年4月12日
增加缓存记录和cookie用于测试模拟关联
主要是2个逻辑，以ip记录访问的dnscookie,以dnscookie记录USER AGENT
2023年4月11日
创建文件实现基础功能

一些测试

wifi : win10(chrome) + win10 (chrome private) + win10 (firefox) + iphone (safari)
dnscookie一致。由路由器的dns缓存的提供解析记录。
chrome with proxy
dnscookie变了。使用代理后，由代理网络出口的dns服务器同个解析记录，在断开proxy后，会变回原理的值。
wifi + 4g
dnscookie变了。并且在4g环境下，不同浏览器dnscookie会出现不同，原因应该是基站设置的是公共dns，并没有直接提供dns缓存服务。
wifi + 8.8.8.8
dnscookie变了。在网卡中设定dns服务器为8.8.8.8 和2001:4860:4860::8888。chrome 和 chrome private 返回值不一致。
chrome + safe dns
dnscookie变了。chrome 和 chrome private 返回值不一致。
chrome + vpn
没找到支持ipv6的vpn，先留个坑

一些感受和结论

优点

不依赖浏览器，清除缓存和cookie，不会影响结果
同设备下可以开应用关联
wifi环境下可以多设备关联

会影响dnscookie值的情况

浏览器的host cache
例如同个手动清除，浏览器内访问依然会是旧值。该缓存时间约60s。参考Chromium’s DNS Cache
切换网络，如重新拨号，wifi 改为移动网络
修改dns服务器地址
比如在浏览器配置中开启安全dns、在网卡选项中指定dns地址
使用代理工具
超过解析记录的有效期
用户直接配置了公共的dns服务器地址
由于大部分公共dns服务器是使用任播，每次查询返回的服务器大概率是不一样的。才场景测试方式是使用匿名浏览模式或者清除浏览器host cahce 访问，就会发现返回值不是固定的，会在几个地址内重复。

缺点

ipv4实现麻烦
如果使用ipv4需要多个ip地址或多次请求，并且请求失败或者被拦截，则结果会不同
用户不精准
用户请求的公共DNS并不会固定，且公共DNS也会为不同的人提供解析服务
不确定性
主要取决于用户的网络配置，但这不是固定的且不可控。比如在移动网络环境或者用户使用了多个公共的dns服务器，那么dnscookie会几乎失去价值。
过期时间不可控
取决于dns服务器配置，例如:
- 我的电脑本地dns会限制在3h ,获取方法如下：
```
ping dnscookie.bjun.tech 
ipconfig /flushdns
ipconfig /displaydns > a.txt 
```
- 国内的部分dns服务器会最长限制1d 获取方法如下：
```
nslookup -d dnscookie.bjun.tech dnsserver
```
- 而google dig,和谷歌的公共dns，如 8.8.8.8 返回的是6h。
```
nslookup -d dnscookie.bjun.tech 8.8.8.8
```

以上是对自己思考和测试的记录，相比dnscookie.com中提到的，这里只是做了一点点尝试。例如： “Depending on how a system is configured, a DNS cookie may not change when a user’s IP address changes, such as when they connect to a VPN.” 这里的vpn 情况并未做尝试和验证，这里应该和DNS泄露检测相似，不过目前了解的大部分VPN都有房DNS泄露。
另外提到的各种想法拓展，可能能提高dnscookie的实用价值。

其他

似乎域名的 NS TTL会影响解析结果的缓存时间。如下文中的 AUTHORITY RECORDS，在修改之前为 300 ,即5分钟。时间到了支持再次查询会更新dns记录

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 1,  additional = 1

    QUESTIONS:
        dnscookie.bjun.tech, type = AAAA, class = IN
    ANSWERS:
    ->  dnscookie.bjun.tech
        AAAA IPv6 address = 2602:ff62:fff:4082:e8ed:a208:eb56:7971
        ttl = 85768 (23 hours 49 mins 28 secs)
    AUTHORITY RECORDS:
    ->  dnscookie.bjun.tech
        nameserver = nsdnscookie.bjun.tech
        ttl = 85766 (23 hours 49 mins 26 secs)
    ADDITIONAL RECORDS:
    ->  nsdnscookie.bjun.tech
        internet address = 102.129.220.230
        ttl = 86236 (23 hours 57 mins 16 secs)

------------
名称:    dnscookie.bjun.tech
Address:  2602:ff62:fff:4082:e8ed:a208:eb56:7971

参考

Identify Related Network Flows