我有一台运行 bind 9.4 的 DNS 服务器 (mega.dude - 123.123.123.123)。当我:
dig mega.dude
我没有得到答案部分。
我有
nameserver 123.123.123.123
在 /etc/resolv.conf 中
这是我的区域文件:
$TTL 1W
@ IN SOA mega.dude. names.mega.dude. (
2009081502 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
NS ns1
NS ns2
MX 10 mail.mega.dude.
A 123.123.123.123
@ A 123.123.123.123
ns1 A 123.123.123.123
ns2 A 123.123.123.123
www CNAME @
mail A 123.123.123.123
它以前不是这样的。我读到过,将 mx 记录指向 CNAME 是邪恶的。所以我改变了它。然后我想也许 NS 也是这种情况。所以我也改变了那些。仍然不行。端口是开放的。我搞不懂。哦,顺便说一句,所有其他区域都返回正常。但不是服务器自己的域。所以我知道我在做一些愚蠢的事情。
编辑
这是我的named.conf的部分:
zone "mega.dude" {
type master;
file "pri/mega.dude";
};
zone "123.123.123.in-addr.arpa" {
type master;
notify no;
file "pri/123.123.123";
};
这是我在服务器上收到的响应:
$ dig mega.dude
; <<>> DiG 9.4.3-P1 <<>> mega.dude
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25170
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mega.dude. IN A
;; Query time: 134 msec
;; SERVER: 123.123.123.123#53(123.123.123.123)
;; WHEN: Thu Apr 1 08:02:54 2010
;; MSG SIZE rcvd: 28
以下是我的笔记本电脑的响应:
dig @mega.dude mega.dude
; <<>> DiG 9.4.2-P2.1 <<>> @mega.dude mega.dude
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21361
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;mega.dude. IN A
;; Query time: 51 msec
;; SERVER: 123.123.123.123#53(123.123.123.123)
;; WHEN: Thu Apr 1 08:20:19 2010
;; MSG SIZE rcvd: 28
queries.log 包含:
01-Apr-2010 08:02:54.192 client 123.123.123.123#33160: query: mega.dude IN A +
我还应该检查其他地方吗?
编辑
我按照 Alnitak 的建议做了更改——至少我认为我理解了:
$TTL 1W
@ IN SOA mega.dude. names.mega.dude. (
2009081502 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
IN NS ns1
IN NS ns2
IN MX 10 mail
A 123.123.123.123
ns1 A 123.123.123.123
ns2 A 123.123.123.123
www A 123.123.123.123
mail A 123.123.123.123
我现在得到了权威部分,但没有答案部分:
dig mega.dude
; <<>> DiG 9.4.3-P1 <<>> mega.dude
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30264
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;mega.dude. IN A
;; AUTHORITY SECTION:
mega.dude. 86400 IN SOA mega.dude. names.mega.dude. 2009081502 10800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 123.123.123.123#53(123.123.123.123)
;; WHEN: Thu Apr 1 08:33:50 2010
;; MSG SIZE rcvd: 70
所以事实证明额外的记录导致了问题。
这有效:
@ A 210.48.255.42
这不会:
A 210.48.255.42
我现在得到了完整的答复:
$ dig @mega.dude mega.dude
; <<>> DiG 9.4.3-P1 <<>> @mega.dude mega.dude
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1029
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;mega.dude. IN A
;; ANSWER SECTION:
mega.dude. 604800 IN A 123.123.123.123
;; AUTHORITY SECTION:
mega.dude. 604800 IN NS ns1.mega.dude.
mega.dude. 604800 IN NS ns2.mega.dude.
;; ADDITIONAL SECTION:
ns1.mega.dude. 604800 IN A 123.123.123.123
ns2.mega.dude. 604800 IN A 123.123.123.123
;; Query time: 0 msec
;; SERVER: 123.123.123.123#53(123.123.123.123)
;; WHEN: Thu Apr 1 15:15:58 2010
;; MSG SIZE rcvd: 112
太棒了!只是有些奇怪...
我从运行测试http://www.checkdns.net/quickcheckdomainf.aspx
我发现两个问题:
在 NS 记录中未找到由 SOA(mega.dude)定义的主 DNS。
域名 mega.dude 没有 MX 记录,但有域名的 A 记录。此配置不是 mega.dude
我得到:
未找到任何记录 由 ns1.mega.dude 于 2010 年 4 月 1 日星期四 1:09:05 AM (GMT-5) 报告
自从我做出更改以来已经过去了 12 多个小时。我想我确实在区域文件中指定了 MX 记录。SOA 呢?我很高兴它基本已经解决了,但看起来仍然有些问题。很明显 mega.dude 不是实际域名。我暂时不想被黑客入侵。
抱歉这么久才回答这个问题。我想我应该删掉它。或者应该关闭它并发布另一个问题?
谢谢大家!
答案1
与其告诉我们你没有得到答案部分,不如告诉我们你的情况,这样我们才能更好地诊断做过获取,以及响应代码。
例如,这将告诉我们您的服务器是否正确提供服务SOA
,或者您是否收到某些特定的错误消息。
值得一提的是,关于使用别名(即 a )作为或记录CNAME
的目标的警告是正确的 - 你不应该这样做。MX
NS
我在这里没有看到任何真正的配置错误,但你可以进行一些优化,这样你就不需要真正的域名了任何地方在配置文件中:
@ IN SOA ns1 names ( ... )
IN MX 10 mail
此外,www
记录还应该是A
而不是-为创建别名CNAME
并不是一个好主意,因为对或的查询将返回与域本身完全相同的记录,而您真正想要的只是 IP 地址。www
$ORIGIN
www IN MX?
www IN NS?
您还拥有二与列出的主要记录实际上完全相同A
。这不会破坏任何东西,也许这只是一个复制粘贴错误?
编辑好奇的是,重复的 A 记录条目是问题所在 - 可能是缺少IN
限定符导致解析失败 - 您的 BIND 启动日志会告诉您这一点。
关于其他问题 - 最好将其作为新问题提出,最好引用实际域名。如果您使用虚拟数据,我们根本无法对实时 DNS 问题进行有效诊断。
编辑2不过我确实修复了这个SOA
问题 - 第一个条目SOA
应该是主名称服务器的名称。请参阅上面的修订示例。
答案2
如果您请求特定的记录类型会发生什么?
dig @mega.dude mega.dude. a
dig @mega.dude mega.dude. ns
dig @mega.dude mega.dude. mx
你有没有尝试过挖的+trace
选项?它将显示整个委托路径,这可能有助于您找出查询中断的位置。
dig mega.dude. +trace
答案3
我只是想澄清一下,以防有人想知道。主要问题是空格。不过,感谢所有帮助我纠正其他错误的人。干杯!