服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 未绑定的tcp-upstream不起作用。 使用TCP查询上游DNS服务器真的在现实世界中工作？
Intereting Posts
新的Linux和古老的Solaris之间的最稳定的NFSconfiguration？ 引导Debian VM时遇到错误消息 由SelfSSL7生成的SSL证书失败。 有任何想法吗？ Apache2，VirtualHosts，SSL，Mutli域名证书 与使用DNATed IP的传入相同的接口回复 切换前景过程 我如何转发某个域名到另一个url？ 什么是最好的Linux版本的Web服务器？ 运行perl脚本使用root cron告诉我“访问被拒绝” 完整的系统备份到Windows Server 2008上的远程NAS replace$ args中的第一个字符 logging带宽使用？ SASL：如何删除用户的所有mech条目？ 如何强制所有软件的umask 002？ 从私有VPC子网访问Internet？

未绑定的tcp-upstream不起作用。 使用TCP查询上游DNS服务器真的在现实世界中工作？

今天我一直在unbound.conf中玩一些选项，只是为了好玩。 我已经启用TCP上游，但它不适用于某些域。

OS：OpenBSD当前。 不作承诺：1.4.19

启用tcp-upstream的示例： 

--> dig www.google.com ; <<>> DiG 9.4.2-P2 <<>> www.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30362 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 43200 IN A 173.194.34.210 www.google.com. 43200 IN A 173.194.34.212 www.google.com. 43200 IN A 173.194.34.211 www.google.com. 43200 IN A 173.194.34.209 www.google.com. 43200 IN A 173.194.34.208 ;; Query time: 579 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 20 01:01:54 2013 ;; MSG SIZE rcvd: 112 --> dig www.facebook.com ; <<>> DiG 9.4.2-P2 <<>> www.facebook.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48116 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN A ;; Query time: 4529 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 20 01:02:05 2013 ;; MSG SIZE rcvd: 34

/var/log/messages显示facebook查询的这个错误： 

 unbound: [29654:0] error: tcp connect: Connection refused

在tcp-upstream禁用的情况下： 

 --> dig www.facebook.com ; <<>> DiG 9.4.2-P2 <<>> www.facebook.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50721 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN A ;; ANSWER SECTION: www.facebook.com. 43200 IN CNAME star.c10r.facebook.com. star.c10r.facebook.com. 43200 IN A 173.252.101.26 ;; Query time: 692 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 20 01:06:20 2013 ;; MSG SIZE rcvd: 74

我猜这个问题是有些服务器不允许tcp客户端。 这个问题的一些解决方法？ 它真的可以在现实世界中使用tcp-upstream吗？

我知道UDP是一个更好的DNS协议。 我不需要像“使用UDP代替”的答案。 我只是在问TCP与DNS的这个问题，如果这在现实世界中是可靠的。

DNS大多数情况下都使用小的消息和响应（只需做一些随机查询，然后考虑查询和响应的紧凑表示所需的空间）。 为此使用UDP是理想的（没有连接设置/拆卸成本）。 有些查询有大量的答案（例如，查看nslookup -query=any google.com的输出），这不适合最小的UDP数据报。 这些都是通过TCP询问和回答的。

随着EDNS的可用性（ http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS ），大多数包括IPv6和DNSSEC在内的DNS查询都可以使用UDP来解决。 因此，许多服务器提供商不允许传入连接到TCP端口53. TCP的使用通常仅限于区域传输。

因此，如果您计划为本地客户端创buildrecursionDNS服务器，则应该基于UDP，因为所有服务器都支持UDP，并且大多数不支持TCP。

在未绑定的文档中检查它： 

  outgoing-num-tcp: <number> Number of outgoing TCP buffers to allocate per thread. Default is 10. If set to 0, or if do_tcp is "no", no TCP queries to authoritative servers are done. incoming-num-tcp: <number> Number of incoming TCP buffers to allocate per thread. Default is 10. If set to 0, or if do_tcp is "no", no TCP queries from clients are accepted.