use bind 9.8 as caching server and authoritative nameserver
Hi all , I installed a new bind caching server called nameserver.hiddendomain.be by using Ubuntu server 12.04.3 LTS with the included bind version : 9.8.1.dfsg.P1-4 for testing. We are a tiny ISP for some regional customers so we don't use forwarders, we host the caching servers for them. Recently our government obligated all ISP's to block access to child-porn, illegal betting sites, illegal file share sites etc... I have been asked now to implement this on our caching DNS servers (serve a custom zone to all of our customers that points to an IP from the government that hosts a block-page) It's the first time I try to use this mixed bind setup. (still act as caching server for our customers, but be authoritative for all domains we need to block) When I query a to-be-blocked-zone with for example: dig @localhost stop.com , I get the response I want from within our local zone file (see zone file below; /etc/bind/stop.com.zone). If I use another Ubuntu host in the same network and qery with dig @nameserver stop.com , I get the response from the Internet and not from the master zone file located on our 'nameserver'. (our test caching server seems to ignore it's master for the zone stop.com) Below you will find our config files ,I don't see the problem, thanks for your help ! Regards, Olivier (the name of my test server and the name of the zone we need to block have been replaced by fake ones for privacy reasons. Except for those names and it's IP, all other info is from my test server-setup) ---cat /etc/hosts --> 127.0.0.1 localhost IP.IP.IP.IP nameserver.hiddendomain.be nameserver # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ---cat /etc/bind/named.conf --> // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; ---cat /etc/bind/named.conf.options --> options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. // forwarders { // 0.0.0.0; // }; // // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys // dnssec-enable yes; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; ---cat /etc/bind/named.conf.local --> // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "stop.com" { type master; file "/etc/bind/stop.com.zone"; }; ---cat /etc/bind/stop.com.zone --> $TTL 86400 $ORIGIN stop.com. @ IN SOA nameserver.hiddendomain.be. hostmaster.hiddendomain.be. ( 2013101601 ; serial number YYMMDDNN 28800 ; Refresh 7200 ; Retry 864000 ; Expire 86400 ; Min TTL ) NS ns3.hiddendomain.be. NS ns4.hiddendomain.be. IN A 193.191.245.56 www IN A 193.191.245.56 ___ 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: use bind 9.8 as caching server and authoritative nameserver
You're seriously over-complicating the admin for yourselves by creating dummy zones. Look at RPZ as this will achieve what you want in a much simpler and easier to manage way. Steve On 28 October 2013 13:10, wrote: > Hi all , > > I installed a new bind caching server called nameserver.hiddendomain.be by > using Ubuntu server 12.04.3 LTS with the included bind version : > 9.8.1.dfsg.P1-4 for testing. > > We are a tiny ISP for some regional customers so we don't use forwarders, we > host the caching servers for them. > > Recently our government obligated all ISP's to block access to child-porn, > illegal betting sites, illegal file share sites etc... > I have been asked now to implement this on our caching DNS servers (serve a > custom zone to all of our customers that points to an IP from the government > that hosts a block-page) > > It's the first time I try to use this mixed bind setup. (still act as > caching server for our customers, but be authoritative for all domains we > need to block) > > When I query a to-be-blocked-zone with for example: dig @localhost stop.com > , I get the response I want from within our local zone file (see zone file > below; /etc/bind/stop.com.zone). > If I use another Ubuntu host in the same network and qery with dig > @nameserver stop.com , I get the response from the Internet and not from the > master zone file located on our 'nameserver'. (our test caching server seems > to ignore it's master for the zone stop.com) > > Below you will find our config files ,I don't see the problem, thanks for > your help ! > > Regards, > Olivier > > (the name of my test server and the name of the zone we need to block have > been replaced by fake ones for privacy reasons. Except for those names and > it's IP, all other info is from my test server-setup) > > ---cat /etc/hosts --> > > 127.0.0.1 localhost > IP.IP.IP.IPnameserver.hiddendomain.be nameserver > > # The following lines are desirable for IPv6 capable hosts > ::1 ip6-localhost ip6-loopback > fe00::0 ip6-localnet > ff00::0 ip6-mcastprefix > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > > ---cat /etc/bind/named.conf --> > > // This is the primary configuration file for the BIND DNS server named. > // > // Please read /usr/share/doc/bind9/README.Debian.gz for information on the > // structure of BIND configuration files in Debian, *BEFORE* you customize > // this configuration file. > // > // If you are just adding zones, please do that in > /etc/bind/named.conf.local > > include "/etc/bind/named.conf.options"; > include "/etc/bind/named.conf.local"; > include "/etc/bind/named.conf.default-zones"; > > ---cat /etc/bind/named.conf.options --> > > options { > directory "/var/cache/bind"; > > // If there is a firewall between you and nameservers you want > // to talk to, you may need to fix the firewall to allow multiple > // ports to talk. See http://www.kb.cert.org/vuls/id/800113 > > // If your ISP provided one or more IP addresses for stable > // nameservers, you probably want to use them as forwarders. > // Uncomment the following block, and insert the addresses replacing > // the all-0's placeholder. > > // forwarders { > // 0.0.0.0; > // }; > > > // > // If BIND logs error messages about the root key being expired, > // you will need to update your keys. See > https://www.isc.org/bind-keys > > // > dnssec-enable yes; > dnssec-validation auto; > > auth-nxdomain no;# conform to RFC1035 > listen-on-v6 { any; }; > > ---cat /etc/bind/named.conf.local --> > > // > // Do any local configuration here > // > > // Consider adding the 1918 zones here, if they are not used in your > // organization > //include "/etc/bind/zones.rfc1918"; > > zone "stop.com" > { > type master; > file "/etc/bind/stop.com.zone"; > }; > > ---cat /etc/bind/stop.com.zone --> > > $TTL 86400 > $ORIGIN stop.com. > > @ IN SOA nameserver.hiddendomain.be. > hostmaster.hiddendomain.be. ( > 2013101601 ; serial number YYMMDDNN > 28800 ; Refresh > 7200; Retry > 864000 ; Expire > 86400 ; Min TTL > ) > > NS ns3.hiddendomain.be. > NS ns4.hiddendomain.be. > > IN A 193.191.245.56 > www IN A 193.191.245.56 > > > > > ___ > 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 ___ P
Re: DNSSEC and split DNS
On 10/25/13 6:11 PM, David Newman wrote: > > > On 10/23/13 5:20 PM, Mark Andrews wrote: >> In message <5268626c.8040...@networktest.com>, David Newman writes: >>> On 10/23/13 4:28 PM, Mark Andrews wrote: You sign all versions of the zone. As for key management you can: * use the same keys in all views which makes mobile device management simpler as there is no need to distribute keys. Validating from the root will work in all cases though there is still something to be said for distributing keys for local zones locally as this prevents resolution failures when the site is disconnected from the rest of the world. * different keys per view. You will need to distribute the keys and for mobile devices they will need all sets of keys as they see both the internal and external views depending apon where they attach to the network and whether there is a VPN active. For fixed devices different keys will cause data leakage to be rejected as the leaked data won't validate. You can change strategy if you pick the wrong one. >>> >>> Thanks, makes sense. >>> >>> What about delegation? Right now, there is none between external zones >>> and internal forward zones using RFC 1918 addresses. >>> >>> I *think* option 1 would require, for example, example.org's zone to >>> include delegation and glue records for internal.example.org to keep the >>> chain of trust intact. >>> >>> And I *think* option 2 in theory could be set up as an island of trust, >>> with no delegation from parent domains. >> >> You can >> * add the delegation for internal.example.org to example.org >> and make it visible to the world with a appropriate acl on >> internal.example.org. >> * have two version of example.org, one with and one without the >> delegation for internal.example.org. > > I went this route, and encountered three issues: Answering two of my own questions. The final one remains unresolved. > > 1. After a reload, there are out-of-zone warnings for hosts in example.org: > > 25-Oct-2013 16:02:49.330 general: warning: > dynamic/example.org/example.org.db:133: ignoring out-of-zone data > (hostname.example.org) > > Both internal and external zones are called 'example.org' but each is in > a separate view. These warnings come from the example.org zone file, the > one in the external view. Root cause: An $INCLUDE statement in a zone file in the internal view called a file with a typo in its name. That zone wasn't loading as a result. > 2. With two zones using the same name, I'm unsure how to use rndc to > reload just the internal or just the external version since both use the > same name. rndc reload zone IN view > > 3. Another internal nameserver gets intermittent dig +dnssec errors on > queries for internal resources. Sometimes after a restart, the result is > NOERROR and other times it's NXDOMAIN or SERVFAIL. > > This is seen on an internal recursive nameserver (let's call it NS2). I > think this might be due to the presence of external servers in the > forwarding statement. If I comment out the external forwarders and > include only one other internal server (let's call it NS1), dig lookups > always work, including DNSSEC. > > Problem is, NS1 is currently an authoritative and recursive server, and > I'm trying to separate these functions. Is there some other way to build > up a cache and get DNSSEC data on NS2? Still stuck on this one. Authoritative and recursive servers should be separate (this is to allow trust anchors on internal zones). If delegation only happens for a zone in the internal view, how would an internal caching-only server build up a cache of both internal and external responses? What should it use as forwarders? Thanks dn > > Config details below. Thanks very much for additional troubleshooting clues. > > dn > > This is from named.conf: > > acl internal-xfer { > .. > } > > acl external-xfer { > .. > } > > acl trusted { > .. > } > > view "internal" in { > > match-clients { trusted; }; > recursion yes; > additional-from-auth yes; > additional-from-cache yes; > > .. > >zone "example.org" in { > type master; > file "dynamic/split.example.org/split.example.org.db"; > allow-query { trusted; }; > allow-transfer { internal-xfer; }; > // internal and external zones use same key > key-directory "managed-keys/example.org"; > inline-signing yes; > auto-dnssec maintain; > }; > > .. > > }; > > view "external" in { > > match-clients { any; }; > recursion no; > additional-from-auth no; > additional-from-cache no; > > .. > > zone "example.org" in { > type master; >
Reverse look-up returns root servers?
background: last month we enabled the feature on sendmail to do a reverse look-up of the name and verify the IP address before accepting an email for delivery FEATURE(`require_rdns')dnl. I know this breaks the RFC but given all the spam this actually helps weed out a few. Received a call from purchasing today, that (all of a sudden) one of our vendors is no longer able to send us email. Checking the mail log I get: Oct 28 05:30:48 smtp sendmail[9092]: r9SCUmtY009092: ruleset=check_rcpt, arg1=, relay=[198.173.12.21], reject=550 5.7.1 ... Fix reverse DNS for 198.173.12.21 Oct 28 05:30:49 smtp sendmail[9092]: r9SCUmtY009092: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=[198.173.12.21] now normally the second line should end with relay=mailgw.apollocolors.com. [198.173.12.21] (not just the IP in brackets) However, we implemented the rule over a month ago, and all of a sudden as of yesterday this stopped working?? Question: When I dig the MX record I get mailgw.apollocolors.com. pompt> dig apollocolors.com MX ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> apollocolors.com MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50104 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;apollocolors.com.INMX ;; ANSWER SECTION: apollocolors.com.3085INMX10 mailgw.apollocolors.com. ;; AUTHORITY SECTION: apollocolors.com.3332INNSns3.e2services.net. apollocolors.com.3332INNSns4.e2services.net. apollocolors.com.3332INNSns2.e2services.net. apollocolors.com.3332INNSns1.e2services.net. ;; ADDITIONAL SECTION: mailgw.apollocolors.com. 3085INA198.173.12.21 ns1.e2services.net.3079INA216.35.163.10 ns2.e2services.net.3079INA216.35.163.11 ns3.e2services.net.3079INA64.14.233.10 ns4.e2services.net.3079INA64.14.233.11 ;; Query time: 1 msec ;; SERVER: 12.238.189.39#53(12.238.189.39) ;; WHEN: Mon Oct 28 12:53:35 2013 ;; MSG SIZE rcvd: 223 When I look-up the reverse at my recursive server I get: prompt> dig -x 198.173.12.21 ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> -x 198.173.12.21 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33959 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;21.12.173.198.in-addr.arpa.INPTR ;; ANSWER SECTION: 21.12.173.198.in-addr.arpa. 8428 INPTRmailgw.apollocolors.com. ;; AUTHORITY SECTION: 12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com. ;; ADDITIONAL SECTION: auth1.dns.cogentco.com.16531IN2001:550:1:a::d auth2.dns.cogentco.com.30846IN2001:550:1:b::d auth4.dns.cogentco.com.30846IN2001:978:1:a::d auth5.dns.cogentco.com.30846IN2001:978:1:b::d ;; Query time: 1 msec ;; SERVER: 12.238.189.39#53(12.238.189.39) ;; WHEN: Mon Oct 28 12:55:16 2013 ;; MSG SIZE rcvd: 286 However, and her is the rub, when I do the same reverse look-up at any of their servers I get a list of root servers back. Shouldn't I be getting back the IP address pointer back? Also according to IntoDNS two of their servers are misconfigured or non-existant. Here is what I get instead: prompt> dig @216.35.163.10 -x 198.173.12.21 ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> @216.35.163.10 -x 198.173.12.21 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29478 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;21.12.173.198.in-addr.arpa.INPTR ;; AUTHORITY SECTION: .3600INNSj.root-servers.net. .3600INNSl.root-servers.net. .3600INNSi.root-servers.net. .3600INNSm.root-servers.net. .3600INNSa.root-servers.net. .3600INNSb.root-servers.net. .3600INNSc.root-servers.net. .3600INNSd.root-servers.net. .3600INNSe.root-servers.net. .3600INNSf.root-servers.net. .3600INNSg.root-servers.net. .3600INNSh.root-servers.net. .3600INNSk.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net.3600INA192.58.128.30 l.root-servers.net.3600INA199.7.83.42 i.root-servers.net.3600INA192.36.148.17 ;; Query time: 59 msec ;; SERVER: 216.35.163.10#53(216.35
Re: DNSSEC and split DNS
In message <526eba87.7040...@networktest.com>, David Newman writes: > > > 3. Another internal nameserver gets intermittent dig +dnssec errors on > > queries for internal resources. Sometimes after a restart, the result is > > NOERROR and other times it's NXDOMAIN or SERVFAIL. Inconsistant use of views. The NOERROR will probably be coming from a the internal view and the NXDOMAIN from the external view (or the other way around). As for SERVFAIL you may have badly configured firewalls that are dropping fragmented responses, or responses > 512 bytes resulting in excessive timeouts and excessive use of TCP. This is more visible in a newly started server. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Reverse look-up returns root servers?
On 28.10.13 16:07, Shawn Bakhtiar wrote: When I look-up the reverse at my recursive server I get: prompt> dig -x 198.173.12.21 ;; AUTHORITY SECTION: 12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com. 12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com. ;; ADDITIONAL SECTION: auth1.dns.cogentco.com.16531IN2001:550:1:a::d auth2.dns.cogentco.com.30846IN2001:550:1:b::d auth4.dns.cogentco.com.30846IN2001:978:1:a::d auth5.dns.cogentco.com.30846IN2001:978:1:b::d auth1.dns.cogentco.com. 10800 IN A 66.28.0.14 auth1.dns.cogentco.com. 43200 IN 2001:550:1:a::d auth2.dns.cogentco.com. 10800 IN A 66.28.0.30 auth2.dns.cogentco.com. 43200 IN 2001:550:1:b::d auth4.dns.cogentco.com. 10800 IN A 80.245.32.74 auth4.dns.cogentco.com. 43200 IN 2001:978:1:a::d auth5.dns.cogentco.com. 10800 IN A 80.91.64.50 auth5.dns.cogentco.com. 43200 IN 2001:978:1:b::d fix the TTLs, they should be the same. BTW, yout parent referral only contains two servers, you should ask for adding the others: 12.173.198.in-addr.arpa. 14400 IN NS auth2.dns.cogentco.com. 12.173.198.in-addr.arpa. 14400 IN NS auth1.dns.cogentco.com. -- 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. If Barbie is so popular, why do you have to buy her friends? ___ 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: DNSSEC and split DNS
On 10/28/13 1:46 PM, Mark Andrews wrote: > In message <526eba87.7040...@networktest.com>, David Newman writes: >> >>> 3. Another internal nameserver gets intermittent dig +dnssec errors on >>> queries for internal resources. Sometimes after a restart, the result is >>> NOERROR and other times it's NXDOMAIN or SERVFAIL. > > Inconsistant use of views. The NOERROR will probably be coming > from a the internal view and the NXDOMAIN from the external view > (or the other way around). The underlying question is what forwarders to use, if any, on an internal caching-only nameserver where DNSSEC and split DNS are in use. In this case, per your guidance there are two versions of some zones, with the internal version using delegation and the external not. The only way I can think of is to allow recursion on authoritative servers, but only from the caching-only servers, and put the authoritative servers in their forwarders statement. For all other clients, the only servers with recursion would be the caching-only ones. And the authoritative servers would be the only ones listed in the forwarders statement. Or is there a better way to do this? thanks dn > > As for SERVFAIL you may have badly configured firewalls that are > dropping fragmented responses, or responses > 512 bytes resulting > in excessive timeouts and excessive use of TCP. This is more visible > in a newly started server. > > Mark > ___ 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: Reverse look-up returns root servers?
I'm inksystems.com the vendor is apollocolors.com I reloaded nscd and named, and sent an email to purchasing to have them check it again. I'll also ask her to forward the information to the vendor to sync their TTLs and make sure they add the other name servers, I wonder if their changing over and that's the issue? Thanks, > Date: Mon, 28 Oct 2013 21:47:42 +0100 > From: uh...@fantomas.sk > To: bind-users@lists.isc.org > Subject: Re: Reverse look-up returns root servers? > > On 28.10.13 16:07, Shawn Bakhtiar wrote: > >When I look-up the reverse at my recursive server I get: > >prompt> dig -x 198.173.12.21 > > >;; AUTHORITY SECTION: > >12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com. > >12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com. > >12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com. > >12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com. > > > >;; ADDITIONAL SECTION: > >auth1.dns.cogentco.com.16531IN2001:550:1:a::d > >auth2.dns.cogentco.com.30846IN2001:550:1:b::d > >auth4.dns.cogentco.com.30846IN2001:978:1:a::d > >auth5.dns.cogentco.com.30846IN2001:978:1:b::d > > auth1.dns.cogentco.com. 10800 IN A 66.28.0.14 > auth1.dns.cogentco.com. 43200 IN 2001:550:1:a::d > auth2.dns.cogentco.com. 10800 IN A 66.28.0.30 > auth2.dns.cogentco.com. 43200 IN 2001:550:1:b::d > auth4.dns.cogentco.com. 10800 IN A 80.245.32.74 > auth4.dns.cogentco.com. 43200 IN 2001:978:1:a::d > auth5.dns.cogentco.com. 10800 IN A 80.91.64.50 > auth5.dns.cogentco.com. 43200 IN 2001:978:1:b::d > > fix the TTLs, they should be the same. > > BTW, yout parent referral only contains two servers, you should ask for > adding the others: > > 12.173.198.in-addr.arpa. 14400 IN NS auth2.dns.cogentco.com. > 12.173.198.in-addr.arpa. 14400 IN NS auth1.dns.cogentco.com. > > > -- > 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. > If Barbie is so popular, why do you have to buy her friends? > ___ > 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: Performance Tuning RHEL 5 and Bind
OK I have the source of the problem now I just need an elegant way to fix it and most cost ( Network TCP ) effective way to fix it The Windows Domain is responsible for X.internal.example.com and I am presently forwarding X.internal.example.com to their nameservers DC, resulting in TCP queries. Which is dragging the cache server down when PC's query for records off of [NAME].internal.example.com. I don't mind not caching X.internal.example.com so can I create an NS record or an stub entry that points the PC's else where rather than forwarding them or caching them? Thank You, Brett On Tue, Oct 22, 2013 at 9:39 PM, Alan Clegg wrote: > > On Oct 22, 2013, at 8:29 PM, brett smith wrote: > >> Yes tuning off IPTABLES conn-tracking makes a huge difference. I also >> followed: >> >> https://access.redhat.com/site/solutions/304713 >> https://access.redhat.com/site/solutions/168483 >> >> I still see some SYN_SENT from Windows PC's on tcp port 53 on the DNS >> cache server. > > You've cured the symptoms, not the illness. > > You really, REALLY need to figure out why your clients are doing TCP. You'll > see a world of difference when you solve this part of the puzzle. > > AlanC > -- > Alan Clegg | +1-919-355-8851 | a...@clegg.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: Performance Tuning RHEL 5 and Bind
On Oct 28, 2013, at 8:08 PM, brett smith wrote: > OK I have the source of the problem now I just need an elegant way to > fix it and most cost ( Network TCP ) effective way to fix it > > The Windows Domain is responsible for X.internal.example.com and I am > presently forwarding X.internal.example.com to their nameservers DC, > resulting in TCP queries. Which is dragging the cache server down when > PC's query for records off of [NAME].internal.example.com. I don't > mind not caching X.internal.example.com so can I create an NS record > or an stub entry that points the PC's else where rather than > forwarding them or caching them? Slave X.internal.example.com AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Performance Tuning RHEL 5 and Bind
Hi— On Oct 28, 2013, at 9:05 PM, Alan Clegg wrote: > Slave X.internal.example.com +1; it’s also worth looking into why there is such a high volume of DNS queries. Is it simply a big network with a lot of chatty clients? Or is TTL turned down so low that client side caching is not effective and needs to requery often? Or is something doing a host scan? If it’s your network IDS or security/network admin folks running a portscan, fine; if it’s malware or an intruder scanning the local subnet(s), one might want to notice and take steps to solve the problem rather than a symptom. Regards, — -Chuck ___ 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