ACL ?
Greetings:
Trying to implement acl in my named.conf... for Bind 9.2.2
acl eagle { 192.168.1.0/24; localhost; };
But when I issued an reload, I got:
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error]
/etc/named.conf:2: unknown option 'acl'
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error] reloading
configuration failed: failure
Help?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ACL ?
Worked like a charm.
Thanks.
-John
Alan Clegg wrote:
John D. Vo wrote:
Greetings:
Trying to implement acl in my named.conf... for Bind 9.2.2
acl eagle { 192.168.1.0/24; localhost; };
But when I issued an reload, I got:
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error]
/etc/named.conf:2: unknown option 'acl'
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error] reloading
configuration failed: failure
Move the ACL out of the options { } stanza.
AlanC
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ACL ?
In message 49c79d6b.7060...@eagle.net, John D. Vo writes:
Greetings:
Trying to implement acl in my named.conf... for Bind 9.2.2
acl eagle { 192.168.1.0/24; localhost; };
But when I issued an reload, I got:
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error]
/etc/named.conf:2: unknown option 'acl'
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error] reloading
configuration failed: failure
You have the acl in the wrong place in named.conf. It should be
like:
acl {
};
options {
};
not
options {
acl { ... };
...
};
Mark
Help?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ACL ?
On Mar 23 2009, John D. Vo wrote:
Trying to implement acl in my named.conf... for Bind 9.2.2
acl eagle { 192.168.1.0/24; localhost; };
But when I issued an reload, I got:
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error]
/etc/named.conf:2: unknown option 'acl'
Mar 23 08:55:39 ns1 named[13578]: [ID 866145 daemon.error] reloading
configuration failed: failure
Well, you ought to have let us see what was in line 1 of /etc/named.conf,
but I guess you have put your ACL definition inside the options
statement. It should be a separate statement.
A couple of points:
1. You can (and should) test a new named.conf for syntax errors in
advance by using the named-checkconf program.
2. BIND 9.2.2 is very very old. The whole of the 9.2.x series is EOL
(and that was after 9.2.9). It's long past time that you upgraded.
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Server names for query
On Mon, Mar 23, 2009 at 3:20 PM, Kevin Darcy k...@chrysler.com wrote: For the *initial* NS query, I believe BIND will resolve those names down to a flat set of addresses, all of which have equal chance of being tried, so, yes, if a given NS name resolves to more addresses than other names, it is more likely to be tried on the initial NS query. But that's just the *initial* NS query. Once BIND, and/or virtually any other full-resolver implementation, builds up a history of how fast each nameserver responds (based on round-trip-time or RTT), it will start using nameservers which respond faster (although there is some banding that occurs, so that nameservers which respond more-or-less at the same speed get tried equally often). So if the point of your question is to try to control the distribution of query load to nameservers, be aware that this will be determined much more by the speed at which they respond, respectively, to clients, than to how the NS names are organized. Clients gravitate to faster servers. If the extra volume causes the fast servers to bog down and be slower, then clients gravitate away from them, and some sort of query-volume equilibrium is achieved between all of the nameservers which are published for the zone. In a sense, it is auto-tuning in this regard. Thanks, Kevin. My analysis is more based on collective queries (i.e., from clients in diverse geographical/network locations), rather than from any particular client. So the point of my question is determining whether it would be expected that the *total* number of queries from different clients for a given domain would be distributed roughly proportional to the number of A records corresponding to each NS target in the NS RR set for the domain. The 'rndc dumpdb -cache' command seems pretty useful in looking at the server stats on client server. However, it organizes stats by name (rather than by IP address), so it doesn't help clarify the issue in the RFC. Best regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Server names for query
Casey Deccio wrote: On Mon, Mar 23, 2009 at 3:20 PM, Kevin Darcy k...@chrysler.com wrote: For the *initial* NS query, I believe BIND will resolve those names down to a flat set of addresses, all of which have equal chance of being tried, so, yes, if a given NS name resolves to more addresses than other names, it is more likely to be tried on the initial NS query. But that's just the *initial* NS query. Once BIND, and/or virtually any other full-resolver implementation, builds up a history of how fast each nameserver responds (based on round-trip-time or RTT), it will start using nameservers which respond faster (although there is some banding that occurs, so that nameservers which respond more-or-less at the same speed get tried equally often). So if the point of your question is to try to control the distribution of query load to nameservers, be aware that this will be determined much more by the speed at which they respond, respectively, to clients, than to how the NS names are organized. Clients gravitate to faster servers. If the extra volume causes the fast servers to bog down and be slower, then clients gravitate away from them, and some sort of query-volume equilibrium is achieved between all of the nameservers which are published for the zone. In a sense, it is auto-tuning in this regard. Thanks, Kevin. My analysis is more based on collective queries (i.e., from clients in diverse geographical/network locations), rather than from any particular client. So the point of my question is determining whether it would be expected that the *total* number of queries from different clients for a given domain would be distributed roughly proportional to the number of A records corresponding to each NS target in the NS RR set for the domain. It all depends on where the clients are and how quickly the nameservers can answer queries for the zone. A nameserver that can answer more quickly for a given community of clients will attract more queries from those clients, over time. It's only the initial query that can really be weighted in the way you describe. After that, the clients auto-tune their nameserver selection choices according to load, network latency, etc. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Root Server Simulation Communication Problem
Hi Ben,
Thanks for reply now my root server (rootns.man) is responding to
abc.com. after enabling the recursion to Yes in abc.com server, now my
question is, Is my abc.com still called authoritative Name server or a
caching name server I was intend to set up a authoritative name server,
and hope by enabling recursion iam still authoritative server.
Regards
Mani
From: Ben Bridges [mailto:bbrid...@springnet.net]
Sent: Friday, March 20, 2009 8:35 PM
To: T MANIKANDAN-PKXR74; bind-users@lists.isc.org
Subject: RE: Root Server Simulation Communication Problem
You have recursion disabled on your abc.com server, and I believe that
is preventing your query from succeeding. My understanding is that the
contents of the root hints file are not stored in the server's cache
(which means, I think, that they are not themselves returned in response
to queries for those records). Since you have recursion disabled on
abc.com, it is never using its root hints to query your root server
(rootns.man) for the NS and A records for the root zone (which sounds
obfuscated, but it is done that way because the root servers themselves
have the most current list of servers for the root zone).
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@lists.isc.org
Subject: Root Server Simulation Communication Problem
Hi,
I am trying to set up lab which replicates the root server
also. ( DNS with Root server simulation for Intranet),
Basically I have two servers one abc.com as authoritative server
and the other rootns.man acting as root server. running BIND 9 on both.
I have done the following things in my named.conf file
options {
directory /var/named;
recursion no;
};
zone . {
type hint;
file root;
};
zone abc.com IN {
type master;
file forward;
};
zone 10.168.192.in-addr.arpa IN {
type master;
file reverse;
};
My root File (Points to another DNS acting as Root server let us
call rootns.man)
. 86400 IN NS rootns.man.
rootns.man. 86400 IN A 1.2.3.4
My Forward and reverse file
$TTL 3600
@ IN SOA abc.com. root.abc.com. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
abc.com. IN A 192.168.10.12
$TTL 3600
@ IN SOA abc.com. root.abc.com.(
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
12 IN PTR abc.com.
In the other DNS server rootns.man (acting root server)
zone . IN {
type master;
file forward;
};
Forward file in roons.man server
$TTL86400
@ IN SOA rootns.man root.rootns.man (
42 ; serial
(d. adams)
3H ;
refresh
15M ; retry
1W ; expiry
1D );
minimum
. IN NS rootns.man.
rootns.man. IN A1.2.3.4
Once completing this I have a minor problem that is my abc.com
server is not able to determine the root server (rootns.man) IP address.
attached the DIG output from abc.com server. can any one please help me
in resolving this issue.
Regards
Mani
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
