;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 3600 IN NS ns.bogustld.
;; ADDITIONAL SECTION:
ns.bogustld. 3600 IN A 10.0.0.1
如果我从发痒的机器执行此操作，我会得到
;; QUESTION SECTION:
;. IN NS
;; AUTHORITY SECTION:
. 3600000 IN NS ns.bogustld.
;; Query time: 0 msec
它会变得更有趣
如果您尝试 dig +trace .互联网框
; <<>> DiG 9.5.0a6 <<>> +trace .
;; global options: printcmd
. 3005 IN NS C.ROOT-SERVERS.NET.
. 3005 IN NS D.ROOT-SERVERS.NET.
. 3005 IN NS E.ROOT-SERVERS.NET.
. 3005 IN NS F.ROOT-SERVERS.NET.
. 3005 IN NS G.ROOT-SERVERS.NET.
. 3005 IN NS H.ROOT-SERVERS.NET.
. 3005 IN NS I.ROOT-SERVERS.NET.
. 3005 IN NS J.ROOT-SERVERS.NET.
. 3005 IN NS K.ROOT-SERVERS.NET.
. 3005 IN NS L.ROOT-SERVERS.NET.
. 3005 IN NS M.ROOT-SERVERS.NET.
. 3005 IN NS A.ROOT-SERVERS.NET.
. 3005 IN NS B.ROOT-SERVERS.NET.
;; Received 500 bytes from 64.105.172.26#53(64.105.172.26) in 19 ms
. 86400 IN SOA a.root-servers.net. nstld.verisi
gn-grs.com. 2008102201 1800 900 604800 86400
;; Received 92 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 84 ms
我的内部根框， （假）
; <<>> DiG 9.5.0-P2 <<>> +trace .
;; global options: printcmd
. 3600 IN NS ns.bogustld.
;; Received 57 bytes from 10.0.0.1#53(10.0.0.1) in 1 ms
. 3600 IN NS ns.bogustld.
;; Received 72 bytes from 10.0.0.1#53(ns.bogustld) in 0 ms
痒
; <<>> DiG 9.5.0-P2 <<>> +trace .
;; global options: printcmd
. 3600000 IN NS ns.bogustld.
;; Received 41 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms
dig: couldn't get address for 'ns.bogustld': failure
为什么我的面向互联网的机器可以找到 SOA，但我的内部机器却找不到？
Now my delegation issues look resolved, but I am still having trouble with the root lookup (which I thought would be soooo easy.)
I think the problem stems from the fact that when I dig from the itchy machine I get an authority record instead of an answer record. I'm just not sure what I did (or didn't) to cause that.
If you "dig [no args]" from a machine using the typical hint file for the internet you get a block of answers for the root nameservers and the translation in the additional section.
if I do that from the bogus machine (root and TLD nameserver) I get
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 3600 IN NS ns.bogustld.
;; ADDITIONAL SECTION:
ns.bogustld. 3600 IN A 10.0.0.1
If I do that from the itchy machine I get
;; QUESTION SECTION:
;. IN NS
;; AUTHORITY SECTION:
. 3600000 IN NS ns.bogustld.
;; Query time: 0 msec
It get's more interesting if you try dig +trace .
Internet box
; <<>> DiG 9.5.0a6 <<>> +trace .
;; global options: printcmd
. 3005 IN NS C.ROOT-SERVERS.NET.
. 3005 IN NS D.ROOT-SERVERS.NET.
. 3005 IN NS E.ROOT-SERVERS.NET.
. 3005 IN NS F.ROOT-SERVERS.NET.
. 3005 IN NS G.ROOT-SERVERS.NET.
. 3005 IN NS H.ROOT-SERVERS.NET.
. 3005 IN NS I.ROOT-SERVERS.NET.
. 3005 IN NS J.ROOT-SERVERS.NET.
. 3005 IN NS K.ROOT-SERVERS.NET.
. 3005 IN NS L.ROOT-SERVERS.NET.
. 3005 IN NS M.ROOT-SERVERS.NET.
. 3005 IN NS A.ROOT-SERVERS.NET.
. 3005 IN NS B.ROOT-SERVERS.NET.
;; Received 500 bytes from 64.105.172.26#53(64.105.172.26) in 19 ms
. 86400 IN SOA a.root-servers.net. nstld.verisi
gn-grs.com. 2008102201 1800 900 604800 86400
;; Received 92 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 84 ms
My internal root box (Bogus)
; <<>> DiG 9.5.0-P2 <<>> +trace .
;; global options: printcmd
. 3600 IN NS ns.bogustld.
;; Received 57 bytes from 10.0.0.1#53(10.0.0.1) in 1 ms
. 3600 IN NS ns.bogustld.
;; Received 72 bytes from 10.0.0.1#53(ns.bogustld) in 0 ms
Itchy
; <<>> DiG 9.5.0-P2 <<>> +trace .
;; global options: printcmd
. 3600000 IN NS ns.bogustld.
;; Received 41 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms
dig: couldn't get address for 'ns.bogustld': failure
Why does my internet facing machine find a SOA, but none of my internal machines?
Assuming that you've checked all of the obvious things - such as ensuring that the main bind configuration file is what you think it is. Firstly check that the that you think named is using are the right ones - sometimes it's easy to edit a file that's in the wrong directory and wonder why changes aren't noticed.
Also have you used named-checkconf and named-checkzone
It is hard enough to debug bind, but without seeing the config files it is almost impossible, so please add them to the original post.
(I've added this as a comment to the question - I've posted as an answer because the OP is new here).
因此 box1 和 box2 应该位于伪造区域，并且包含 A 记录。 zone1和zone2应该是指向box1和box2的NS记录。
清澈如泥？ :)
Each of the 3 servers needs to have the same hints file. It should have an NS record for "." with the name of the root server and an A record for that name.
The root server should have the "." zone set up. The "." zone needs to have "bogus" with an ns record for itself. It then should have A records for box1.bogus going to box1 and box2.bogus going off to box2.
Note that you should not use box1 and box2 both as the hostnames and the names of the 2nd level domains. Let's say that the domains are zone1.bogus and zone2.bogus instead.
So box1 and box2 should be in the bogus zone, complete with A records. zone1 and zone2 should be NS records pointing to box1 and box2.
;Should this be ns1.itchy.bogus or ns1.itchy.internal.bogus??
itchy NS ns1-itchy.bogus.
ns1-itchy.bogus. A 10.0.0.2
;
scratchy NS ns1-scratchy.bogus.
ns1-scratchy.bogus. A 10.0.0.3
我认为问题是你正在委托 itchy.bogus，所以你不能把名字放在那里。
我相信，“com”名称服务器使用提示，以便它们可以为委托区域的名称服务器提供 A 记录，但在您的情况下，确保所服务的任何给定区域仅具有子区域的委托和当前区域内的主机。
Ok. I see you've aded your configs. Excellent.
I would change the root zone thusly:
;Should this be ns1.itchy.bogus or ns1.itchy.internal.bogus??
itchy NS ns1-itchy.bogus.
ns1-itchy.bogus. A 10.0.0.2
;
scratchy NS ns1-scratchy.bogus.
ns1-scratchy.bogus. A 10.0.0.3
I think the issue is that you're delegating itchy.bogus, so you can't put names inside there.
The "com" name servers, I believe, use hints so that they can serve A records for name servers for delegated zones, but in your case, it's just cleaner to insure that any given zone being served only has delegations for sub-zones AND hosts within the current zone.
一些备用 DNS 根提供商会这样做，但它们为“客户”提供根提示以供使用，但根本不引用“真实”根服务器。
...我对这个问题的理解正确吗？ 没有把握。
Like the highlander, there can be only one.
By using the normal internet root hints, you're more or less precluded from using your own internal root, because none of the real Internet root servers know about "bogus".
Your only choice would be to mirror the root "." zone from within your ".", but then add "bogus" to it. You'd do this by periodically dumping the root zone and running it through some processing to add your custom zone to it.
Some of the alternate DNS root providers do this, but they supply root hints for their "customers" to use that do not reference the "real" root servers at all.
... Am I understanding the question correctly? Not sure.
dig . @10.0.0.1 (bogus) should return authoritative records for '.', since it is indeed authoritative for the zone.
dig . @10.0.0.2 (itchy) should not return authoritative records for '.', since it isn't. It may return an authoritative record the first time you query for a name in the root zone, because it has to recurse and fetch an authoritative record from the authoritative server. But if you do it a 2nd time, you'll get a cached result and the 'aa' flag will be clear.
Your name server won't use the hint to give answers to dig. That is, it won't give the hint back to dig as an answer. It will insist on actually querying 10.0.0.1 for bogustld. I don't think you have bogustld set up as a zone, just bogus.
You should probably change ns.bogustld to ns.bogus. Give 10.0.0.1 the name ns.bogus.
Alternatively, you could add an NS and an SOA record in . for bogustld.
If you dig ns1.bogus. @10.0.0.2, that works, right (assuming the config above is still in place)?
发布评论
评论（8）
通过使用@，您正在定义itchy.bogus。 然后，您无法在带有 itchy.bogus 线的区域中进一步重新定义它。
试试这个：
因为这是 itchy.bogus 的区域文件，所以应该做正确的事情。
By using @, you're defining itchy.bogus. You can't then redefine it further down in the zone with the itchy.bogus line.
Try this:
Since this is the zone file for itchy.bogus, that should do the right thing.
现在我的委托问题看起来已经解决了，但我仍然在根查找方面遇到问题（我认为这会非常容易）。
我认为问题源于这样一个事实：当我从发痒的机器中
挖掘时我得到的是权威记录而不是答复记录。 我只是不确定我做了什么（或没有做什么）导致了这种情况。如果您使用互联网上典型的提示文件从机器上“挖掘[无参数]”，您将获得根名称服务器的一组答案以及附加部分中的翻译。
如果我从伪造的机器（根和 TLD 名称服务器）执行此操作，我会得到
如果我从发痒的机器执行此操作，我会得到
它会变得更有趣
如果您尝试
dig +trace .互联网框我的内部根框， （假）
痒
为什么我的面向互联网的机器可以找到 SOA，但我的内部机器却找不到？
Now my delegation issues look resolved, but I am still having trouble with the root lookup (which I thought would be soooo easy.)
I think the problem stems from the fact that when I
digfrom the itchy machine I get an authority record instead of an answer record. I'm just not sure what I did (or didn't) to cause that.If you "dig [no args]" from a machine using the typical hint file for the internet you get a block of answers for the root nameservers and the translation in the additional section.
if I do that from the bogus machine (root and TLD nameserver) I get
If I do that from the itchy machine I get
It get's more interesting if you try
dig +trace .Internet box
My internal root box (Bogus)
Itchy
Why does my internet facing machine find a SOA, but none of my internal machines?
假设您已经检查了所有明显的事情 - 例如确保主绑定配置文件是您认为的那样。 首先检查您认为 name 使用的文件是否正确 - 有时很容易编辑位于错误目录中的文件，并想知道为什么没有注意到更改。
另外，您是否使用过named-checkconf和named-checkzone
调试bind已经足够困难了，但是如果没有看到配置文件，这几乎是不可能的，所以请将它们添加到原始帖子中。
（我已将其添加为问题的评论 - 我已将其作为答案发布，因为这里的操作是新的）。
Assuming that you've checked all of the obvious things - such as ensuring that the main bind configuration file is what you think it is. Firstly check that the that you think named is using are the right ones - sometimes it's easy to edit a file that's in the wrong directory and wonder why changes aren't noticed.
Also have you used named-checkconf and named-checkzone
It is hard enough to debug bind, but without seeing the config files it is almost impossible, so please add them to the original post.
(I've added this as a comment to the question - I've posted as an answer because the OP is new here).
3 个服务器中的每一个都需要有相同的提示文件。 它应该有一个“.”的 NS 记录。 包含根服务器的名称和该名称的 A 记录。
根服务器应该有“.” 区设置。 这 ”。” 区域需要有“虚假”的 ns 记录。 然后，它应该具有 box1.bogus 前往 box1 和 box2.bogus 前往 box2 的 A 记录。
请注意，您不应同时使用 box1 和 box2 作为主机名和二级域的名称。 假设域是 zone1.bogus 和 zone2.bogus。
因此 box1 和 box2 应该位于伪造区域，并且包含 A 记录。 zone1和zone2应该是指向box1和box2的NS记录。
清澈如泥？ :)
Each of the 3 servers needs to have the same hints file. It should have an NS record for "." with the name of the root server and an A record for that name.
The root server should have the "." zone set up. The "." zone needs to have "bogus" with an ns record for itself. It then should have A records for box1.bogus going to box1 and box2.bogus going off to box2.
Note that you should not use box1 and box2 both as the hostnames and the names of the 2nd level domains. Let's say that the domains are zone1.bogus and zone2.bogus instead.
So box1 and box2 should be in the bogus zone, complete with A records. zone1 and zone2 should be NS records pointing to box1 and box2.
Clear as mud? :)
好的。 我看到您已经添加了配置。 出色的。
我会这样改变根区域：
我认为问题是你正在委托 itchy.bogus，所以你不能把名字放在那里。
我相信，“com”名称服务器使用提示，以便它们可以为委托区域的名称服务器提供 A 记录，但在您的情况下，确保所服务的任何给定区域仅具有子区域的委托和当前区域内的主机。
Ok. I see you've aded your configs. Excellent.
I would change the root zone thusly:
I think the issue is that you're delegating itchy.bogus, so you can't put names inside there.
The "com" name servers, I believe, use hints so that they can serve A records for name servers for delegated zones, but in your case, it's just cleaner to insure that any given zone being served only has delegations for sub-zones AND hosts within the current zone.
就像高地人一样，只能有一个。
通过使用正常的互联网根提示，您或多或少地无法使用自己的内部根，因为真正的互联网根服务器都不知道“假”。
您唯一的选择是镜像根“.”。 从“.”内的区域，然后添加“bogus”。 为此，您可以定期转储根区域并通过一些处理运行它以将自定义区域添加到其中。
一些备用 DNS 根提供商会这样做，但它们为“客户”提供根提示以供使用，但根本不引用“真实”根服务器。
...我对这个问题的理解正确吗？ 没有把握。
Like the highlander, there can be only one.
By using the normal internet root hints, you're more or less precluded from using your own internal root, because none of the real Internet root servers know about "bogus".
Your only choice would be to mirror the root "." zone from within your ".", but then add "bogus" to it. You'd do this by periodically dumping the root zone and running it through some processing to add your custom zone to it.
Some of the alternate DNS root providers do this, but they supply root hints for their "customers" to use that do not reference the "real" root servers at all.
... Am I understanding the question correctly? Not sure.
挖。 @10.0.0.1（伪造）应该返回“.”的权威记录，因为它确实对该区域具有权威性。
挖。 @10.0.0.2（痒）不应该返回“.”的权威记录，因为它不是。 当您第一次在根区域中查询名称时，它可能会返回权威记录，因为它必须递归并从权威服务器获取权威记录。 但如果您第二次执行此操作，您将获得缓存的结果，并且“aa”标志将被清除。
dig . @10.0.0.1 (bogus) should return authoritative records for '.', since it is indeed authoritative for the zone.
dig . @10.0.0.2 (itchy) should not return authoritative records for '.', since it isn't. It may return an authoritative record the first time you query for a name in the root zone, because it has to recurse and fetch an authoritative record from the authoritative server. But if you do it a 2nd time, you'll get a cached result and the 'aa' flag will be clear.
您的名称服务器不会使用提示来给出挖掘答案。 也就是说，它不会给出挖掘的提示作为答案。 它将坚持实际查询 10.0.0.1 中的 bogustld。 我认为你没有将 bogustld 设置为区域，只是伪造的。
您可能应该将 ns.bogustld 更改为 ns.bogus。 将 10.0.0.1 命名为 ns.bogus。
或者，您可以在 中添加 NS 和 SOA 记录。 对于博古斯特尔德。
如果你挖掘 ns1.bogus。 @10.0.0.2，这有效，对吧（假设上面的配置仍然存在）？
Your name server won't use the hint to give answers to dig. That is, it won't give the hint back to dig as an answer. It will insist on actually querying 10.0.0.1 for bogustld. I don't think you have bogustld set up as a zone, just bogus.
You should probably change ns.bogustld to ns.bogus. Give 10.0.0.1 the name ns.bogus.
Alternatively, you could add an NS and an SOA record in . for bogustld.
If you dig ns1.bogus. @10.0.0.2, that works, right (assuming the config above is still in place)?