Re: BIND ignores queries from specific privileged source ports
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 linked previously https://www.cisco.com/c/en/us/td/docs/security/asa/asa910/configuration/firewall/asa-910-firewall-config/nat-basics.html#ID-2090-0438 I think the option that does the right thing is "flat" without "include-reserve". Yes, that was my understanding as well. Unfortunately the flat option is not available in most NAT modes and seems to present itself only when also using a PAT pool in a manual (twice) NAT configuration. Interestingly enough, older versions of the ASA (7.x) did not require this extra configuration as they did not attempt to use source ports below 1024 for PAT. I'm sure there's a reason Cisco added the newer logic in ASA 8.x which sometimes does use ports < 1024, I'm just not sure what that reason could have been. --Blake ___ 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: BIND ignores queries from specific privileged source ports
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 described
where DNS queries use the well known source port of protocols that are
abuse prone:
https://www.cisco.com/c/en/us/td/docs/security/asa/asa910/configuration/firewall/asa-910-firewall-config/nat-basics.html#ID-2090-0438
I don't see a configuration option within BIND to change that behavior,
just a BIND compile time option (which I probably won't change since
software and upgrades are managed via yum/apt). I will look for another
avenue to resolve this issue.
--Blake
Mark Andrews wrote on 6/7/2019 9:44 PM:
Named drops those ports as they can be used in reflection attacks.
Sane NAT developers avoid those ports for just that reason. The
full list is below.
static int
ns_client_dropport(in_port_t port) {
switch (port) {
case 7: /* echo */
case 13: /* daytime */
case 19: /* chargen */
case 37: /* time */
return (DROPPORT_REQUEST);
case 464: /* kpasswd */
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 source ports but not others?
Example:
[root@ns ~]# dig +short -b 127.0.0.1 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#1 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#50 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#19 @localhost google.com
;; connection timed out; no servers could be reached
[root@ns ~]# dig +short -b 127.0.0.1#14 @localhost google.com
172.217.6.110
[root@ns ~]# dig +short -b 127.0.0.1#13 @localhost google.com
;; connection timed out; no servers could be reached
While it would be ideal for clients to use source port randomization and
initiate queries from random ephemeral ports, I don't control all the clients
or the NAT routers in between the client and the server. Queries using a source
port of 13 and 19 are dropped while queries from port 1, 50, and 14 are
answered. This has been confirmed via a network capture as well. I checked the
ARM, but didn't see what knob(s) I could tweak to control this behavior. Anyone
know?
Thanks,
--Blake
___
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
BIND ignores queries from specific privileged source ports
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 ~]# dig +short -b 127.0.0.1#1 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#50 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#19 @localhost google.com ;; connection timed out; no servers could be reached [root@ns ~]# dig +short -b 127.0.0.1#14 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#13 @localhost google.com ;; connection timed out; no servers could be reached While it would be ideal for clients to use source port randomization and initiate queries from random ephemeral ports, I don't control all the clients or the NAT routers in between the client and the server. Queries using a source port of 13 and 19 are dropped while queries from port 1, 50, and 14 are answered. This has been confirmed via a network capture as well. I checked the ARM, but didn't see what knob(s) I could tweak to control this behavior. Anyone know? Thanks, --Blake ___ 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: BIND and UDP tuning
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 or you ISP is interfering somehow, or is simply not able to keep up. I'm leaning towards that, too. The problem persists even when using the provider's DNS servers. I thought for sure I'd see some verifiable info from other people having problems with cable, such as from dslreports, etc, but there really hasn't been anything. The comment made about DOCSIS earlier in this thread was helpful. Do you believe it could be impacting all data, not just bind/DNS/UDP? Do people not generally use cable as even a fallback link for secondary services? I figured it was because there's no SLA, not because it doesn't work well with many protocols. I'd imagine services like Netflix and youtube don't have problems is because they 1) don't require a lot of DNS traffic and 2) http is a really simple protocol and 3) the link is probably engineered to be used for that? Overall it probably depends on volume and application. Cable works well as a transport, but is not the same as DSL, ethernet, or GPON. If you have the need to send 500+ pps, then Cable may not meet your needs. If you are running a high volume mail server you probably do need to run a local resolver to query services like SpamHaus, SORBs, and others due to the terms of service of these services and the rate limiting that they apply which would prevent you from using your upstream provider's DNS servers or a public DNS service like Google/Quad9/1.1.1.1. I would, however, recommend that you ensure your system has at least 2 resolvers configured in /etc/resolv.conf. If the first (local resolver) fails to resolve a query, then your system should retry the second server before giving up and returning a failure to Postfix. Again, if you're using free RBL services that second resolver may need to be one of your own and not one shared with other folks. The occasional timeout might delay email, but should not prevent SMTP from functioning because A) DNS timeouts are considered to be a temporary error, and B) the default behavior of SMTP is to queue and retry if there is a timeout or temporary failure. Another angle to look at the problem from is if you believe the network can't handle more than X query volume, reduce your query volume below X to see if this resolves your issue. I operate dozens of email servers and they do not generate the query volume you describe. Perhaps you are querying too many RBLs and it may pay to be more selective. I find SpamHaus and SpamCop to be the best two RBLs. If you want to pick another one or two, that seems reasonable. I would not recommend more RBLs within Postfix. --Blake ___ 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: BIND and UDP tuning
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 queries per second, although the usual amount is closer to 200 per second. DOCSIS cable systems use an upstream request/grant system to avoid collisions (they act as a hub where only one cable modem in the node can transmit at the same time). This leads to low pps rates compared with ethernet. Even a 10M ethernet connection (1k-10k pps) will outperform a 1gig cable connection (a few hundred pps). Based on the info you've provided, I suspect that you may be running into this limit. As another poster suggested, you might consider moving your DNS server to a VPS hosted on an ethernet connection at a location more suited for DNS server operation or otherwise try to leverage your upstream provider's DNS or an outside DNS server. --Blake ___ 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: Multiple A records and reverse DNS
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 looked up in the PTR record. This is sometimes referred to as a "verified" hostname. Without this, receiving mail servers may sometimes log your rDNS as unknown, which can look spammy to subsequent spam filters. You can have any number of other A records that point to your server, they are irrelevant to PTR verification. Example: Your reverse zone: 1.1.1.1.in-addr.arpa.INPTRmail.adi.com. Your adi.com zone: mail.adi.com.INA1.1.1.1 smtp.adi.com.INA1.1.1.1 www.adi.com.INA1.1.1.1 foo.adi.com.INCNAMEwww.adi.com. All the matters to PTR verification is that 1.1.1.1 has a PTR record and that PTR record exists as an A or CNAME that eventually points back to 1.1.1.1 As others have pointed out, this is best common practice for outgoing mail servers aka mail relays; However, I generally recommend having valid PTR records and having matching forward records for any servers. Maybe it's just me, but most of my server's send email - even MX servers (they do create NDR notices from time to time). --Blake Thomas Schulz wrote on 3/17/2016 8:53 AM: This is not a BIND question but I hope people here will know the answer. We are switching service providers and I understand that many email SPAM prevention systems insist on the reverse DNS matching the forward DNS. If I have two A records for our mail server and the reverse record matches one of them, will that be good enough. Or will the fact that the other A record does not match cause trouble. Tom Schulz Applied Dynamics Intl. sch...@adi.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 ___ 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: BIND recursive - DNS Nonsense Name Attacks
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 queries had. --Blake Neil wrote on 5/28/2015 6:08 PM: Hi Bind users, Just wondering if anyone else has seen the DNS nonsense name attacks on their recursives? Any way to mitigate such attacks? Currently running version 9.10, I already ACL's and have RPZ deployed but this is a reactive solution. I read that fetches-per-server and fetches-per-zone have been deployed to subscription releases, any time line for code to be released in the public version? Anything else I can do? Some tcpdump logs 17:35:26.520596 IP 211.27.99.62.1028 210.50.44.4.53: 17436+ A? nbpdrsthvwxlm.w.jiajiaxhhq.com. (52) 17:35:26.572225 IP 211.27.99.62.1028 210.50.44.4.53: 17437+ A? gcjycliyggj.w.jiajiaxhhq.com. (50) 17:35:26.604453 IP 211.27.99.62.1028 210.50.44.4.53: 17438+ A? zvltevrzkmfhtcq.w.jiajiaxhhq.com. (54) 17:35:26.605662 IP 211.27.99.62.1028 210.50.44.4.53: 17439+ A? xcfpgnlbbwvwoyk.w.jiajiaxhhq.com. (54) 17:35:26.63 IP 211.27.99.62.1028 210.50.44.4.53: 17440+ A? ttqikqwpcvk.w.jiajiaxhhq.com. (50) 17:35:26.704413 IP 211.27.99.62.1028 210.50.44.4.53: 17441+ A? abcqrsghijxlz.w.jiajiaxhhq.com. (52) 17:35:26.704950 IP 211.27.99.62.1028 210.50.44.4.53: 17442+ A? aopdefthijklm.w.jiajiaxhhq.com. (52) 17:35:26.715783 IP 211.27.98.70.1029 210.50.44.4.53: 63183+ A? eqw.w.jiajiaxhhq.com. (42) 17:35:26.760114 IP 210.50.8.23.41508 210.50.44.4.53: 56630+ A? yjmtmpqxwbuh.w.jiajiaxhhq.com. (51) 17:35:26.762262 IP 210.50.8.23.41508 210.50.44.4.53: 54127+ A? abelutejkzcl.w.jiajiaxhhq.com. (51) 17:35:26.835637 IP 211.27.99.62.1028 210.50.44.4.53: 17443+ A? nbcqrsthvwxym.w.jiajiaxhhq.com. (52) Thanks Neil ___ 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: Value of memory
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 free sharedbuffers cached Mem: 10071492 9128089158684 16880764 319180 -/+ buffers/cache: 5928649478628 Swap: 5185532 05185532 I, too, find that my CentOS 6 systems are using ~ 2GB of RAM. Memory usage on C7 appears to be down compared to a similarly configured C6 name server. Hope this provides a reference point. --Blake Robert Moskowitz wrote the following on 8/6/2014 10:39 PM: I have a server that is only running bind 9.8.2 (Centos 6.5). It has 2Gb memory and free reports ~1.7Gb used. I am looking at replacing this server with an armv7 board running Redsleeve (until Centos 7 is out and stable for armv7). I have a choice of boards, one with 1Gb memory ($60) and one with 2Gb memory ($90). This server servers out my zones and supports the couple handfull of systems on my net. I would like to eventually get to DNSSEC, but that is another stalled project. About the only meaningful difference between the two boards (btw, Cubieboard2 and Cubietruck) for my needs is the memory. I know more memory is better, but how much better? Oh, why the move to arm? Power consumption. ROI for the C2 board is one year just on power saving. ___ 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: Name-server redundancy
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 and one or more of the authoritative DNS servers. However, this is no substitute for an actual test to determine how different client applications will behave. --Blake Sid Shapiro wrote the following on 6/9/2014 4:56 PM: Again - thanks for the quick response - that'll teach me to post without all the facts. I simply don't remember what the specific error was, darn it. It might have been NXDOMAIN or SERVFAIL - I didn't write it down. The test I was running was on a barely, if ever used, domain, so I was pretty sure it wasn't cached anywhere. I'm trying to figure out ways to test this without taking name servers offline :-) -- Sid Shapiro sid_shap...@bio-rad.com mailto:sid_shap...@bio-rad.com Bio-Rad Corporate IT - Desk: (510) 741-6846 Mobile: (510) 224-4343 ___ 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: RHEL 6 CPU load
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 (the cores typically run at 1200MHz). 1 [|24.7%] 13 [||| 12.1%] Tasks: 411, 107 thr, 446 kthr; 5 running 2 [|| 10.2%] 14 [||1.3%] Load average: 0.71 0.83 0.90 3 [ 6.5%] 15 [||| 4.5%] 4 [||| 4.5%] 16 [ 6.4%] 5 [||| 4.4%] 17 [||1.9%] 6 [| 0.6%] 18 [||3.2%] 7 [||| 3.8%] 19 [||2.5%] 8 [| 0.6%] 20 [| 0.6%] 9 [||1.3%] 21 [ 0.0%] 10 [ 0.0%] 22 [ 0.0%] 11 [||| 10.8%] 23 [| 0.6%] 12 [ 0.0%] 24 [ 0.0%] Mem[|||34455/64375MB] Swp[ 0/9607MB] PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 1862 named 20 0 1960M 203M 2900 S 10.8 0.3 46:47.44 ├─ /usr/sbin/named -u named 1888 named 20 0 1960M 203M 2900 S 0.6 0.3 5:11.81 │ ├─ /usr/sbin/named -u named 1887 named 20 0 1960M 203M 2900 S 0.0 0.3 0:07.57 │ ├─ /usr/sbin/named -u named 1886 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.64 │ ├─ /usr/sbin/named -u named 1885 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.95 │ ├─ /usr/sbin/named -u named 1884 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.78 │ ├─ /usr/sbin/named -u named 1883 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.46 │ ├─ /usr/sbin/named -u named 1882 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.81 │ ├─ /usr/sbin/named -u named 1881 named 20 0 1960M 203M 2900 S 1.3 0.3 1:43.79 │ ├─ /usr/sbin/named -u named 1880 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1879 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.51 │ ├─ /usr/sbin/named -u named 1878 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.71 │ ├─ /usr/sbin/named -u named 1877 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.73 │ ├─ /usr/sbin/named -u named 1876 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.78 │ ├─ /usr/sbin/named -u named 1875 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1874 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1873 named 20 0 1960M 203M 2900 S 1.3 0.3 1:43.57 │ ├─ /usr/sbin/named -u named 1872 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.92 │ ├─ /usr/sbin/named -u named 1871 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.60 │ ├─ /usr/sbin/named -u named 1870 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1869 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.87 │ ├─ /usr/sbin/named -u named 1868 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.43 │ ├─ /usr/sbin/named -u named 1867 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1866 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.42 │ ├─ /usr/sbin/named -u named 1865 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1864 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1863 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.76 │ └─ /usr/sbin/named -u named And here's a less loaded CentOS 5 server (2x Xeon E5620 which typically runs at 1600MHz per core): 1 [ 0.0%] Tasks: 1962, 64 thr; 2 running 2 [| 4.2%] Load average: 0.48 0.44 0.50 3 [|| 1.2%] 4 [| 0.6%] 5 [ 0.0%] 6 [ 0.0%] 7 [| 0.6%] 8 [|| 1.2%] 9 [ 0.0%] 10 [||| 9.0%] 11 [ 84.4%] 12 [|| 1.2%] 13 [| 0.6%] 14
Re: RHEL 6 CPU load
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 following on 11/20/2013 9:37 AM: We recently upgraded one of our DNS servers to RHEL 6. The other two servers are running RHEL 5. The new system is showing much higher CPU load than the other two (RHEL 5 machines sit around 11-15%). I am not sure if this is related to the OS versions or something else. The build procedure for the new system is completely different than before which could also be the cause. Any ideas why this could be happening? top last pid: 9651; load avg: 0.00, 0.00, 0.00; up 2+01:08:04 08:31:10 647 processes: 1 running, 646 sleeping CPU states: 1.4% user, 0.0% nice, 3.2% system, 95.4% idle, 0.0% iowait Kernel: 137575 ctxsw, 7682 intr Memory: 2023M used, 21G free, 318M buffers, 747M cached Swap: 26G free PID USERNAME THR PRI NICE SIZE RES SHR STATE TIME CPU COMMAND 8566 root 27 200 1921M 296M 2848K sleep 26:56 132% named rndc status version: 9.9.4-P1 () id:07aaf1ef CPUs found: 24 worker threads: 24 UDP listeners per interface: 24 number of zones: 169 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 22/9900/1 tcp clients: 0/100 server is up and running -- Daniel ___ 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: RHEL 6 CPU load
- 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 talking about the named process which can run up to 180% during the day. When it is doing this the system still has very low load. 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 following on 11/20/2013 9:37 AM: We recently upgraded one of our DNS servers to RHEL 6. The other two servers are running RHEL 5. The new system is showing much higher CPU load than the other two (RHEL 5 machines sit around 11-15%). I am not sure if this is related to the OS versions or something else. The build procedure for the new system is completely different than before which could also be the cause. Any ideas why this could be happening? Were the configure options the same when you built on 5.x vs 6.x? You can see that with named -V. You mention a different build procedure -- do you mean named or OS? As a first step I would focus on those differences. FWIW I have moved about 30 recursive resolvers with the highest iterative workload I've had the privilege of managing to centos 6.x and had no ill effects so I don't think it's simply the OS itself. Again, it made perfect sense to me. I am talking about the OS builds. Bind is compiled with the exact same options and the configs for this system is identical to the other slave server. 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, at least in part, responsible for the additional load. The issue for me is the HIGH CPU use for named. It is much lower for our RHEL 5 systems. You didn't provide the same CPU information about your RHEL 5 builds as you did for your RHEL6 system, so I just responded about the information you did provide. Are these 24/32 core systems? Do the same number of named child processes run on both the RHEL5 and RHEL6 systems? I'm going to assume that you've already examined query load on the servers and found them similar. --Blake ___ 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: RHEL 6 CPU load
- 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, at least in part, responsible for the additional load. I just compiled a version of bind on the RHEL 6 system with ipv6 disabled and the results were the same. You didn't provide the same CPU information about your RHEL 5 builds as you did for your RHEL6 system, so I just responded about the information you did provide. Are these 24/32 core systems? Do the same number of named child processes run on both the RHEL5 and RHEL6 systems? I'm going to assume that you've already examined query load on the servers and found them similar. The other system only has 16 CPUs but named runs at a third of the CPU that the RHEL 6 box does. RHEL 5: version: 9.9.4-P1 () id:07aaf1ef CPUs found: 16 worker threads: 16 UDP listeners per interface: 16 number of zones: 169 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 30/9900/1 tcp clients: 0/100 server is up and running What about the information from top? When comparing RHEL5 and RHEL6 systems, I would compare the total CPU usage of the server (out of 100% not 2400% or 1600%). Since the hardware is different, comparing a 16 named threads on a 16 core box at ???MHz against a 24 core box with 24 named threads at ???MHz may not necessarily be valid. If the CPUs are running at the same frequency (look at what speed they are actually running at vs the max speed... see /proc/cpuinfo ) then you can probably account for the 16 vs 24 core difference pretty easily. If the CPUs run at more than negligibly different frequencies you will have to factor that into any comparison or make the frequencies the same to make a 1:1 good comparison. --Blake ___ 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: Can I have Inbound load balancing achieved with below settings
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 can give them an error message. Well, the browser *could* of course give a message like I have tried $N out of $M possible ip addresses with no success - do you want to abandon this? at any time while trying that collection of ip addresses. The other approach is to try them all in parallel, sort of like ipv4 and ipv6 parallel connection attempts in http://tools.ietf.org/html/rfc6555 Parallel is bad - they *should* be stagged by $RTT*$FACTOR, otherwise you just flood the link with SYN SYN/ACK packets, all but one of which are wasted, and may have consumed bandwidth, buffer space, NAT and firewall session resources, to name but a few. I think there are better solutions than publishing an enormous list of A/ records, personally, and I think it's good that browser manufacturers aren't blasting out 6 SYNs every time someone types www.google.com... On a related note, I have seen recent Comtrend DSL modems (w/ integrated router and DNS cache) send out parallel DNS requests to both of the configured DNS servers. The debug log on the modem indicates that the modem throws away latter responses. I agree that staggered might be a softer approach that is less resource intensive and will likely achieve the same (or perhaps better) result if all services are working. In the case of degraded service, the more aggressive parallel client will likely be faster. As a server and network admin, I guess we have to anticipate and prepare for clients that might be considered borderline abusive. --Blake ___ 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
