smartdns
smartdns copied to clipboard
pymumu
smartdns目前程序是否支持热加载
目前我弄了一个脚本反复切换域名的脚本，但生效只能使用/etc/init.d/smartdns restart 能否支持热加载也生效，比如 domain-set -name google-file /etc/smartdns/google.conf domain-rules /domain-set:google/ -c none -nameserver google google.conf我会自动新增绝对域名，但也会自动删除，那么就需要反复重启，但反复重启就可能导致，解析卡顿慢，因为53进程down了，如果本身热加载53进程就不会down，但配置也就生效了，可以实现这个功能不
谷歌的域名可以穷举 为啥要来回切换
不是谷歌域名，是举个例子，比如我腾讯域名，解析成43.141.X.X会丢包，目前我用脚本实现解析自动控制使用那个上游DNS解析，其实目的就是使用的上游DNS，提供我想要的结果，就给用户，不想要的就切换，但脚本会每次重启restart，所以想如果能热载不怕程序挂了，一挂都不能解析了
restart就可以了，加载速度应该是比较快的
其实需求是，比如5个上游DNS同时解析，有电信，联通，移动的上游DNS，返回出来的资源，我不需要电信的资源，我只需要移动的IP，或者可以理解是特定的IP地址才是我想要的，就是这个需求，有啥好的办法不
所以你的问题实际上是上游频繁变动。 如果仅仅是从结果中排除某些ip，可以用igrone-ip
说起来我觉得你可以把所有上游都写进配置，然后用防火墙控制哪些通哪些不通。
smartdns重启后有一些上游检查配置过程，等到实际进入工作状态可能没那么快
，
所以你的问题实际上是上游频繁变动。 如果仅仅是从结果中排除某些ip，可以用igrone-ip
说起来我觉得你可以把所有上游都写进配置，然后用防火墙控制哪些通哪些不通。
smartdns重启后有一些上游检查配置过程，等到实际进入工作状态可能没那么快
不光是排除，应该有个优先级的概念，比如我先用 3.3.3.3 上游DNS返回 6.6.0.0/16 段的资源那就是正常的，如果3.3.3.3返回43.141.0.0/16的资源的出现，我就使用上游移动DNS，比如假设2.2.2.2 是上游移动DNS，这个上游DNS解析就返回移动的结果，这样就避免解析到43.141出现丢包，如果直接igrone-ip 我怕解析结果就是43.141然后给用户给空就故障了，但如果既指定3.3.3.3跟2.2.2.2一起指定，那么就会返回6.6.0.0/16 还有移动上游DNS的结果，这样做不到精确控制解析，但如果存在6.6.0.0/16的资源，那我就不需要移动上游解析了，目前我是脚本实现的，但因为用户路由器也有ttl过期时间，我脚本是先看日志如果出现43.141就自动改成移动上游DNS解析，如果正好把43.141返回给用户后，用户那边ttl记录了这个解析结果，可能还是有问题，所以这种有啥好的解决方案不，如果用脚本也是会来回切换重启，所以一开始想是否支持热载，但也解决不了用户突然ttl过期时间那个场景
3.3.3.3跟2.2.2.2一起指定，那么就会返回6.6.0.0/16 还有移动上游DNS的结果
这里有一个区别。igrone-ip是从结果中去掉某一个ip。blacklist-ip是丢弃包含该结果的整个上游结果。我没理解你到底是要哪种。但针对单个上游应用igrone-ip或blacklist-ip不会影响其他上游。 最终终端拿到的结果（二次以上查询）是多个上游合并的结果。
restart就可以了，加载速度应该是比较快的
这种重启多了，也会进程卡死了，比如Server is already running, pid is 912 就是卡住了一样，然后我又搞了判断卡住的脚本，但好像不咋好使，所以如果能热载是不是就不会出现这种问题
3.3.3.3跟2.2.2.2一起指定，那么就会返回6.6.0.0/16 还有移动上游DNS的结果
这里有一个区别。igrone-ip是从结果中去掉某一个ip。blacklist-ip是丢弃包含该结果的整个上游结果。我没理解你到底是要哪种。但针对单个上游应用igrone-ip或blacklist-ip不会影响其他上游。 最终终端拿到的结果（二次以上查询）是多个上游合并的结果。 igrone-ip只忽悠某一个IP的话，估计不太好使，需求是比如我返回电信IP，我都得去掉，比如解析出来16个IP，8个电信，8个移动，那么我就把电信IP全部给去掉，或者我把电信的所有IP列表都搞出来比如2000多段，不返回电信结果，但前提是移动有资源，如果一个域名返回的只有电信结果，那么移动返回空这样也是故障，就是在能够返回结果的前提下过滤掉电信的解析目标，然后过滤的电信目标，可以单独搞个ctcc.list 里面放电信目标路由，类似这种，强调是一个域名如果都解析的是电信结果，那么就直接返回用户了，如果直接给过滤了，那么用户那里就获取不到解析IP了，会有问题