use bind 9.8 as caching server and authoritative nameserver

2013-10-28 Thread bind-check


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

2013-10-28 Thread Steven Carr
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

2013-10-28 Thread David Newman
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?

2013-10-28 Thread Shawn Bakhtiar
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

2013-10-28 Thread Mark Andrews

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?

2013-10-28 Thread Matus UHLAR - fantomas

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

2013-10-28 Thread David Newman
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?

2013-10-28 Thread Shawn Bakhtiar
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

2013-10-28 Thread brett smith
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

2013-10-28 Thread Alan Clegg

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

2013-10-28 Thread Charles Swiger
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