出现大量告警Read UDP错误，i/o超时

[Dodotry]

基于coredns源代码，添加dnsredir插件编译后，出现较多的i/o timeout，主机上已对内核的相关TCP参数优化，好像没有改善，有遇到这问题的吗？有什么方式能优化调整？

[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:53924->119.29.29.29:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:34824->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:49496->223.5.5.5:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:59482->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:39944->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:60629->8.8.8.8:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:49605->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:59442->114.114.114.114:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:49845->223.5.5.5:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:38189->1.1.1.1:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:42711->1.1.1.1:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:39886->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:46461->114.114.114.114:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:46362->202.130.97.65:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:55348->114.114.114.114:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:49217->114.114.114.114:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 172.31.180.141:52597->1.1.1.1:53: i/o timeout
[WARNING] plugin/dnsredir: Exchange() failed  error: read udp 7.7.22.2:58954->114.114.114.114:53: i/o timeout

[leiless]

用coredns官方的forward插件配置同样的上游DNS先验证下看看是不是能复现这个问题？

如果能，说明是网络的确有问题，比如丢包率很高，你可以尝试在高峰时期 ping 114.114.114.114 之类的看看丢包率。

我看你用的是UDP协议（原始DNS），可以把协议换成TCP协议，TCP协议在国内的ToS一般高于UDP，高峰时期也许有用。

另外这些常见的DNS地址全部io timeout，我怀疑是不是你的VPS宿主机层面禁用了UDP协议？

可以用 dig @223.5.5.5 baidu.com 试试看能不能正常响应。

dig @223.5.5.5 +tcp baidu.com （对应的TCP请求）

[Dodotry]

用coredns官方的forward插件配置同样的上游DNS先验证下看看是不是能复现这个问题？

如果能，说明是网络的确有问题，比如丢包率很高，你可以尝试在高峰时期 ping 114.114.114.114 之类的看看丢包率。

我看你用的是UDP协议（原始DNS），可以把协议换成TCP协议，TCP协议在国内的ToS一般高于UDP，高峰时期也许有用。

另外这些常见的DNS地址全部io timeout，我怀疑是不是你的VPS宿主机层面禁用了UDP协议？

可以用 dig @223.5.5.5 baidu.com 试试看能不能正常响应。

dig @223.5.5.5 +tcp baidu.com （对应的TCP请求）

十分感谢回复，日志里面我没有开启正常响应的日志，只记录了告警类。ping常见的公共DNS延时正常没有丢包，我尝试使用TCP协议后，统计少了一些timeout，但国外公共DNS没有明显变化。
VPS上没有禁用UDP，告警是有一定的比例存在。

[leiless]

统计少了一些timeout，但国外公共DNS没有明显变化

如果你的是在国内的云服务器上请求国外的IP的话，应该会很容易导致丢包的（国情），即便TCP也是如此。
我猜测你用coredns官方forward插件请求国外公共DNS也会产生类似的情况，有条件的话你可以验证下看看。

需要你确认下：

• 请求国内公共DNS io timeout是不是会明显减少很多？
• 请求国外公共DNS io timeout是不是会明显增加很多？

[Dodotry]

如果你的是在国内的云服务器上请求国外的IP的话，应该会很容易导致丢包的（国情），即便TCP也是如此。 我猜测你用coredns官方forward插件请求国外公共DNS也会产生类似的情况，有条件的话你可以验证下看看。

VPS使用境外IP，并有GRE到国内节点上，路由将国内公共DNS指向GRE。用forward会有timeout情况，但很少，不常现。

需要你确认下：

• 请求国内公共DNS io timeout是不是会明显减少很多？

国内有明显减少

• 请求国外公共DNS io timeout是不是会明显增加很多？

不会明显增加，只有1.1.1.1会相对较多超时。

[leiless]

VPS使用境外IP，并有GRE到国内节点上，路由将国内公共DNS指向GRE。用forward会有timeout情况，但很少，不常现。

看起来拓扑结构是：
End-user request <-> VPS(海外) coredns <-> 分流请求Public DNS(国内/国外)

你的意思是VPS coredns-dnsredir <-> Public DNS经常出现io timeout，但是同样的配置换成coredns-forward之后io timeout会减少很多对吗？

另外，GRE是什么东西？

[Dodotry]

VPS使用境外IP，并有GRE到国内节点上，路由将国内公共DNS指向GRE。用forward会有timeout情况，但很少，不常现。

看起来拓扑结构是： End-user request <-> VPS(海外) coredns <-> 分流请求Public DNS(国内/国外)

你的意思是VPS coredns-dnsredir <-> Public DNS经常出现io timeout，但是同样的配置换成coredns-forward之后io timeout会减少很多对吗？

对的。

另外，GRE是什么东西？

VPS → CN Node创建了GRE隧道 到国内DNS走7.7.22.1/30

[leiless]

可以分别贴一下 coredns-dnsredir 和 coredns-forward的配置吗？

从第一条评论的日志来看，是海外VPS DNS回溯国内公共DNS（通过GRE隧道到CN node）查询的时候出现了UDP read timeout。

我怀疑可能是GFW动了一些手脚，因为常规的DNS （UDP + TCP）请求都是明文的。

[Dodotry]

可以分别贴一下 coredns-dnsredir 和 coredns-forward的配置吗？

从第一条评论的日志来看，是海外VPS DNS回溯国内公共DNS（通过GRE隧道到CN node）查询的时候出现了UDP read timeout。

我怀疑可能是GFW动了一些手脚，因为常规的DNS （UDP + TCP）请求都是明文的。

当前的配置是这样的，forward配置的时候没有走分流解析，简单的试了一下海外和国内各两个。没敢多试，有用户体验不好。

.:53  {
  errors
  hosts {
    fallthrough
  }
  forward . 127.0.0.1:5302
  health :28080
  # prometheus :9153
  # log . "{type}|{proto}|{remote}:{port} - {>id},{size},{>do},{>bufsize},{rcode},{rsize},{duration},{name}"
  lrucache 50000
  template ANY AAAA {
      rcode NXDOMAIN
  }
  reload 30s
}

.:5302 {
  bind 127.0.0.1
  dnsredir /opt/coredns/conf/mydns.conf {
      expire 15s
      max_fails 3
      health_check 5s
      policy random
      path_reload 10s
      to 114.114.114.114
      to 202.96.128.86
  }
  dnsredir /opt/coredns/conf/overseas.conf {
      expire 15s
      max_fails 3
      health_check 5s
      policy round_robin
      path_reload 10s
      to 208.67.222.222
  }
  dnsredir /opt/coredns/conf/accelerated-domains.china.conf /opt/coredns/conf/apple.china.conf {
      expire 15s
      max_fails 3
      health_check 5s
      policy round_robin
      path_reload 10s
      to tcp://119.29.29.29
      to 114.114.114.114 tcp://223.5.5.5
  }
  dnsredir . {
      expire 60s
      max_fails 5
      health_check 5s
      policy random
      spray
      to tcp://202.130.97.65
      to tls://8.8.8.8@dns.google tls://8.8.4.4@dns.google
      to 1.1.1.1 tls://9.9.9.9
  }
  # log . "{type}|{proto}|{remote}:{port} - {>id},{size},{>do},{>bufsize},{rcode},{rsize},{duration},{name}"
  loop
  reload 30s

[Dodotry]

我怀疑可能是GFW动了一些手脚，因为常规的DNS （UDP + TCP）请求都是明文的。

不排除这种可能。

[leiless]

当前的配置是这样的，forward配置的时候没有走分流解析，简单的试了一下海外和国内各两个。没敢多试，有用户体验不好。

我稍晚一点看，现在忙。

有条件可以再开一组海外VPS + CN node，将GRE将他们连起来，这样环境就一样了，就可以作为测试环境了。

[leiless]

没敢多试，有用户体验不好。

另外，如果你有很多用户使用的情况下，也是有可能被GFW盯上的。

当然不排除机器性能跟不上用户请求，导致内核丢包，终端用户看到的就是超时了(UDP)。

[Dodotry]

没敢多试，有用户体验不好。

另外，如果你有很多用户使用的情况下，也是有可能被GFW盯上的。

当然不排除机器性能跟不上用户请求，导致内核丢包，终端用户看到的就是超时了(UDP)。

还是感觉不太正常，看下面的一段配置，forward直接均衡到了202.130.97.65 8.8.8.8，相当于dnsredir已经空闲，而且去掉了健康检查，这一台是另外一台新VPS，几乎没什么访问量，这是什么原因？

异常如下：

[Dodotry]

迷糊了……

[leiless]

相当于dnsredir已经空闲，而且去掉了健康检查，这一台是另外一台新VPS，几乎没什么访问量，这是什么原因？

注释掉 health_check 相当于使用默认值，你可以设置一下默认值 max_fails 0：

max_fails is the maximum number of consecutive health checking failures that are needed before considering an upstream as down. 0 to disable this feature(which the upstream will never be marked as down). Default is 3.

[leiless]

另外看起来需要支持一下 health_check 0 去禁用health_check，等有时间我改下..