Re: New IP for Auth Servers

[Reindl Harald]

http://www.intodns.com/mcomdc.com

Nameserver records returned by the parent servers are:

ns1.mcomdc.com.   ['74.84.103.134']   [TTL=172800]
ns2.mcomdc.com.   ['74.84.119.134']   [TTL=172800]

h.gtld-servers.net was kind enough to give us that information.

Looks like the A records (the GLUE) got from the parent zone check are 
different than the ones got from your nameservers. You have to make sure 
your parent server has the same NS records for your zone as you do.I 
detected some problems as follows:
For ns2.mcomdc.com the parent reported: ['74.84.119.134'] and your 
nameservers reported: ['68.66.64.240']
For ns1.mcomdc.com the parent reported: ['74.84.119.134'] and your 
nameservers reported: ['97.64.168.6']


Am 16.09.2015 um 16:23 schrieb Teresa Campbell:

I recently moved my two authoritative servers to new servers on new
IP's.  I did it slowly leaving the old servers up so that everyone would
have time to receive the new IP for my domain. When I query everything
from google's free DNS servers to my own recursive servers I show the
new IP's, which is what I expected. It has been a month since I moved to
the new IP's, however I am still see a ton of query's going to the old
Auth servers. My authoritative servers do not have recursive turned on
so all the traffic I am seeing is coming from other DNS servers and they
are querying my domains for records. Did I miss something? Is that
normal? Is it safe to just turn the old servers off?

Here are the queries I am seeing in the logs

16-Sep-2015 09:00:16.807 client 78.140.179.9#22202 (ns2.mcomdc.com):
query: ns2.mcomdc.com IN A -EDC (74.84.103.134)
16-Sep-2015 09:00:16.882 client 63.79.12.161#20765 (ns1.mcomdc.com):
query: ns1.mcomdc.com IN A -EDC (74.84.103.134)


Here is the process I followed to move to the new IP's.

I brought up my new servers with the new IP's. I changed the A record
for ns1.mcomdc.com on all 4 of the servers (old and new) to the new IP
address. I waited a few hours to confirm it all looks good, then made
the change to ns2.mcomdc.com. I then left all 4 servers up for 72 hours
and came back and confirmed every major free recursive DNS server had
the new ns server IP's and any changes I made to the new server and not
the old where propagating across the internet. I am not sure it matters
here but I am running BIND 9.10.2-P4




signature.asc
Description: OpenPGP digital signature
___
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: New IP for Auth Servers

[Rich Goodson]

Teresa,

Here are the out of zone glue records for mcomdc.com  (note 
the query to a.gtld-servers.net , one of the 
authoritative servers for the com zone):
rgoodson@bcn-rgoodson1 ~ $ dig  @a.gtld-servers.net 
 ns1.mcomdc.com 

; <<>> DiG 9.9.5-P1 <<>> @a.gtld-servers.net  
ns1.mcomdc.com 
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49533
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.mcomdc.com .   IN  A

;; AUTHORITY SECTION:
mcomdc.com .172800  IN  NS  
ns1.mcomdc.com .
mcomdc.com .172800  IN  NS  
ns2.mcomdc.com .

;; ADDITIONAL SECTION:
ns1.mcomdc.com .172800  IN  A   
74.84.103.134
ns2.mcomdc.com .172800  IN  A   
74.84.119.134

;; Query time: 79 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 16 09:36:10 CDT 2015
;; MSG SIZE  rcvd: 107

rgoodson@bcn-rgoodson1 ~ $ dig +norec @68.66.64.240 ns1.mcomdc.com 


; <<>> DiG 9.9.5-P1 <<>> +norec @68.66.64.240 ns1.mcomdc.com 

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50438
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.mcomdc.com .   IN  A

;; ANSWER SECTION:
ns1.mcomdc.com .300 IN  A   
97.64.168.6

;; AUTHORITY SECTION:
mcomdc.com .300 IN  NS  
ns1.mcomdc.com .
mcomdc.com .300 IN  NS  
ns2.mcomdc.com .

;; ADDITIONAL SECTION:
ns2.mcomdc.com .300 IN  A   
68.66.64.240

;; Query time: 51 msec
;; SERVER: 68.66.64.240#53(68.66.64.240)
;; WHEN: Wed Sep 16 09:36:49 CDT 2015
;; MSG SIZE  rcvd: 107

What you need to do is log in to Network Solutions (your registrar) and update 
the IP addresses that they have for ns1.mcomdc.com  and 
ns2.mcomdc.com .  They in turn will update the ‘com’ 
zone with new glue records for ns1.mcomdc.com  and 
ns2.mcomdc.com .

-Rich

> On Sep 16, 2015, at 9:23 AM, Teresa Campbell  > wrote:
> 
> I recently moved my two authoritative servers to new servers on new IP's.  I 
> did it slowly leaving the old servers up so that everyone would have time to 
> receive the new IP for my domain. When I query everything from google's free 
> DNS servers to my own recursive servers I show the new IP's, which is what I 
> expected. It has been a month since I moved to the new IP's, however I am 
> still see a ton of query's going to the old Auth servers. My authoritative 
> servers do not have recursive turned on so all the traffic I am seeing is 
> coming from other DNS servers and they are querying my domains for records. 
> Did I miss something? Is that normal? Is it safe to just turn the old servers 
> off? 
> 
> Here are the queries I am seeing in the logs
> 
> 16-Sep-2015 09:00:16.807 client 78.140.179.9#22202 (ns2.mcomdc.com 
> ): query: ns2.mcomdc.com  IN 
> A -EDC (74.84.103.134)
> 16-Sep-2015 09:00:16.882 client 63.79.12.161#20765 (ns1.mcomdc.com 
> ): query: ns1.mcomdc.com  IN 
> A -EDC (74.84.103.134)
> 
> 
> Here is the process I followed to move to the new IP's.
> 
> I brought up my new servers with the new IP's. I changed the A record for 
> ns1.mcomdc.com  on all 4 of the servers (old and new) 
> to the new IP address. I waited a few hours to confirm it all looks good, 
> then made the change to ns2.mcomdc.com . I then left 
> all 4 servers up for 72 hours and came back and confirmed every major free 
> recursive DNS server had the new ns server IP's and any changes I made to the 
> new server and not the old where propagating across the internet. I am not 
> sure it matters here but I am running BIND 9.10.2-P4
> 
> Thanks,
> 
> Teresa Campbell
>  
>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
> 

New IP for Auth Servers

[Teresa Campbell]

I recently moved my two authoritative servers to new servers on new IP's.  I 
did it slowly leaving the old servers up so that everyone would have time to 
receive the new IP for my domain. When I query everything from google's free 
DNS servers to my own recursive servers I show the new IP's, which is what I 
expected. It has been a month since I moved to the new IP's, however I am still 
see a ton of query's going to the old Auth servers. My authoritative servers do 
not have recursive turned on so all the traffic I am seeing is coming from 
other DNS servers and they are querying my domains for records. Did I miss 
something? Is that normal? Is it safe to just turn the old servers off?

Here are the queries I am seeing in the logs

16-Sep-2015 09:00:16.807 client 78.140.179.9#22202 (ns2.mcomdc.com): query: 
ns2.mcomdc.com IN A -EDC (74.84.103.134)
16-Sep-2015 09:00:16.882 client 63.79.12.161#20765 (ns1.mcomdc.com): query: 
ns1.mcomdc.com IN A -EDC (74.84.103.134)


Here is the process I followed to move to the new IP's.

I brought up my new servers with the new IP's. I changed the A record for 
ns1.mcomdc.com on all 4 of the servers (old and new) to the new IP address. I 
waited a few hours to confirm it all looks good, then made the change to 
ns2.mcomdc.com. I then left all 4 servers up for 72 hours and came back and 
confirmed every major free recursive DNS server had the new ns server IP's and 
any changes I made to the new server and not the old where propagating across 
the internet. I am not sure it matters here but I am running BIND 9.10.2-P4

Thanks,

Teresa Campbell


___
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: New IP for Auth Servers

[Mark Andrews]

This sort of of thing is *supposed* to be caught by the Registry
or by their proxy the Registrar.  Teresa, if you failed to receive
a notification that your glue records were wrong you should be
asking why you are paying good money for registry services that are
not being performed to agreed specifications.

RFC 1034 and the requirements specified therein predate the assignment
of the registry role to the current registrar so there is no excuse
of "we didn't know we were required to check".

Mark

RFC 1034 4.2.2. Administrative considerations

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.



In message , Rich Goodson
 writes:
>
> Teresa,
>
> Here are the out of zone glue records for mcomdc.com 
> (note the query to a.gtld-servers.net , one
> of the authoritative servers for the com zone):
> rgoodson@bcn-rgoodson1 ~ $ dig  @a.gtld-servers.net
>  ns1.mcomdc.com 
>
> ; <<>> DiG 9.9.5-P1 <<>> @a.gtld-servers.net 
> ns1.mcomdc.com 
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49533
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.mcomdc.com . IN  A
>
> ;; AUTHORITY SECTION:
> mcomdc.com .  172800  IN  NS  
> ns1.mcomdc.com .
> mcomdc.com .  172800  IN  NS  
> ns2.mcomdc.com .
>
> ;; ADDITIONAL SECTION:
> ns1.mcomdc.com .  172800  IN  
> A 74.84.103.134
> ns2.mcomdc.com .  172800  IN  
> A 74.84.119.134
>
> ;; Query time: 79 msec
> ;; SERVER: 192.5.6.30#53(192.5.6.30)
> ;; WHEN: Wed Sep 16 09:36:10 CDT 2015
> ;; MSG SIZE  rcvd: 107
>
> rgoodson@bcn-rgoodson1 ~ $ dig +norec @68.66.64.240 ns1.mcomdc.com
> 
>
> ; <<>> DiG 9.9.5-P1 <<>> +norec @68.66.64.240 ns1.mcomdc.com
> 
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50438
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.mcomdc.com . IN  A
>
> ;; ANSWER SECTION:
> ns1.mcomdc.com .  300 IN  
> A 97.64.168.6
>
> ;; AUTHORITY SECTION:
> mcomdc.com .  300 IN  NS  
> ns1.mcomdc.com .
> mcomdc.com .  300 IN  NS  
> ns2.mcomdc.com .
>
> ;; ADDITIONAL SECTION:
> ns2.mcomdc.com .  300 IN  
> A 68.66.64.240
>
> ;; Query time: 51 msec
> ;; SERVER: 68.66.64.240#53(68.66.64.240)
> ;; WHEN: Wed Sep 16 09:36:49 CDT 2015
> ;; MSG SIZE  rcvd: 107
>
> What you need to do is log in to Network Solutions (your registrar) and
> update the IP addresses that they have for ns1.mcomdc.com
>  and ns2.mcomdc.com .
> They in turn will update the ‘com’ zone with new glue records for
> ns1.mcomdc.com  and ns2.mcomdc.com
> .
>
> -Rich
>
> > On Sep 16, 2015, at 9:23 AM, Teresa Campbell  > wrote:
> >
> > I recently moved my two authoritative servers to new servers on new
> IP's.  I did it slowly leaving the old servers up so that everyone would
> have time to receive the new IP for my domain. When I query everything
> from google's free DNS servers to my own recursive servers I show the new
> IP's, which is what I expected. It has been a month since I moved to the
> new IP's, however I am still see a ton of query's going to the old Auth
> servers. My authoritative servers do not have recursive turned on so all
> the traffic I am seeing is coming from other DNS servers and they are
> querying my domains for records. Did I miss something? Is that normal? Is
> it safe to just turn the old servers off?
> >
> > Here are the queries I am seeing in the logs
> >
> > 16-Sep-2015 09:00:16.807 client 78.140.179.9#22202 (ns2.mcomdc.com
> ): query: ns2.mcomdc.com 
> IN A 

Re: New IP for Auth Servers

[Reindl Harald]

Am 17.09.2015 um 02:54 schrieb Mark Andrews:

This sort of of thing is *supposed* to be caught by the Registry
or by their proxy the Registrar.  Teresa, if you failed to receive
a notification that your glue records were wrong you should be
asking why you are paying good money for registry services that are
not being performed to agreed specifications.

RFC 1034 and the requirements specified therein predate the assignment
of the registry role to the current registrar so there is no excuse
of "we didn't know we were required to check".

Mark

RFC 1034 4.2.2. Administrative considerations

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so


they where originally not wrong, the IP's changed and in that case you 
need to inform the registry to change the GLUE records - how should they 
know and even if the ymonitor it - in what timeframe?


don't get me wrong but if you change the GLUE IP'S for a domain you need 
to coordinate that - been there once- forget that too in that case but i 
admit as it happened it was only my fault and nobody elses




signature.asc
Description: OpenPGP digital signature
___
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

Multiple queries for same host

[Alex]

HI,

I have a fedora22 system with bind-9.10.2 that is configured to be
authoritative for its domain and also provides recursive query
services for a number of trusted hosts.

I'm seeing a situation where multiple queries for the same host are
occurring in the logs, and I don't understand why. In this case, it's
queries to IPs at spamhaus, although I've changed my key and our
public IP to 192.168.1.27 in this example:

16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
(254.223.16.69.mykey.sbl.dq.spamhaus.net): query:
254.223.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
(254.223.16.69.mykey.zen.dq.spamhaus.net): query:
254.223.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
16-Sep-2015 20:18:47.948 queries: client 192.168.1.27#34798
(254.222.16.69.mykey.sbl.dq.spamhaus.net): query:
254.222.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
(254.222.16.69.mykey.zen.dq.spamhaus.net): query:
254.222.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
(13.185.69.216.mykey.sbl.dq.spamhaus.net): query:
13.185.69.216.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)

It appears to happen most frequently with spamhaus queries, but also
occurs with random other domains.

Can someone help me understand why this is happening? Is the query
being broken down into multiple pieces, perhaps?

I've included my named.conf here in case I'm missing something, in
hopes someone could help me review.

acl "trusted" {
{ 127.0.0.0/8; };
{ 192.168.1.0/24; };
};

options {
version "None of your business.";

transfers-out 200;

// The following paths are necessary for this chroot
listen-on-v6 { none; };
listen-on port 53 { 192.168.1.3; 127.0.0.1; };

directory "/var/named";
dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE
pid-file "/var/run/named/named.pid";// _PATH_PIDFILE
statistics-file "/var/named/data/named.stats"; // _PATH_STATS
memstatistics-file "/var/tmp/named.memstats";   // _PATH_MEMSTATS
// End necessary chroot paths

check-names master warn;/* default. */
datasize 20M;
allow-transfer {
127.0.0.1;
192.168.1.3;
192.168.1.27;
};
// Prevent outsiders from using juggernaut
// as their name server for unauthorized queries
allow-query { trusted; };
allow-recursion { trusted; };
};

logging {

category default { named_info; };
category general { named_info; };
category lame-servers { null; };

// Configure general default info
channel named_info {
file "/var/log/named.info.log" versions 4 size 10m;
severity info;
print-time yes;
print-category yes;
};

};

zone "." {
type hint;
file "/var/named/named.ca";
};

zone "localhost" {
type master;
file "masters/localhost";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};

zone "0.0.127.in-addr.arpa" {
type master;
file "masters/db.127.0.0";
allow-update { none; };
allow-transfer { any; };
};

zone "0/27.1.168.192.in-addr.arpa" {
type master;
file "masters/db.1.168.192";
allow-query { any; };
allow-transfer { trusted; };
};

zone "mydomain.com" {
type master;
file "masters/db.mydomain.com";
allow-query { any; };
allow-transfer { trusted; };
};
___
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: New IP for Auth Servers

[Mark Andrews]

In message <55fa109f.10...@thelounge.net>, Reindl Harald writes:
> Am 17.09.2015 um 02:54 schrieb Mark Andrews:
> > This sort of of thing is *supposed* to be caught by the Registry
> > or by their proxy the Registrar.  Teresa, if you failed to receive
> > a notification that your glue records were wrong you should be
> > asking why you are paying good money for registry services that are
> > not being performed to agreed specifications.
> >
> > RFC 1034 and the requirements specified therein predate the assignment
> > of the registry role to the current registrar so there is no excuse
> > of "we didn't know we were required to check".
> >
> > Mark
> >
> > RFC 1034 4.2.2. Administrative considerations
> >
> > As the last installation step, the delegation NS RRs and glue RRs
> > necessary to make the delegation effective should be added to the parent
> > zone.  The administrators of both zones should insure that the NS and
> > glue RRs which mark both sides of the cut are consistent and remain so
>
> they where originally not wrong, the IP's changed and in that case you
> need to inform the registry to change the GLUE records - how should they
> know and even if the ymonitor it - in what timeframe?

If it goes longer than a day then something is wrong.  It isn't
that hard to check every delegation NS RRset and every glue RRset
daily.  It isn't that hard to put those that are inconsistent onto
a list to perform a recheck the next day and if they are still
inconsistent send a email to the zone contacts.  As this is the
registry they should have valid contact details or the registrar
should and can act as their proxy.

> don't get me wrong but if you change the GLUE IP'S for a domain you need
> to coordinate that - been there once- forget that too in that case but i
> admit as it happened it was only my fault and nobody elses

And the point of having the registry check is to catch errors.  They
can then send email reminders.

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: Multiple queries for same host

[Barry Margolin]

In article ,
 Alex  wrote:

> HI,
> 
> I have a fedora22 system with bind-9.10.2 that is configured to be
> authoritative for its domain and also provides recursive query
> services for a number of trusted hosts.
> 
> I'm seeing a situation where multiple queries for the same host are
> occurring in the logs, and I don't understand why. In this case, it's
> queries to IPs at spamhaus, although I've changed my key and our
> public IP to 192.168.1.27 in this example:
> 
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.223.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.223.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.948 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.222.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.222.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (13.185.69.216.mykey.sbl.dq.spamhaus.net): query:
> 13.185.69.216.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 
> It appears to happen most frequently with spamhaus queries, but also
> occurs with random other domains.

If the client application doesn't have a cache, it will repeat queries 
like this.

> 
> Can someone help me understand why this is happening? Is the query
> being broken down into multiple pieces, perhaps?

What makes you think that? They're all the same full name, not broken 
down.

> 
> I've included my named.conf here in case I'm missing something, in
> hopes someone could help me review.

You need to be looking at the client, not the server, to see why it's 
repeating the same query.

> 
> acl "trusted" {
> { 127.0.0.0/8; };
> { 192.168.1.0/24; };
> };
> 
> options {
> version "None of your business.";
> 
> transfers-out 200;
> 
> // The following paths are necessary for this chroot
> listen-on-v6 { none; };
> listen-on port 53 { 192.168.1.3; 127.0.0.1; };
> 
> directory "/var/named";
> dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE
> pid-file "/var/run/named/named.pid";// _PATH_PIDFILE
> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
> memstatistics-file "/var/tmp/named.memstats";   // _PATH_MEMSTATS
> // End necessary chroot paths
> 
> check-names master warn;/* default. */
> datasize 20M;
> allow-transfer {
> 127.0.0.1;
> 192.168.1.3;
> 192.168.1.27;
> };
> // Prevent outsiders from using juggernaut
> // as their name server for unauthorized queries
> allow-query { trusted; };
> allow-recursion { trusted; };
> };
> 
> logging {
> 
> category default { named_info; };
> category general { named_info; };
> category lame-servers { null; };
> 
> // Configure general default info
> channel named_info {
> file "/var/log/named.info.log" versions 4 size 10m;
> severity info;
> print-time yes;
> print-category yes;
> };
> 
> };
> 
> zone "." {
> type hint;
> file "/var/named/named.ca";
> };
> 
> zone "localhost" {
> type master;
> file "masters/localhost";
> check-names fail;
> allow-update { none; };
> allow-transfer { any; };
> };
> 
> zone "0.0.127.in-addr.arpa" {
> type master;
> file "masters/db.127.0.0";
> allow-update { none; };
> allow-transfer { any; };
> };
> 
> zone "0/27.1.168.192.in-addr.arpa" {
> type master;
> file "masters/db.1.168.192";
> allow-query { any; };
> allow-transfer { trusted; };
> };
> 
> zone "mydomain.com" {
> type master;
> file "masters/db.mydomain.com";
> allow-query { any; };
> allow-transfer { trusted; };
> };

-- 
Barry Margolin
Arlington, MA
___
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