Hello,
I have a basic recursive resolver configuration with Bind 9.18.19 that
acts as the resolver for some VPN roadwarrior clients (a mix of Apple
iOS and macOS clients).
Periodically I will see the following in my logs:
02-Nov-2023 15:06:27.658 resolver: info: loop detected resolving
Sarah Newman wrote:
> What should happen when for a given domain:
>
> - The domain resolves via TCP but not UDP - UDP for this domain had no
> response at all.
I would expect the domain to be completely unresolvable: the resolver will
only try TCP if it gets a truncated reaponse over UDP.
> -
On 4/23/20 12:41 PM, Chuck Aurora wrote:
On 2020-04-23 14:16, Sarah Newman wrote:
What should happen when for a given domain:
- The domain resolves via TCP but not UDP - UDP for this domain had no
response at all.
- That authoritative nameserver hosts other domains, and those domains
resolve
On 2020-04-23 14:16, Sarah Newman wrote:
What should happen when for a given domain:
- The domain resolves via TCP but not UDP - UDP for this domain had no
response at all.
- That authoritative nameserver hosts other domains, and those domains
resolve via UDP.
Do you have an example for this?
What should happen when for a given domain:
- The domain resolves via TCP but not UDP - UDP for this domain had no response
at all.
- That authoritative nameserver hosts other domains, and those domains resolve
via UDP.
I found
Hi there,
On Thu, 12 Mar 2020, G.W. Haywood wrote:
On Thu, 12 Mar 2020, ShubhamGoyal wrote:
How can i improve my recursive resolver speed.
I wonder if you have some kind of networking misconfiguration which
results in timeouts while BIND is waiting for responses. Perhaps you
will learn
On 3/12/20 11:00 AM, Fred Morris wrote:
The obvious conclusion (until disproved!) is that "DNS lookups to the
rest of the world are slow" but I wouldn't start there.
I feel like running a network sniffer (tcpdump, Wireshark, etc.) on the
recursive resolver will make it quite appa
To confirm, this is a local caching also-known-as recursive resolver. It
is quick (< 100 msec) when answering from cache, but not when it has to do
lookups itself (> 1000 msec).
On Thu, 12 Mar 2020, ShubhamGoyal wrote:
we made a recurive resolver (Cent OS 7, 8GB RAM ,250 GB Har
recursive resolver speed.
and If we apply syslog (it is a centralised logging of bind) . then any
profit for recursive resolver.
If you have anything like DNS fixups set on your routers, turn it off now.
Those don't offer any real fixups, but they do mess up DNS service instead.
In order
improve my recursive resolver speed.
I wonder if you have some kind of networking misconfiguration which
results in timeouts while BIND is waiting for responses. Perhaps you
will learn more about what is happening if you look at the network
traffic using a tool such as Wireshark.
and If we
recursive resolver speed.
and If we apply syslog (it is a centralised logging of bind) . then any
profit for recursive resolver.
In order for us to help you better, you need to provide more information. What
makes you think The recursive resolver is slow? Do you have syslog? Is the BIND
instance
In order for us to help you better, you need to provide more information.
What makes you think The recursive resolver is slow? Do you have syslog? Is
the BIND instance slow, or is it the operating system (low RAM? Slow disk?)
or is this a network-related issue?
On Thu, Mar 12, 2020 at 11:00 AM
Dear sir,
how can we improve my DNS Recursive resolver
speed.
Best Regards,
Shubham Goyal
Cyber Security Group
Centre for Development of Advanced Computing
Bangalore
Erich Eckner wrote:
>
> I'm undecided whether they're authoritative or not. On one hand, they are
> distributed via DHCP as default DNS servers, speaking for "recursive", on
> the other hand, they have matching SOA records (and I think, that means,
> they're authoritative) - maybe they're both?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On Mon, 28 Oct 2019, Tony Finch wrote:
Erich Eckner wrote:
RPZ rewrites responses as they are going out of your nameserver, so you
can't use RPZ to change the way the nameserver's resolver works (because
the resolver depends on incoming
Erich Eckner wrote:
>
> 1. Set a custom query-source (the one of the vpn interface) for that
> second-level domain. (This would also be applied to all subdomains thereof,
> right?)
>
> 2. Overwrite (by rpz?) the name-servers for that domain to the (somehow
> obtained) internal nameservers (they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I'm running bind as a recursive resolver. This box also has a vpn tunnel
to another network (not mine) with split-horizon dns (internal clients see
different NS entries than external clients; those in turn resolve
different addresses). I
On 2015-04-23 22:56, Mark Andrews wrote:
The nameservers for umea.se are broken. BIND 9.10.x Windows does
SIT by default. The correct EDNS behaviour for a server that does
not understand a EDNS option is to *ignore* the option.
Ok.
Add the following to named.conf to temporarially work
Hi
I'm troubleshooting a strange problem. Customer uses bind 9.10.1 as a recursive
resolver and they cannot resolve some domains.
Platform is windows server 2012, 64-bit
I've installed 9.9.7, 9.10.1 and 9.10.2 in my lab, only 9.9.7 can resolve
umea.se, I used the exact same configuration
as
a recursive resolver and they cannot resolve some domains.br
br
Platform is windows server 2012, 64-bitbr
br
I've installed 9.9.7, 9.10.1 and 9.10.2 in my lab, only 9.9.7 can
resolve umea.se, I used the exact same configuration in all three.br
br
With 9.10.x i get dnssec
On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
I'm trying to come up with an interim solution for my ISP's DNS
Recursive Resolver that is DNSSEC aware.
My thoughts so far:-
Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux
gives me).
Ouch! - bitten by the signing
In message 1269885784.31597.68.ca...@mjenet.posix.co.za, Mark Elkins writes:
On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
I'm trying to come up with an interim solution for my ISP's DNS
Recursive Resolver that is DNSSEC aware.
=20
My thoughts so far:-
Use BIND 9.6.1-P3
22 matches
Mail list logo
