Re: How to Setup a Name Servers visible on Internet?

On 22/06/2011 14:07, Matus UHLAR - fantomas wrote: > On 21.06.11 12:26, Metropolitan College wrote: >> I'm sorry, I forgot that a terminal mail clients don't support HTMl, > > They do. However HTML mail is hard to read and even harder to reply. > That's why I didn't read most of your former mails

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 u

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 f

Re: EDNS request problem on TTL=0 data

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

Re: Better solution than making a recursive nameserver authoritative?

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

EDNS request problem on TTL=0 data

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 t

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 words,

Re: Better solution than making a recursive nameserver authoritative?

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 2)

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 appro

Re: bind restart needed to reflect changes to dynamic zone in multiple views

> 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

Better solution than making a recursive nameserver authoritative?

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., 10.in-addr.arpa

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 sa

Re: bind restart needed to reflect changes to dynamic zone in multiple views

> 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 memor

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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

RE: bind restart needed to reflect changes to dynamic zone in multipleviews

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.or

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 probl

Re: bind restart needed to reflect changes to dynamic zone in multiple views

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 probl

bind restart needed to reflect changes to dynamic zone in multiple views

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

Re: Update-Policy "ms-self" for reverse zone dont work - please help

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 thi

Re: Logging Response Results

On Thu, Jun 23, 2011 at 02:31:22PM -0700, Ray Van Dolson 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

Re: Logging Response Results

On Thu, Jun 23, 2011 at 10:27:31PM +0200, Stefan Certic wrote a message of 65 lines which said: > stored into database (matching the initial query from query log). This may help: > We monitor our email system and may record your emails. Don't!

Re: Logging Response Results

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 a

Re: bind9 enum hack

On Jun 22, 2011 4:35 PM, "Stefan Certic" 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 4.6.1.8.

Update-Policy "ms-self" for reverse zone dont work - please help

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: zone"cp.test" { type master; file "forward/cp.test"; notify yes; update-policy {