首先，我不是在做失败。 我希望能够使用HWIC-4ESW添加另一个ISP链接。 设备：可提供HWIC-4ESW的Cisco 3825（1GB RAM，2GB闪存，IOS 15.4高级企业服务）。 目前，使用Gi0 / 1将路由器连接到Gi0 / 0上当前ISP的pipe理型交换机。 我需要添加第二个链接到同一个ISP（他们不提供更多的带宽每个链接，其他ISP在地区不提供任何更好的）。 我的ISP不允许在这些链接上绑定，但是如果我在我的路由器上进行负载平衡，则可以实现负载均衡。 我有几个select：1）使用交换机join两个ISP提供的调制解调器之前的路由器。 （不是最好的解决scheme，但可行）2）使用我已经铺设的HWIC-4ESW并尝试使用它。 （首选方法，因为我手头有HWIC）3）花钱在HWIC-2FE上并使用layer3路由。 （最好的方法，但也是昂贵的，现在将解决这个问题，但我将不得不购买更多的hwic-2fe的，因为我添加）4）使用路由器棒configuration提供第3层路由到其他vlans和控制访问使用ACL 。 （也是可行的，但不是最好的，因为ISP的stream量不是，也不能被标记或被丢弃; 5）使用Linux服务器提供平衡和聚合，然后转发到路由器（使用2个有限的静态IP地址（/ 29） ） 我的问题是，如果我能得到选项2工作，我将如何设置？ 如果选项2不起作用，请根据其他选项提供build议。 谢谢
我们有一个公共的DNS提供者，一个私人的DNS主人和一个私人的DNS奴隶。 公共DNS提供“example.com”区域及其所有子域。 我们的专用DNS也提供了“example.com”区域，但是有些Alogging指向我们LAN上的内部IP而不是公共IP。 关于这个configuration令人讨厌的是，我们需要在两个DNS主服务器上复制所有的CNAME和MXlogging。 在私人DNS主机上，如果我可以在我们的专用networking上configuration一些已知的子域名，然后回落到公共主机上以获取任何未定义的logging，这将是非常酷的。 AFAIK，这可以用通配符NSlogging来完成，但是这些不被允许。 例子： example.com Web服务器是可公开访问的 Web服务器上的某些页面仅适用于来自专用LAN的请求 cdn.example.com 是一个CNAME指向亚马逊云端 我不想在我们的专用DNS服务器上定义cdn.example.com区域。 （而且我们有许多其他的logging是重复的。）如果私人DNS服务器可能是一个特定区域的主/从混合，这将是很好的，所以它可以覆盖某些logging，但从公共DNS服务器。 如果bind9不能做到这一点，有什么可以吗？ 或者，也许我应该使用shell脚本来完成此操作，然后再添加或覆盖我们的自定义logging。
将域名中的每个名称服务器条目指向不同的故障转移服务器有什么缺点吗？ 在这个设置中，相同的DNS服务器也将提供内容 – 所以如果它closures，替代的名称服务器将被加载，然后指向自己。 我知道这个设置有其局限性（例如，每个域将被限制为只有一个“受保护的”服务器/服务），但是我是否有任何限制？
SRVlogging符合以下格式： _service._proto.domain (and some other values here…) 。 我想知道是否有人曾经在_proto – tls使用过。 TLS不是传输协议，那么可以在那里使用它？ 我知道在_service可以增加安全性，但是在传输协议上也可以吗？
我看到一个问题，即与BIND并发的UDP连接数量似乎有限。 我以前在named.conf增加了recursive-clients ，并且增加了/etc/sysconfig/named的套接字限制： ulimit -HSn 16384 OPTIONS="-S 16384" 我不再在日志中看到任何错误，但是我仍然对DNS查询的响应速度缓慢/丢失。 看看netstat -an或者在/proc/net/udp我可以看到UDP连接的数量始终低于4096，这表明我正在达到一个我无法识别的地方。 我可以在/proc/net/nf_conntrack看到数以万计的[UNREPLIED]条目，所以我假定连接正在通过iptables，但没有被BIND接受。 我在VMWare VM（不同的物理主机）上运行库存BIND 9.8.2的多个CentOS 6.5服务器上看到了这一点。 面向客户的IP是通过AnyCast公告的环回; 如果我查询服务器的实际IP，我会一直得到一个即时响应，所以有可能是每个本地IP。 任何人都可以提出我可能打的任何限制，或者我失踪的其他任何东西？
这是我的区域文件 zone "domain.com"{ type master; file "/etc/bind/db.override"; }; zone "cpanel.domain.com"{ type forward; forwarders { 8.8.8.8;8.8.4.4; }; forward only; } 根域parsing为这个文件 ; ; BIND data file for overridden IPs ; $TTL 86400 @ IN SOA ns1 root ( 2012100401 ; serial 604800 ; refresh 1w 86400 ; retry 1d 2419200 ; expiry 4w 86400 ; minimum […]
我遇到了一个奇怪的问题，我的服务器现在拒绝做DNS查找（使用绑定）。 我使用CentOS盒子作为OpenVPN网关，为客户端提供DNS服务。 对于一个月，一切工作正常，如预期，今天的DNS服务不再工作。 没有改变configuration… 这是named.conf文件： options { # Hide bind version version "Not shown"; # Listen only on localhost and VPN gateway IPv4 listen-on port 53 { 127.0.0.1; 10.44.3.1; }; listen-on-v6 port 53 { ::1; }; # Forward requests to Google public DNS forwarders { 8.8.8.8; 8.8.4.4; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file […]
概要 我尝试使用ISC Bind 9.9.5设置广域Bonjour（又名DNS-SD ），但无法加载提供“富文本”服务域发现的反向查找区域。 背景 根据浏览和注册域的发现（域枚举） ： 五个特殊的RR名字是为此目的而保留的： b._dns-sd._udp.<domain>. db._dns-sd._udp.<domain>. r._dns-sd._udp.<domain>. dr._dns-sd._udp.<domain>. lb._dns-sd._udp.<domain>. 通过对这些名称执行PTR查询，客户可以分别学习： 推荐浏览的域名列表。 一个推荐的默认域用于浏览。 build议使用dynamic更新注册服务的域列表。 一个推荐的默认域用于注册服务。 “传统浏览”或“自动浏览”域。 [ deletia ] 查询名称的<domain>部分也可以从主机的IP地址以不同的方式派生。 主机使用其IP地址并计算该地址及其子网掩码的逻辑与，以得出子网的“基本”地址（该子网的“networking地址”，或者等同于“全部”在该子网上的“零”主机地址）。 然后，它构造与该基地址相对应的常规DNS“反向映射”名称，并将其用作上述查询的名称的<domain>部分。 例如，如果主机的地址为192.168.12.34，子网掩码为255.255.0.0，那么子网的“基本”地址为192.168.0.0，并为此设备发现推荐的自动浏览域子网，主机发出名称为“lb._dns-sd._udp.0.0.168.192.in-addr.arpa”的DNS PTR查询。 另外，在域名下： 富文本服务子域名是允许和鼓励的，例如： Building 2, 1st Floor . example . com . Building 2, 2nd Floor . example . com . Building 2, 3rd Floor . example . […]
对于testing环境，我有一个非常具体的问题。 我有这个networking设置： +————+ +————+ | | +—–+ | | | eth0 +—-+ br0 +—-+ eth0 | | | +-+—+ | | | Guest1 | | | Guest2 | | | +—–+ | | | eth1 +—-+ br1 +—-+ eth1 | | | +—+-+ | | +————+ | | +————+ +-+-+–+ | Host | +——+ KVM主机为客户机（/ […]
我有一个令人不安的问题，现在几个星期…我的三个DNS服务器之一（运行bind9作为Plesk DNS主服务器的从服务器）正在发送无谓的DNS请求垃圾邮件。 这些请求的来源IP来自世界各地，所以我不能仅仅通过iptables来丢弃IP范围或整个国家。 这里有几条日志，所以你可以看到这些“攻击”的scheme： 10-May-2015 11:15:54.714 client 120.87.202.161#47441: query: sjgzincrmxobabst.www.luzhiye.com IN A + (my-ip) 10-May-2015 11:15:56.252 client 111.187.196.51#41387: query: mrcf.www.330dp.com IN A + (my-ip) 10-May-2015 11:15:56.806 client 89.90.44.173#56673: query: qzwp.www.330dp.com IN A + (my-ip) 10-May-2015 11:15:57.891 client 116.93.242.237#55721: query: srapafupglkxaver.www.330dp.com IN A + (my-ip) 10-May-2015 11:15:59.611 client 123.153.92.59#20847: query: yj.www.330dp.com IN A + (my-ip) 这些请求并不是真正的攻击，因为主机服务器非常轻松。 […]