7 Aug
2014
7 Aug
'14
3:16 a.m.
On 2014-08-06 21:31, Rob Janssen wrote:
[..]
In general: please read the entire mail before
starting to comment on
individual paragraphs,
so you don't need to ask questions that are answered a few paragraphs
down the same mail.
(Ehmm, which exact questions that I supposedly made where answered "a
few paragraphs down"!? ;)
The system is running Debian Wheezy, all uptodate,
with bind9 version
9.8.4 plus Debian patches.
Do you mean "I am running the latest Debian stable/testing/unstable" or
do you mean "I took the patches from Debian and compiled them together"?
It is not available to the outside no so security
worries.
What exactly do you mean with that? How did you make it "not available"?
Which "outside" has no access to it? ampr.org NSs are on the wide
Internet, hence something has to be able to send it packets.
Did you maybe simply mean that it is non-recursive for non-local clients?
If it is really "not available to the outside" then that might explain
your resolution issues.
Are you allowing both UDP and TCP port 53 replies for instance?
Note that as the replies have to come in, if there is a bad path
What I see is that it does not cache ampr.org
addresses very long, but
that does not surprise me
because the default TTL in the zone is only one hour. Of course
everything would perform better
when the TTL was the more usual 24hours, but undoubtedly there was a
good reason to set this TTL.
Actually, lots of zones have short TTLs on labels so that those hosts
can be changed quickly. Typically one does set somewhat longer TTLs on
the NS hosts though.
(lately it was useful for me as I changed the external
address of the
machine and the update
was propagated quickly in DNS, but in general I would think the zone is
very static)
It is very common, do check mass-hosted services like Google, Facebook,
Akamai etc. All have nice low TTls as they want to see your queries and
be able to change them a lot.
What I am surprised about is that the measured
relative performance of
the 7 alternative DNS
servers is apparently not kept by bind long enough to be useful. The TTL
at that level is 24
hours but I think I have often seen that when doing the same lookups
within 24 hours I see lookup
delays again. The statistics command you gave does not provide that
info, I wonder if there is
some bind command to query its measured timers and preferred servers.
You can always use: "rndc dumpdb" to get the current database.
or just query and check the TTL that is left: dig @<ns> <hostname>
We have several timeservers on net-44 addresses and I
do "ntpq -p -c rv
-c mrulist" a couple of
times a day now that we are testing and deploying. It was slow every
time, of course the cached
lookups are gone because the previous try was more than an hour ago, but
apparently the DNS
preference info was gone too and queries were again sent to slow (for
me) servers.
When running such a query that you expect that is slow, run a tcpdump in
the background or anther shell, then you can see what is being queried
and takes so long. Wireshark should visualize this easily in
conversation view.
After my experimental change with the hardwired
forwarders everything
works much better.
I'm not sure I want to keep it, but it certainly indicates that there
*is* a way in which bind could
handle it more efficiently.
You just hard-coded them, thus ignoring any kind of TTL. That cannot be
done internet-scale, then you could as well just go back to /etc/hosts.
Note that you are also avoiding the actual lookup of the NS record, lots
of baby steps.
[..] Probably I should turn off the DNSSEC that has
been enabled by default by bind and Debian, that appears to cause a lot
of extra overhead too.
As asked above, did you filter out TCP for DNS?
EDNS0 quite needs it and DNSSEC needs EDNS0 due to big responses.
tcpdump/wireshark as mentioned above is your best way to debug...
Greets,
Jeroen