Tony Finch wrote on 6/11/2019 4:23 AM:
Mark Andrews wrote:
As for the NAT box that chooses those ports. If you can’t keep the
original port it should choose a ephemeral port at random. Choosing a
well known port is problematic for lots of reasons.
If I understand the documentation that was l
Barry Margolin wrote on 6/10/2019 11:18 AM:
In article ,
Blake Hudson wrote:
Thank you Mark. A popular NAT appliance manufacturer has some logic that
attempts to keep the translated source port close to the untranslated
source port which can sometimes result in the behavior I've desc
return (DROPPORT_RESPONSE);
}
return (DROPPORT_NO);
}
On 8 Jun 2019, at 7:56 am, Blake Hudson wrote:
Can someone explain why BIND (I'm using bind-9.9.4-73.el7_6.x86_64 but have
also tried 9.10.3-P4-Ubuntu) seems to ignore DNS queries initiated from
specific privileged
Can someone explain why BIND (I'm using bind-9.9.4-73.el7_6.x86_64 but
have also tried 9.10.3-P4-Ubuntu) seems to ignore DNS queries initiated
from specific privileged source ports but not others?
Example:
[root@ns ~]# dig +short -b 127.0.0.1 @localhost google.com
172.217.6.110
[root@ns ~]# di
Alex wrote on 9/30/2018 7:27 PM:
Hi,
On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote:
On 30 Sep 2018, at 09:59, Alex wrote:
It also tends to happen in bulk - there may be 25 SERVFAILs within the
same second, then nothing for another few minutes.
That really makes it seem like either you modem
Alex wrote on 9/26/2018 11:52 AM:
This is all now running on a 165/35 cable system.
Early in this thread or another, I provided a packet trace that showed
what appears to me to never have received the replies - it just times
out.
It looks like there are periods of as many as 500 querie
Tom, when your mail server establishes a connection to another host, the
receiving host will likely automatically check the PTR record of the IP
address your server used as it's source address. This PTR record should
have a corresponding A record that points to the same IP address that
was look
I've seen similar queries. Problem was traced to an open resolver at the
client end (actually many open resolvers). Patched firmware resolves the
issue with the client. Bind moving to a soft limit on the number of
recursive clients a few years back seemed to mitigate any service impact
these qu
Robert, I'm running a minimal install of CentOS7 on x86 hardware. This
system provides authoritative and recursive roles across two separate
BIND views. I also have rbldnsd serving a few zones on this system.
free reports the following after ~24 hrs of uptime:
total used
If you want to ensure well working failover you must, at some point,
test it. Even better, you may want to regularly test it (check out
Netflix's Chaos Monkey).
One way to run a simulation would be to use a firewall rule or static
route to block access between your test client/recursive server
Phil Mayers wrote the following on 11/21/2013 9:35 AM:
On 21/11/13 14:57, - wrote:
Are others seeing the named process run at 130-180% on RHEL 6? We've
No. Our RHEL6 boxes rune fine.
Fine here as well...
Here is a decently busy CentOS 6 system w/ latest BIND from RPM, 2x Xeon
CPU E5-2640
- wrote the following on 11/20/2013 12:30 PM:
Depending on your OS and Bind settings, Bind may be performing IPv6/
queries in parallel to IPv4/A queries. If IPv6 is disabled on your RHEL5
server I suspect they may only be performing IPv4/A queries during
recursion. You might check if this is
- wrote the following on 11/20/2013 10:46 AM:
Daniel, what do you see the load as? I see 4.6% CPU usage (100% possible
- 95.4% idle).
Wondering the same. Don't consider 0.00 high load. ;-)
:-) I guess I need to be a little better at explaining my self. It
made perfect sense to me.
I am ta
Daniel, what do you see the load as? I see 4.6% CPU usage (100% possible
- 95.4% idle).
I'm not sure which versions of BIND you were using on RHEL5, but the
newer versions do tend to use more CPU usage (I'll assume due to new
features, patches, etc in the BIND code).
--Blake
- wrote the fol
Phil Mayers wrote the following on 11/14/2013 2:39 AM:
On 13/11/13 22:21, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-11-13 at 16:49 -0500, Barry Margolin wrote:
It means that users will have to wait for an arbitrary
number of timeouts before the browser ca
15 matches
Mail list logo
