domain-name-system – 绑定:由于NS的“意外输入结束”

前端之家收集整理的这篇文章主要介绍了domain-name-system – 绑定:由于NS的“意外输入结束”前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我偶然发现了Bind的主从配置中的奇怪错误.

该区域在主站上工作正常,但在奴隶上我遇到了这些错误

21-May-2014 19:06:07.573 general: info: zone example.com/IN: refresh: failure trying master 1.2.3.4#53 (source 0.0.0.0#0): unexpected end of input

这是我的绑定文件的样子:

@   IN SOA  ns1.example.com.    admin.example.com. (
    2014052116    ; Serial
    28800         ; Refresh
    180           ; Retry
    604800        ; Expire
    21600       ) ; Minimum

                86400   IN A        1.2.3.4
                86400   IN MX       10 mail.example.com.
                86400   IN MX       20 mail2.example.com.
                86400   IN NS       ns1.example.com.
                86400   IN NS       ns2.example.com.
                86400   IN NS       ns3.example.com.
                86400   IN NS       ns1.example.net.
                86400   IN NS       ns2.example.net.
                86400   IN NS       ns3.example.net.
                86400   IN NS       ns1.example.org.

; until here it works -- if I uncomment the below here,I'll get "end of input" failures.
;               86400   IN NS       ns2.example.org.
;               86400   IN NS       ns3.example.org.


*               86400   IN A        1.2.3.4
[...]

如果我取消注释被注释的两条NS线 – 我将得到“输入结束”错误.如果我让他们评论,一切正常.

是否存在导致其崩溃的最大NS或文件大小?

谢谢.

编辑:

命名checkzone:

master # named-checkzone example.com example.com. 
zone example.com/IN: example.com/MX 'mail.example.com' is a CNAME (illegal)
zone example.com/IN: example.com/MX 'mail2.example.com' is a CNAME (illegal)
zone example.com/IN: loaded serial 2014052105
OK

全球选择:

options {
    directory "/var/cache/bind";
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
    listen-on { any; };
    dnssec-enable yes;
    recursion no;
    statistics-file "/var/log/named.stats";
    try-tcp-refresh yes;
};

版本(在所有三台服务器上都相同):

# named -v
BIND 9.8.4-rpz2+rl005.12-P1

解决方法

我认为你正在运行的最大允许UDP DNS数据包大小为512字节.在进行预期的AXFR请求(在TCP模式下运行;没有大小约束)之前,从服务器还将进行SOA查询,以确认主服务器认为自己对该区域具有权威性.

您遇到的问题是SOA响应将包含的不仅仅是QUESTION和ANSWER部分:

> AUTHORITY部分将包含所有已配置的名称服务器.
> ADDITIONAL部分将包含这些名称服务器的所有已知A和AAAA记录.

这就是调整NS记录或其关联的A / AAAA记录对整个区域传输成功产生影响的原因,但添加其他记录类型没有影响.您的组合权限数据对于可以通过UDP传输的数据来说太大了.

不幸的是,我不知道有任何解决方法. BIND管理员参考手册确实引用了try-tcp-refresh选项,但是默认为yes,并且在选项中没有禁用它.我不确定区域转移是你问题的结束.即使它成功了,这也会给任何客户带来问题,而这些客户反过来会提出包含你的AUTHORITY和ADDITIONAL部分的任何请求. EDNS0旨在解决这样的问题,但我认为AUTHORITY膨胀在功能上太低,无法启动.

希望我的分析在某种程度上是错误的.我认为你有一个非常有趣的问题,我希望看到有人为此提供更好的答案,因为我也可以从中学习.

猜你在找的HTML相关文章