@JenghongLee
@flyfishcn
要是厂家的人在这里，能帮忙确认问题所在就好了。同一地点、同一线路，只换了 ONT 就好了，也是应该能说明应该是软件实现的问题，而非线路的问题了。如能找到问题，说不定更新一下固件就好了。

@app13 可以尝试报修，说光猫开久了容易无响应，重启光猫又好了，问问你那边的维护人员，有没有“大厂”（华为、中兴等）的光猫可以换。

@mmmkik 解析的 IP 确认过了，是对的。并且直接访问 IP 也不可以打开网页。

@redsonic 所以烽火的光猫 6in4 也是没问题的啰？

@zwy100e72 确实如此，但作为 ONT，感觉既然设置成了桥接，就不应该去管 PPP 包的内容才对。除非要做应用层替换，不然这个开发意义在哪里？除非……

@xinglp 这个太容易被更换了吧，用户端设备谁都可以换掉，还不如原来的分光呢。

@zro 又查了一下 6in4 的实现协议，好像还必须解包 41 号协议，才能实现改隧道里的 v6 包，难道你那边的的线路中的某些设备已经可以做 41 号协议解包修改了？

@zro 一样的，DNS UDP 响应可以抢答，可以修改返回的数据，不管你是 v6 还是 v4 地址……运营商这么做，是“好心”，怕你用了其它 DNS 解析出来的地址不是它网内的，网速慢又还要多出网间结算费用。连很多家用路由器的自定义固件都可以设置，是否强制指定 DNS 为某个地址，而不管设备端如何更改 DNS 配置。

@flyfishcn 还是固件问题可能性比较大……说不定这几个厂家都用了同一个“公版方案”做出来的固件。搜了一下，出问题的都是这种之前没怎么听过厂家，很是奇特。

@zro 这个不好说，还可能会是运营商把 8888 的路由做到了自己的网内。

@flyfishcn 问题是这是桥接模式呀，桥接后需拨号，难道连 PPPoE 的包也解了？解来做什么……岂不是把简单的二层数据复杂化到应用层了？

@akimotoakira8 https://www.v2ex.com/t/389690 可以参考这个，估计是光猫的问题。

@CloudXNS The name server "lv3ns1.ffdns.net" is an approved name server. 还蛮迅速呀，不像 DNSPod 发邮件问了，就回复已经提交等待通过……到现在也没消息了。

你们的 Link 记录能否改进一下，一致返回 A Record 行不？这样就能在 @ 上用 CDN 了呢，现在添加了 Link 偶尔会返回 CNAME，把 MX 冲掉了。就像 Route 53 那样的 Alias 记录。

Alias records work like a CNAME record in that you can map one DNS name (example.com) to another ‘target’ DNS name (elb1234.elb.amazonaws.com). They differ from a CNAME record in that they are not visible to resolvers. Resolvers only see the A record and the resulting IP address of the target record.

Resolvers only see the A record and the resulting IP address of the target record 这是重点啊。不然 Link 记录就没有任何优势了。

想添加 .dk 的域名，可是你们的 Name server 没有在 DK Hostmaster 注册啊，没法修改成你们提供的地址，就是 lv3ns1.ffdns.net. lv3ns2.ffdns.net. 这些地址，DNSPod 也是没有注册……没注册根本修改不了 .dk 域名的 Name server 的。

DK Hostmaster 注册地址： https://www.dk-hostmaster.dk/english/technical-administration/dns-server-contacts/apply-for-nameserver/
查询是否注册的地址： https://www.dk-hostmaster.dk/english/technical-administration/dns-server-contacts/approved-name-servers/