Hello,
I am running bind 9.8 with GSS-TSIG on a SuSE Enterprise 11 PL 1 Server.
For my forward zones I have the following rules:
zonecp.test {
type master;
file forward/cp.test;
notify yes;
update-policy {
On Jun 22, 2011 4:35 PM, Stefan Certic ste...@routotelecom.com wrote:
zone 4.6.1.8.3.e164enum {
type forward;
forwarders {127.0.0.1 port 5200;};
};
zone e164enum {
type master;
file /etc/bind/enum.conf;
};
...
What i am trying to achieve, is:
- Match everything that begins with
Unfortunately not, since billing is per query based, and each zone can have
different pricing. Also, results per query are very important for analytical
purposes in order to be able to spot problems in case some of forward zones
stop wroking and/or provide unacceptable sucess rates.
Anyway, i
On Thu, Jun 23, 2011 at 10:27:31PM +0200,
Stefan Certic ste...@routotelecom.com wrote
a message of 65 lines which said:
stored into database (matching the initial query from query log).
This may help: http://www.dnsmezzo.net/
We monitor our email system and may record your emails.
Don't!
On Thu, Jun 23, 2011 at 02:31:22PM -0700,
Ray Van Dolson rvandol...@esri.com wrote
a message of 37 lines which said:
If you're handy with Python, pcapy[1]
Quite limited.
and impacket[2]
No IPv6 support. And, anyway, neither pcapy nor impacket parses the
DNS (if you read French, see
If I'm not mistaken, ms-self means that the client's hostname must match the
name of the record being updated. This is not the case in the reverse space,
where record names end in in-addr.arpa instead of cp.test.
Your DHCP server should own the reverse space. I don't know how else to manage
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic
On 06/24/11 08:22, Brian J. Murrell wrote:
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I
On 24/06/11 14:22, Brian J. Murrell wrote:
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I
On 11-06-24 09:57 AM, Lyle Giese wrote:
It's expected behavior in a way.
Given your explanation, indeed. :-)
You are probably making this change in
the internal view and the internal named process knows about the change
and reloads the zone.
The external view's process is unaware of
I wonder if pointing to different file names with one being a symbolic
link to the other would work? That way you'd only have to create and
update the one file but the transfer would transfer two separate files.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
On 06/24/11 09:21, Brian J. Murrell wrote:
On 11-06-24 09:57 AM, Lyle Giese wrote:
It's expected behavior in a way.
Given your explanation, indeed. :-)
You are probably making this change in
the internal view and the internal named process knows about the change
and reloads the zone.
The
A. I guess I had not considered how BIND handles views and that
it's done with a separate process per view. But I only have one named
process, so I suppose it's threading for each view.
No, the views will all share the same process and thread(s), but they are
separate chunks of memory,
On 11-06-24 12:39 PM, Evan Hunt wrote:
You can specify the view in the reload command:
$ rndc reload example.com in external
But reload doesn't work for dynamic zones:
# rndc reload rbl.interlinx.bc.ca in greatunwashed
rndc: 'reload' failed: dynamic zone
and since I want the same
Currently the two recursive caching nameservers for clients on our network are
also authoritative for a few zones. In particular, they are authoritative for:
1) our main forward zone (columbia.edu) in order to provide an internal view of
the zone
2) RFC 1918 reverse zones (e.g.,
But reload doesn't work for dynamic zones:
Do the internal and external versions *both* need to be dynamic?
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
The master/slave approach really works better, though. Something like
On 11-06-24 01:47 PM, Evan Hunt wrote:
Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
Yeah. I got the master/slave approach
On 06/24/2011 10:39, David Coulthart wrote:
Currently the two recursive caching nameservers for clients on our network are
also authoritative for a few zones. In particular, they are authoritative for:
1) our main forward zone (columbia.edu) in order to provide an internal view of
the zone
On 6/24/2011 2:51 PM, Brian J. Murrell wrote:
The data really does need to be quite in sync though. I'm not sure a
period of less than a second or two is going to be acceptable.:-(
Do you have control of the update process. You could potentially send
and update to both views (in other
Hi,
I'm investigating an outage that happened on a bind server. It was
configured as a caching resolving name server. It was forwarding for
one specific zone. This zone had two nameservers/forwarders of which one
at some point was unreachable due to a cable cut. The other nameserver
turned out
On 06/24/2011 06:39 PM, David Coulthart wrote:
configure the zone as forward first, the recursive nameserver gets
back the NS delegation then uses that to perform an iterative query
against the authoritative nameserver for the subdomain. This
actually seems like it might solve my issues. Are
Hi Paul,
Which version of named are you running? You've likely run into an issue
that we've seen before - basically, as you have surmised, your server
has to retry each query and never gets a response regarding edns (so it
can't remember). Let me know which version you are running and I'll
On 11-06-24 03:19 PM, David Sparro wrote:
Do you have control of the update process.
Sure.
You could potentially send
and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to update?
I think
you'd need separate zone files
On 06/24/2011 10:47 PM, Brian J. Murrell wrote:
On 11-06-24 03:19 PM, David Sparro wrote:
Do you have control of the update process.
Sure.
You could potentially send
and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to
24 matches
Mail list logo
