Re: Automatic . NS queries from BIND
On 17/06/15 12:27, Gaurav Kansal wrote: Hi Gaurav, At most, what I can make sure is my hint file is up-to-dated with this cross check. You're better off not providing a hints file at all. BIND ships with a built-in list of hints, and it will use this if you don't provide a hints file. BIND's built-in list is updated by ISC whenever root name server addresses change, or when IPv6 addresses are added, for example. This makes your configuration a bit simpler, and you don't have to care about keeping your hints file up to date. Regards, Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
On 17/06/15 12:27, Gaurav Kansal wrote: At most, what I can make sure is my hint file is up-to-dated with this cross check. On 17.06.15 14:26, Anand Buddhdev wrote: You're better off not providing a hints file at all. BIND ships with a built-in list of hints, and it will use this if you don't provide a hints file. BIND's built-in list is updated by ISC whenever root name server addresses change, or when IPv6 addresses are added, for example. This makes your configuration a bit simpler, and you don't have to care about keeping your hints file up to date. well, the hard-coded hints file changes whenever new BIND release gets out, while the bungled hints file may be updated by packagers or manually. I'd say that the bundled hints file is likely to be newer than the hard-coded one. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Where do you want to go to die? [Microsoft] ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
On Wed, Jun 17, 2015 at 9:59 AM, Anand Buddhdev ana...@ripe.net wrote: On 17/06/15 15:00, Matus UHLAR - fantomas wrote: Hi Matus, well, the hard-coded hints file changes whenever new BIND release gets out, while the bungled hints file may be updated by packagers or manually. I'd say that the bundled hints file is likely to be newer than the hard-coded one. Root name server addresses don't change that often. Yah. I think that, if you still have a hints file from ~1995 (20 years) it will work... If you don't keep your version of BIND up to date, the worst that will happen is that you have slightly out-fo-date built-in hints. Assuming one of the root name servers had changed its address in the meantime, the practical effect of this is that upon startup, your BIND resolver's priming query has a 1 in 24 chance of timing out. If this happens, it will just try another address and succeed, and all will be well after that. This is why I prefer to depend on the built-in hints in BIND (and Unbound too, but that's off-topic), instead of the hassle of installing and maintaining a separate hints file. It just seems quite pointless. Finally, let me add that if memory serves me correctly, ISC recommends the use of built-in hints these days. Yup, it's one less thing to break... Regards, Anand ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
In article mailman.2170.1434552077.26362.bind-us...@lists.isc.org, gaurav.kan...@nic.in wrote: In case, i have my hint file in bind configuration and it also have its hard-coded one, who will get the priority. Means which file will be used by bind for getting responses from root ? The hints file takes precedence over the hard-coded ones. Otherwise, how could you run BIND on a private network not connected to the real root servers? -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
In case, i have my hint file in bind configuration and it also have its hard-coded one, who will get the priority. Means which file will be used by bind for getting responses from root ? Sent by kansal's device. On Wed, Jun 17, 2015 at 7:17 AM -0700, Anand Buddhdev ana...@ripe.net wrote: On 17/06/15 15:00, Matus UHLAR - fantomas wrote: Hi Matus, well, the hard-coded hints file changes whenever new BIND release gets out, while the bungled hints file may be updated by packagers or manually. I'd say that the bundled hints file is likely to be newer than the hard-coded one. Root name server addresses don't change that often. If you don't keep your version of BIND up to date, the worst that will happen is that you have slightly out-fo-date built-in hints. Assuming one of the root name servers had changed its address in the meantime, the practical effect of this is that upon startup, your BIND resolver's priming query has a 1 in 24 chance of timing out. If this happens, it will just try another address and succeed, and all will be well after that. This is why I prefer to depend on the built-in hints in BIND (and Unbound too, but that's off-topic), instead of the hassle of installing and maintaining a separate hints file. It just seems quite pointless. Finally, let me add that if memory serves me correctly, ISC recommends the use of built-in hints these days. Regards, Anand ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
On 17/06/15 15:00, Matus UHLAR - fantomas wrote: Hi Matus, well, the hard-coded hints file changes whenever new BIND release gets out, while the bungled hints file may be updated by packagers or manually. I'd say that the bundled hints file is likely to be newer than the hard-coded one. Root name server addresses don't change that often. If you don't keep your version of BIND up to date, the worst that will happen is that you have slightly out-fo-date built-in hints. Assuming one of the root name servers had changed its address in the meantime, the practical effect of this is that upon startup, your BIND resolver's priming query has a 1 in 24 chance of timing out. If this happens, it will just try another address and succeed, and all will be well after that. This is why I prefer to depend on the built-in hints in BIND (and Unbound too, but that's off-topic), instead of the hassle of installing and maintaining a separate hints file. It just seems quite pointless. Finally, let me add that if memory serves me correctly, ISC recommends the use of built-in hints these days. Regards, Anand ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
On Mon, Jun 15, 2015 at 5:56 AM, Gaurav Kansal gaurav.kan...@nic.in wrote: Dear Team, My caching DNS server is generating log of . NS queries to ROOT Servers. I have a hint file in my bind configuration and the same is up-to date. The same behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9 and on 9.10). It must be for some purpose (may be BIND doesn’t trust hint file and cross check it from root servers). Can anyone put some light on this. *Sample tcpdump output :-* 15:36:42.440831 IP anydnsmby.27938 k.root-servers.net.domain: 38907 [1au] NS? . (28) 15:36:43.241203 IP anydnsmby.52261 f.root-servers.net.domain: 3841 [1au] NS? . (28) 15:36:43.624041 IP anydnsmby.48889 k.root-servers.net.domain: 6314 [1au] NS? . (28) 15:36:44.424047 IP anydnsmby.65507 c.root-servers.net.domain: 27973 [1au] NS? . (28) 15:37:42.071574 IP anydnsmby.38958 i.root-servers.net.domain: 53519 [1au] NS? 117.240.177.150. (44) 15:40:11.121122 IP anydnsmby.7941 i.root-servers.net.domain: 62400 [1au] NS? 1.mr. (33) 15:45:52.780062 IP anydnsmby.49432 e.root-servers.net.domain: 54241+ [1au] NS? . (28) 15:45:59.341780 IP anydnsmby.34368 e.root-servers.net.domain: 55928+ [1au] NS? . (28) 15:46:04.487088 IP anydnsmby.35621 e.root-servers.net.domain: 7266+ [1au] NS? . (28) 15:46:35.453029 IP anydnsmby.62875 i.root-servers.net.domain: 4129 [1au] NS? comp-HP. (36) 16:16:13.747955 IP anydnsmby.39690 a.root-servers.net.domain: 8774+ [1au] NS? . (28) 16:16:20.845363 IP anydnsmby.36994 e.root-servers.net.domain: 63433+ [1au] NS? . (28) 16:16:36.746049 IP anydnsmby.42878 a.root-servers.net.domain: 48439+ [1au] NS? . (28) 16:16:42.060534 IP anydnsmby.41018 j.root-servers.net.domain: 5347+ [1au] NS? . (28) 16:16:49.081649 IP anydnsmby.53661 e.root-servers.net.domain: 54768+ [1au] NS? . (28) 16:51:14.034065 IP anydnsmby.38025 k.root-servers.net.domain: 52771 [1au] NS? 116.73.202.141. (43) 16:51:14.835539 IP anydnsmby.19616 i.root-servers.net.domain: 14926 [1au] NS? 116.73.202.141. (43) 17:25:16.706395 IP anydnsmby.58045 i.root-servers.net.domain: 30880 [1au] NS? 2.mr. (33) 17:25:16.707072 IP anydnsmby.38495 i.root-servers.net.domain: 43451 [1au] NS? 6.mr. (33) 17:25:16.707989 IP anydnsmby.35834 i.root-servers.net.domain: 61843 [1au] NS? 3.mr. (33) 17:56:44.855060 IP anydnsmby.61903 a.root-servers.net.domain: 23284 [1au] NS? 172.192.168.2. (42) Regards, Gaurav Kansal Bind has never trusted your hints file. (OK, I can't swear to v4.x of BIND, even though I did use 4.3 a very long time ago.) The file is called a hints file as it is used only to provide a starting place for your named to find the root. It's really not even needed in most cases as BIND now has a built-in set of hints that are used in the absence of a hints file. Yo0u really only need a hits file if you are using a non-standard (usually internal) root. Once named finds a responsive root from either its internal list or from the hints file, the hints are ignored. It gets a copy of the root zone and starts to figure out the fastest one for normal use. Periodically it will retry other root servers to make sure that it is always using a reasonably fast responding one. I'll admit to being unfamiliar with the algorithm used to make these periodic checks. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
The hints hopefully point eventually to an authoritative server for ..
Whatever that authoritative server says overrides any hints, just like any
other zone's authoritative NS. It does not matter how obsolete a delegation
is, so long as some authoritative NS replies, the data from the delegation
(hints) no longer matters.
HtHLen
On Monday, June 15, 2015 6:14 AM, Gaurav Kansal gaurav.kan...@nic.in
wrote:
!--#yiv5613757701 _filtered #yiv5613757701 {font-family:Cambria
Math;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5613757701
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5613757701
#yiv5613757701 p.yiv5613757701MsoNormal, #yiv5613757701
li.yiv5613757701MsoNormal, #yiv5613757701 div.yiv5613757701MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:Calibri,
sans-serif;}#yiv5613757701 a:link, #yiv5613757701
span.yiv5613757701MsoHyperlink
{color:#0563C1;text-decoration:underline;}#yiv5613757701 a:visited,
#yiv5613757701 span.yiv5613757701MsoHyperlinkFollowed
{color:#954F72;text-decoration:underline;}#yiv5613757701
span.yiv5613757701EmailStyle17 {font-family:Calibri,
sans-serif;color:windowtext;}#yiv5613757701 .yiv5613757701MsoChpDefault
{font-family:Calibri, sans-serif;} _filtered #yiv5613757701 {margin:1.0in
1.0in 1.0in 1.0in;}#yiv5613757701 div.yiv5613757701WordSection1 {}--Dear Team,
My caching DNS server is generating log of . NS queries to ROOT Servers. I
have a hint file in my bind configuration and the same is up-to date. The same
behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9 and on
9.10). It must be for some purpose (may be BIND doesn’t trust hint file and
cross check it from root servers).Can anyone put some light on this. Sample
tcpdump output :-15:36:42.440831 IP anydnsmby.27938
k.root-servers.net.domain: 38907 [1au] NS? . (28)15:36:43.241203 IP
anydnsmby.52261 f.root-servers.net.domain: 3841 [1au] NS? .
(28)15:36:43.624041 IP anydnsmby.48889 k.root-servers.net.domain: 6314 [1au]
NS? . (28)15:36:44.424047 IP anydnsmby.65507 c.root-servers.net.domain:
27973 [1au] NS? . (28)15:37:42.071574 IP anydnsmby.38958
i.root-servers.net.domain: 53519 [1au] NS? 117.240.177.150.
(44)15:40:11.121122 IP anydnsmby.7941 i.root-servers.net.domain: 62400 [1au]
NS? 1.mr. (33)15:45:52.780062 IP anydnsmby.49432 e.root-servers.net.domain:
54241+ [1au] NS? . (28)15:45:59.341780 IP anydnsmby.34368
e.root-servers.net.domain: 55928+ [1au] NS? . (28)15:46:04.487088 IP
anydnsmby.35621 e.root-servers.net.domain: 7266+ [1au] NS? .
(28)15:46:35.453029 IP anydnsmby.62875 i.root-servers.net.domain: 4129 [1au]
NS? comp-HP. (36)16:16:13.747955 IP anydnsmby.39690
a.root-servers.net.domain: 8774+ [1au] NS? . (28)16:16:20.845363 IP
anydnsmby.36994 e.root-servers.net.domain: 63433+ [1au] NS? .
(28)16:16:36.746049 IP anydnsmby.42878 a.root-servers.net.domain: 48439+
[1au] NS? . (28)16:16:42.060534 IP anydnsmby.41018 j.root-servers.net.domain:
5347+ [1au] NS? . (28)16:16:49.081649 IP anydnsmby.53661
e.root-servers.net.domain: 54768+ [1au] NS? . (28)16:51:14.034065 IP
anydnsmby.38025 k.root-servers.net.domain: 52771 [1au] NS? 116.73.202.141.
(43)16:51:14.835539 IP anydnsmby.19616 i.root-servers.net.domain: 14926
[1au] NS? 116.73.202.141. (43)17:25:16.706395 IP anydnsmby.58045
i.root-servers.net.domain: 30880 [1au] NS? 2.mr. (33)17:25:16.707072 IP
anydnsmby.38495 i.root-servers.net.domain: 43451 [1au] NS? 6.mr.
(33)17:25:16.707989 IP anydnsmby.35834 i.root-servers.net.domain: 61843
[1au] NS? 3.mr. (33)17:56:44.855060 IP anydnsmby.61903
a.root-servers.net.domain: 23284 [1au] NS? 172.192.168.2. (42) Regards,Gaurav
Kansal
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Automatic . NS queries from BIND
On Mon, Jun 15, 2015 at 3:06 PM, Kevin Oberman rkober...@gmail.com wrote: On Mon, Jun 15, 2015 at 5:56 AM, Gaurav Kansal gaurav.kan...@nic.in wrote: Dear Team, My caching DNS server is generating log of . NS queries to ROOT Servers. I have a hint file in my bind configuration and the same is up-to date. The same behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9 and on 9.10). It must be for some purpose (may be BIND doesn’t trust hint file and cross check it from root servers). Can anyone put some light on this. Sample tcpdump output :- 15:36:42.440831 IP anydnsmby.27938 k.root-servers.net.domain: 38907 [1au] NS? . (28) 15:36:43.241203 IP anydnsmby.52261 f.root-servers.net.domain: 3841 [1au] NS? . (28) 15:36:43.624041 IP anydnsmby.48889 k.root-servers.net.domain: 6314 [1au] NS? . (28) 15:36:44.424047 IP anydnsmby.65507 c.root-servers.net.domain: 27973 [1au] NS? . (28) 15:37:42.071574 IP anydnsmby.38958 i.root-servers.net.domain: 53519 [1au] NS? 117.240.177.150. (44) 15:40:11.121122 IP anydnsmby.7941 i.root-servers.net.domain: 62400 [1au] NS? 1.mr. (33) 15:45:52.780062 IP anydnsmby.49432 e.root-servers.net.domain: 54241+ [1au] NS? . (28) 15:45:59.341780 IP anydnsmby.34368 e.root-servers.net.domain: 55928+ [1au] NS? . (28) 15:46:04.487088 IP anydnsmby.35621 e.root-servers.net.domain: 7266+ [1au] NS? . (28) 15:46:35.453029 IP anydnsmby.62875 i.root-servers.net.domain: 4129 [1au] NS? comp-HP. (36) 16:16:13.747955 IP anydnsmby.39690 a.root-servers.net.domain: 8774+ [1au] NS? . (28) 16:16:20.845363 IP anydnsmby.36994 e.root-servers.net.domain: 63433+ [1au] NS? . (28) 16:16:36.746049 IP anydnsmby.42878 a.root-servers.net.domain: 48439+ [1au] NS? . (28) 16:16:42.060534 IP anydnsmby.41018 j.root-servers.net.domain: 5347+ [1au] NS? . (28) 16:16:49.081649 IP anydnsmby.53661 e.root-servers.net.domain: 54768+ [1au] NS? . (28) 16:51:14.034065 IP anydnsmby.38025 k.root-servers.net.domain: 52771 [1au] NS? 116.73.202.141. (43) 16:51:14.835539 IP anydnsmby.19616 i.root-servers.net.domain: 14926 [1au] NS? 116.73.202.141. (43) 17:25:16.706395 IP anydnsmby.58045 i.root-servers.net.domain: 30880 [1au] NS? 2.mr. (33) 17:25:16.707072 IP anydnsmby.38495 i.root-servers.net.domain: 43451 [1au] NS? 6.mr. (33) 17:25:16.707989 IP anydnsmby.35834 i.root-servers.net.domain: 61843 [1au] NS? 3.mr. (33) 17:56:44.855060 IP anydnsmby.61903 a.root-servers.net.domain: 23284 [1au] NS? 172.192.168.2. (42) Regards, Gaurav Kansal Bind has never trusted your hints file. (OK, I can't swear to v4.x of BIND, even though I did use 4.3 a very long time ago.) The file is called a hints file as it is used only to provide a starting place for your named to find the root. It's really not even needed in most cases as BIND now has a built-in set of hints that are used in the absence of a hints file. Yo0u really only need a hits file if you are using a non-standard (usually internal) root. Once named finds a responsive root from either its internal list or from the hints file, the hints are ignored. It gets a copy of the root zone and starts to figure out the fastest one for normal use. Periodically it will retry other root servers to make sure that it is always using a reasonably fast responding one. I'll admit to being unfamiliar with the algorithm used to make these periodic checks. Yah, as Kevin says, this is normal -- for more details: https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05 W -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Automatic . NS queries from BIND
Right, we know how hints files are used, but I think you guys may be missing the underlying conundrum: why is named querying the NS records of the root zone more often than the TTL of that RRset? See that there is a “NS? .” query at 15:36:44 and then another one at 15:45:52. At 15:45:52 it should have answered its client from the data it cached from the answer to the 15:36:44 query (less than 10 minutes previous). Is named not seeing a response from the root servers in question? Is the max-cache-ttl being capped at a ridiculously-small value? The NS queries of other names besides “.” itself are red herrings. They are all unique names – dot-terminated octet strings, names in the “.mr” TLD, “comp-HP.” -- and we wouldn’t expect them to have been cached previously. But an answer to “NS? .” should be cached for *days*, not just a few minutes. I’m speculating that this might not be a pure “caching DNS server” after all; it might be a forwarder with “forward first” defined. In that case, if the forwarding path experiences occasional delays, then named will fail over to trying iterative resolution, and if the routing and/or firewall rules were never set up to allow that, then the symptoms would be as documented, since named would never get a response from the root servers. General rule: use “forward only” if you must use forwarders *exclusively*; “forward first” is only for *opportunistic* forwarding, where you still have the ability to fall back to iterative resolution, if and when necessary. (Personally, I’m not much of a fan of “forward first”, since it rarely if ever produces the performance benefit expected, or, even if it lowers the average query latency, it does so at the expense of the worst-case latency -- cache miss plus slow authoritative nameservers and/or misconfigured delegations -- and it’s worst-case that causes apps to time out, to break, and ultimately, users to show up bearing pitchforks and burning oil). - Kevin From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Leonard Mills Sent: Monday, June 15, 2015 3:05 PM To: Gaurav Kansal; bind-users@lists.isc.org Subject: Re: Automatic . NS queries from BIND The hints hopefully point eventually to an authoritative server for .. Whatever that authoritative server says overrides any hints, just like any other zone's authoritative NS. It does not matter how obsolete a delegation is, so long as some authoritative NS replies, the data from the delegation (hints) no longer matters. HtH Len On Monday, June 15, 2015 6:14 AM, Gaurav Kansal gaurav.kan...@nic.inmailto:gaurav.kan...@nic.in wrote: Dear Team, My caching DNS server is generating log of . NS queries to ROOT Servers. I have a hint file in my bind configuration and the same is up-to date. The same behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9 and on 9.10). It must be for some purpose (may be BIND doesn’t trust hint file and cross check it from root servers). Can anyone put some light on this. Sample tcpdump output :- 15:36:42.440831 IP anydnsmby.27938 k.root-servers.net.domain: 38907 [1au] NS? . (28) 15:36:43.241203 IP anydnsmby.52261 f.root-servers.net.domain: 3841 [1au] NS? . (28) 15:36:43.624041 IP anydnsmby.48889 k.root-servers.net.domain: 6314 [1au] NS? . (28) 15:36:44.424047 IP anydnsmby.65507 c.root-servers.net.domain: 27973 [1au] NS? . (28) 15:37:42.071574 IP anydnsmby.38958 i.root-servers.net.domain: 53519 [1au] NS? 117.240.177.150. (44) 15:40:11.121122 IP anydnsmby.7941 i.root-servers.net.domain: 62400 [1au] NS? 1.mr. (33) 15:45:52.780062 IP anydnsmby.49432 e.root-servers.net.domain: 54241+ [1au] NS? . (28) 15:45:59.341780 IP anydnsmby.34368 e.root-servers.net.domain: 55928+ [1au] NS? . (28) 15:46:04.487088 IP anydnsmby.35621 e.root-servers.net.domain: 7266+ [1au] NS? . (28) 15:46:35.453029 IP anydnsmby.62875 i.root-servers.net.domain: 4129 [1au] NS? comp-HP. (36) 16:16:13.747955 IP anydnsmby.39690 a.root-servers.net.domain: 8774+ [1au] NS? . (28) 16:16:20.845363 IP anydnsmby.36994 e.root-servers.net.domain: 63433+ [1au] NS? . (28) 16:16:36.746049 IP anydnsmby.42878 a.root-servers.net.domain: 48439+ [1au] NS? . (28) 16:16:42.060534 IP anydnsmby.41018 j.root-servers.net.domain: 5347+ [1au] NS? . (28) 16:16:49.081649 IP anydnsmby.53661 e.root-servers.net.domain: 54768+ [1au] NS? . (28) 16:51:14.034065 IP anydnsmby.38025 k.root-servers.net.domain: 52771 [1au] NS? 116.73.202.141. (43) 16:51:14.835539 IP anydnsmby.19616 i.root-servers.net.domain: 14926 [1au] NS? 116.73.202.141. (43) 17:25:16.706395 IP anydnsmby.58045 i.root-servers.net.domain: 30880 [1au] NS? 2.mr. (33) 17:25:16.707072 IP anydnsmby.38495 i.root-servers.net.domain: 43451 [1au] NS? 6.mr. (33) 17:25
Re: Automatic . NS queries from BIND
On Mon, Jun 15, 2015 at 1:29 PM, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Right, we know how hints files are used, but I think you guys may be missing the underlying conundrum: why is named querying the NS records of the root zone more often than the TTL of that RRset? See that there is a “NS? .” query at 15:36:44 and then another one at 15:45:52. At 15:45:52 it should have answered its client from the data it cached from the answer to the 15:36:44 query (less than 10 minutes previous). Is named not seeing a response from the root servers in question? Is the max-cache-ttl being capped at a ridiculously-small value? The NS queries of other names besides “.” itself are red herrings. They are all unique names – dot-terminated octet strings, names in the “.mr” TLD, “comp-HP.” -- and we wouldn’t expect them to have been cached previously. But an answer to “NS? .” should be cached for **days**, not just a few minutes. I’m speculating that this might not be a pure “caching DNS server” after all; it might be a forwarder with “forward first” defined. In that case, if the forwarding path experiences occasional delays, then named will fail over to trying iterative resolution, and if the routing and/or firewall rules were never set up to allow that, then the symptoms would be as documented, since named would never get a response from the root servers. General rule: use “forward only” if you must use forwarders **exclusively**; “forward first” is only for **opportunistic** forwarding, where you still have the ability to fall back to iterative resolution, if and when necessary. (Personally, I’m not much of a fan of “forward first”, since it rarely if ever produces the performance benefit expected, or, even if it lowers the *average *query latency, it does so at the expense of the *worst-case* latency -- cache miss plus slow authoritative nameservers and/or misconfigured delegations -- and it’s worst-case that causes apps to time out, to break, and ultimately, users to show up bearing pitchforks and burning oil). - Kevin There is more to than TTL expiry involved. TTL on the root is pretty long (60 days). There are also the regular and far more frequent checks for fastest response. These are performed according to an algorithm in BIND that I have not seen documented. It i possible that these queries are responsible, especially as queries are going out to multiple root servers. That said, I admit that I see a real possibility that Kevin is right. I also dislike forward first. Since I am retired, I no longer manage a BIND server, so I have no logs to check on the behavior of my server. It would be interesting to see any documentation on the algorithm used to detect the closest root server as well as the log of someone else running a similar setup. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com On Monday, June 15, 2015 6:14 AM, Gaurav Kansal gaurav.kan...@nic.in wrote: Dear Team, My caching DNS server is generating log of . NS queries to ROOT Servers. I have a hint file in my bind configuration and the same is up-to date. The same behavior is occurring in multiple versions of BIND (tested on 9.7, 9.9 and on 9.10). It must be for some purpose (may be BIND doesn’t trust hint file and cross check it from root servers). Can anyone put some light on this. *Sample tcpdump output :-* 15:36:42.440831 IP anydnsmby.27938 k.root-servers.net.domain: 38907 [1au] NS? . (28) 15:36:43.241203 IP anydnsmby.52261 f.root-servers.net.domain: 3841 [1au] NS? . (28) 15:36:43.624041 IP anydnsmby.48889 k.root-servers.net.domain: 6314 [1au] NS? . (28) 15:36:44.424047 IP anydnsmby.65507 c.root-servers.net.domain: 27973 [1au] NS? . (28) 15:37:42.071574 IP anydnsmby.38958 i.root-servers.net.domain: 53519 [1au] NS? 117.240.177.150. (44) 15:40:11.121122 IP anydnsmby.7941 i.root-servers.net.domain: 62400 [1au] NS? 1.mr. (33) 15:45:52.780062 IP anydnsmby.49432 e.root-servers.net.domain: 54241+ [1au] NS? . (28) 15:45:59.341780 IP anydnsmby.34368 e.root-servers.net.domain: 55928+ [1au] NS? . (28) 15:46:04.487088 IP anydnsmby.35621 e.root-servers.net.domain: 7266+ [1au] NS? . (28) 15:46:35.453029 IP anydnsmby.62875 i.root-servers.net.domain: 4129 [1au] NS? comp-HP. (36) 16:16:13.747955 IP anydnsmby.39690 a.root-servers.net.domain: 8774+ [1au] NS? . (28) 16:16:20.845363 IP anydnsmby.36994 e.root-servers.net.domain: 63433+ [1au] NS? . (28) 16:16:36.746049 IP anydnsmby.42878 a.root-servers.net.domain: 48439+ [1au] NS? . (28) 16:16:42.060534 IP anydnsmby.41018 j.root-servers.net.domain: 5347+ [1au] NS? . (28) 16:16:49.081649 IP anydnsmby.53661 e.root-servers.net.domain: 54768+ [1au] NS? . (28) 16:51:14.034065 IP anydnsmby.38025 k.root-servers.net.domain: 52771 [1au] NS? 116.73.202.141. (43) 16:51:14.835539 IP anydnsmby.19616 i.root-servers.net.domain: 14926 [1au]
