ppdragon16

这个问题其实可以直接加上 `mac('...') -> must_direct` 解决。 然而奇怪的是 `dip(geoip:private) -> direct` 改为 `dip(geoip:private) -> must_direct` 也可以解决这个问题（但是最终配置不能这么写，会导致dae的dns配置无效）。 tcpdump 发现设备会发 IGMP 包到 238.238.238.238。 如果是 `dip(geoip:private) -> must_direct` 则tcpdump输出是这样： ``` 20:48:31.453883 ARP, Request who-has ESP_0BC548.lan...

一顿折腾后我现在怀疑是dae的dns劫持的问题。 当问题发生时，`wisedevice-hilink-drcn.things.dbankcloud.cn`的dns请求回复包如下： ``` Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8180 Standard query response, No error 1... .... .... .... = Response: Message is a response .000 0... .......

发现dae的dns结果（比如www.baidu.com）都是 “Flags 0x8180” 且 “Time to live: 0 (0 seconds)”。 这会不会就是root cause？ 尝试在dns设置中加入ttl没啥用： ``` fixed_domain_ttl { wisedevice-hilink-drcn.things.dbankcloud.cn: 2 } ```

> 你的iot设备是向谁进行的DNS查询，op:53是你的局域网网关吗，为什么你的网关作为一个递归解析器会提供权威的DNS回复，这本身就是不正常的 有道理，不知道咋就抓到一个有AA标记的回复包。。。

> [@ppdragon16](https://github.com/ppdragon16) https://t.me/daeuniverse > > 麻烦进群聊聊 多年没玩电报了，账号忘了。刚尝试注册，收不到短信验证码。。。

> time to live是0的by design的，因为dae必须保证每个连接发送之前都尝试dns查询才能使得内核部分的domain()规则有效 我们正在尝试一种其他的方法去允许在不篡改ttl的情况下让这些事情工作，详见 [#763](https://github.com/daeuniverse/dae/pull/763) > IoT设备很可能就是遵从了ttl==0不断发dns请求。我稍后patch一下你的pr试试。

> > > time to live是0的by design的，因为dae必须保证每个连接发送之前都尝试dns查询才能使得内核部分的domain()规则有效 我们正在尝试一种其他的方法去允许在不篡改ttl的情况下让这些事情工作，详见 [#763](https://github.com/daeuniverse/dae/pull/763) > > > > > > IoT设备很可能就是遵从了ttl==0不断发dns请求。我稍后patch一下你的pr试试。 > > 建议使用 https://github.com/lostattractor/dae/tree/dirty 这里包含很多的修复，包括返回正确的ttl 我刚刚那个pr还没有实现返回正确的ttl 刚试了一下dae/tree/dirty，果然好了！

一个更简单的方案：为DnsCache加上src addr/mac。

上面方案的一个实现：https://github.com/ppdragon16/dae/tree/dns-cache-per-client 目前运行24小时没出问题。CA大重构之前自用。

fork了CA大佬的dirty branch，加了merge answers的逻辑，希望能解决这个问题。 https://github.com/ppdragon16/dae/commits/dirty