-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
出现大量告警Read UDP错误,i/o超时 #20
Comments
用coredns官方的forward插件配置同样的上游DNS先验证下看看是不是能复现这个问题? 如果能,说明是网络的确有问题,比如丢包率很高,你可以尝试在高峰时期 我看你用的是UDP协议(原始DNS),可以把协议换成TCP协议,TCP协议在国内的ToS一般高于UDP,高峰时期也许有用。 另外这些常见的DNS地址全部io timeout,我怀疑是不是你的VPS宿主机层面禁用了UDP协议? 可以用
|
十分感谢回复,日志里面我没有开启正常响应的日志,只记录了告警类。ping常见的公共DNS延时正常没有丢包,我尝试使用TCP协议后,统计少了一些timeout,但国外公共DNS没有明显变化。 |
如果你的是在国内的云服务器上请求国外的IP的话,应该会很容易导致丢包的(国情),即便TCP也是如此。 需要你确认下:
|
VPS使用境外IP,并有GRE到国内节点上,路由将国内公共DNS指向GRE。用forward会有timeout情况,但很少,不常现。
国内有明显减少
不会明显增加,只有1.1.1.1会相对较多超时。 |
看起来拓扑结构是: 你的意思是VPS coredns-dnsredir <-> Public DNS经常出现io timeout,但是同样的配置换成coredns-forward之后io timeout会减少很多对吗? 另外,GRE是什么东西? |
可以分别贴一下 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://[email protected] tls://[email protected]
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 |
不排除这种可能。 |
我稍晚一点看,现在忙。 有条件可以再开一组海外VPS + CN node,将GRE将他们连起来,这样环境就一样了,就可以作为测试环境了。 |
另外,如果你有很多用户使用的情况下,也是有可能被GFW盯上的。 当然不排除机器性能跟不上用户请求,导致内核丢包,终端用户看到的就是超时了(UDP)。 |
迷糊了…… |
注释掉 health_check 相当于使用默认值,你可以设置一下默认值
|
另外看起来需要支持一下 |
我正在抓53端口的报文,空闲等待比较久,想多抓几个数据包供分析。 |
改为 |
附件是抓的报文,配置 |
哈哈,静候大佬佳音~ |
配置参数 [WARNING] plugin/dnsredir: tls: failed to send closeNotify alert (but connection was closed anyway): write tcp 172.31.180.141:4425->8.8.4.4:853: write: broken pipe
[WARNING] plugin/dnsredir: hc: DNS tls://9.9.9.9:853 failed rtt: 2.558025584s err: EOF
[WARNING] plugin/dnsredir: hc: DNS tls://9.9.9.9:853 failed rtt: 2.832479702s err: EOF |
第一条是正常的网络异常现象,第二和第三条看起来还是调用了health check。 |
这次更新是已经支持 |
还没... 我尽快 最近是修复网络请求未设置超时的bug |
最近发布的版本只修复已知缺陷吗? |
|
有规划支持禁用health_check配置么? |
这段时间找个空闲时间看看,顺便更新下upstream coredns。:-) |
最近比较忙,可能还得推迟一段时间了。😔 |
羊群满地,注意防护 |
大佬很久没维护了☺ |
时间比较久远了,我理解一下,现在的问题是:
|
我在x64的OpenWRT上也出现了,日志如下:
甚至是转发给本机的openclash也不通。准备更新一下OpenWRT的Linux内核版本看看 |
大佬好久没维护了 |
好像是那个coredns luci app的原因,导致启动了好几个coredns实例。只运行一个的时候没问题了 |
基于coredns源代码,添加dnsredir插件编译后,出现较多的i/o timeout,主机上已对内核的相关TCP参数优化,好像没有改善,有遇到这问题的吗?有什么方式能优化调整?
The text was updated successfully, but these errors were encountered: