Problem with Multinet cluster service names.

[Jim]

Remember this one?

On Apr 10, 11:59 pm, Malcolm Dunnett <***@spammers.are.scum>
wrote:

> I can't get multinet cluster service names to work reliably. It worked
> just fine for years in older versions of multinet, but with multinet 5.2
> the domain nameserver doesn't seem to be able to reliably see it. It was
> working for a while today but then it quit, eg:

> MALVM9> mu nslook vmscluster.mala.bc.ca localhost
> Server: LOCALHOST
> Address: 127.0.0.1


> *** LOCALHOST can't find VMSCLUSTER.MALA.BC.CA: Non-existent host/domain
> MALVM9> mu netcon domain show
> Connected to NETCONTROL server on "LOCALHOST"
> < malvm9.mala.bc.ca Network Control V5.2(10) at Thu 10-Apr-2008 8:49PM-PDT
> < Service VMSCLUSTER.MALA.BC.CA:
> < Nodename Address Rating
> < -------- --------------- ------
> < MALVM3 142.25.103.73 169
> < MALVM9 142.25.103.71 169
> < End of line

> The nameserver does not show the translation of vmscluster even though
> the mu netcon domain show displays that the two hosts are both
> contributing entries.

> The servers are Alphaservers running VMS 8.3

> Anyone else seen this problem. Anyone successfully using Multinet
> cluster service names with Multinet 5.2?

And

> Process Software has confirmed this is a bug. They've opened a defect
> report (DE 10509).

This continues to be a problem on IA64 with NAMED-040_A052 and
UCXDRIVER-050_A052 installed - any suggestions? Should this still be
failing?

[Geoff Bryant]

I see that DE 10509 is listed as an open issue in the call tracking database.
It is listed as an open issue.

I am not familiar with the code involved, but I did find an internal discussion
of it and it mentions the NAMED-030_A052 as introducing the problem and
NAMED-040_A052 as resolving it. Since it did not resolve it for you, I would
suggest falling back to the orginal NAMED images from MN 5.2 that were replaced
by ecos 030 and 040.

Unfortunately, that is all I can do for now, but will send this along for folks
to look at Monday.

info-***@process.com wrote:
>
>Remember this one?
>
>On Apr 10, 11:59 pm, Malcolm Dunnett <***@spammers.are.scum>
>wrote:
>
>> I can't get multinet cluster service names to work reliably. It worked
>> just fine for years in older versions of multinet, but with multinet 5.2
>> the domain nameserver doesn't seem to be able to reliably see it. It was
>> working for a while today but then it quit, eg:
>
>> MALVM9> mu nslook vmscluster.mala.bc.ca localhost
>> Server: LOCALHOST
>> Address: 127.0.0.1
>
>
>> *** LOCALHOST can't find VMSCLUSTER.MALA.BC.CA: Non-existent host/domain
>> MALVM9> mu netcon domain show
>> Connected to NETCONTROL server on "LOCALHOST"
>> < malvm9.mala.bc.ca Network Control V5.2(10) at Thu 10-Apr-2008 8:49PM-PDT
>> < Service VMSCLUSTER.MALA.BC.CA:
>> < Nodename Address Rating
>> < -------- --------------- ------
>> < MALVM3 142.25.103.73 169
>> < MALVM9 142.25.103.71 169
>> < End of line
>
>> The nameserver does not show the translation of vmscluster even though
>> the mu netcon domain show displays that the two hosts are both
>> contributing entries.
>
>> The servers are Alphaservers running VMS 8.3
>
>> Anyone else seen this problem. Anyone successfully using Multinet
>> cluster service names with Multinet 5.2?
>
>And
>
>> Process Software has confirmed this is a bug. They've opened a defect
>> report (DE 10509).
>
>This continues to be a problem on IA64 with NAMED-040_A052 and
>UCXDRIVER-050_A052 installed - any suggestions? Should this still be
>failing?
>

[Jackson, Craig (Gale)]

On a possibly related note, we've seen a number of occurrances where the whole
cluster service name system gets wedged under VMS 7.3-2 and MN 5.1. This has
happened more frequently as we have added members to the cluster.

We have 7 cluster service names, and we have 10 cluster nodes participating.

What typically happens is that one node crashes, and this causes the exchange
of locks which implements the cluster service name mechanism to get hung up.
We typically find that the named process on one node is holding one of the
locks for a long time. When we restart the named, it clears up.

I'm not sure if we've opened a case with Process, but I don't think so.

We're cutting down that pile of cluster service names anyway. Some haven't
been used in years, and the function of others is being moved onto a hardware
load-balancing appliance. (F5)

Craig Jackson

-----Original Message-----
From: Geoff Bryant [mailto:***@process.com]
Sent: Saturday, July 05, 2008 7:26 AM
To: info-***@process.com
Cc: ***@process.com
Subject: Re: Problem with Multinet cluster service names.

I see that DE 10509 is listed as an open issue in the call tracking database.
It is listed as an open issue.

I am not familiar with the code involved, but I did find an internal discussion
of it and it mentions the NAMED-030_A052 as introducing the problem and
NAMED-040_A052 as resolving it. Since it did not resolve it for you, I would
suggest falling back to the orginal NAMED images from MN 5.2 that were replaced
by ecos 030 and 040.

Unfortunately, that is all I can do for now, but will send this along for folks
to look at Monday.

info-***@process.com wrote:
>
>Remember this one?
>
>On Apr 10, 11:59 pm, Malcolm Dunnett <***@spammers.are.scum>
>wrote:
>
>> I can't get multinet cluster service names to work reliably. It worked
>> just fine for years in older versions of multinet, but with multinet 5.2
>> the domain nameserver doesn't seem to be able to reliably see it. It was
>> working for a while today but then it quit, eg:
>
>> MALVM9> mu nslook vmscluster.mala.bc.ca localhost
>> Server: LOCALHOST
>> Address: 127.0.0.1
>
>
>> *** LOCALHOST can't find VMSCLUSTER.MALA.BC.CA: Non-existent host/domain
>> MALVM9> mu netcon domain show
>> Connected to NETCONTROL server on "LOCALHOST"
>> < malvm9.mala.bc.ca Network Control V5.2(10) at Thu 10-Apr-2008 8:49PM-PDT
>> < Service VMSCLUSTER.MALA.BC.CA:
>> < Nodename Address Rating
>> < -------- --------------- ------
>> < MALVM3 142.25.103.73 169
>> < MALVM9 142.25.103.71 169
>> < End of line
>
>> The nameserver does not show the translation of vmscluster even though
>> the mu netcon domain show displays that the two hosts are both
>> contributing entries.
>
>> The servers are Alphaservers running VMS 8.3
>
>> Anyone else seen this problem. Anyone successfully using Multinet
>> cluster service names with Multinet 5.2?
>
>And
>
>> Process Software has confirmed this is a bug. They've opened a defect
>> report (DE 10509).
>
>This continues to be a problem on IA64 with NAMED-040_A052 and
>UCXDRIVER-050_A052 installed - any suggestions? Should this still be
>failing?
>

[Ralph Young]

Are there A records set up in your zone file data for the cluster
service hosts in question ? i.e., for the example below, there need to
be A records set up for MALVM3 and MALVM9... in some versions prior
to 5.2, these A records were 'forged'.. with the more complex attributes
(views, multiple formats, etc.) in Bind 9, this is not yet a feature.
The A records need to be manually added...

Is this working on other architectures for you but not I64?

Thanks

-Ralph Young
Process Software



Remember this one?

On Apr 10, 11:59 pm, Malcolm Dunnett <***@spammers.are.scum>
wrote:

> I can't get multinet cluster service names to work reliably. It worked
> just fine for years in older versions of multinet, but with multinet 5.2
> the domain nameserver doesn't seem to be able to reliably see it. It was
> working for a while today but then it quit, eg:

> MALVM9> mu nslook vmscluster.mala.bc.ca localhost
> Server: LOCALHOST
> Address: 127.0.0.1


> *** LOCALHOST can't find VMSCLUSTER.MALA.BC.CA: Non-existent host/domain
> MALVM9> mu netcon domain show
> Connected to NETCONTROL server on "LOCALHOST"
> < malvm9.mala.bc.ca Network Control V5.2(10) at Thu 10-Apr-2008 8:49PM-PDT
> < Service VMSCLUSTER.MALA.BC.CA:
> < Nodename Address Rating
> < -------- --------------- ------
> < MALVM3 142.25.103.73 169
> < MALVM9 142.25.103.71 169
> < End of line

> The nameserver does not show the translation of vmscluster even though
> the mu netcon domain show displays that the two hosts are both
> contributing entries.

> The servers are Alphaservers running VMS 8.3

> Anyone else seen this problem. Anyone successfully using Multinet
> cluster service names with Multinet 5.2?

And

> Process Software has confirmed this is a bug. They've opened a defect
> report (DE 10509).

This continues to be a problem on IA64 with NAMED-040_A052 and
UCXDRIVER-050_A052 installed - any suggestions? Should this still be
failing?

[Jim]

On Jul 5, 4:45 pm, Ralph Young <***@process.com> wrote:
> Are there A records set up in your zone file data for the cluster
> service hosts in question ?  i.e., for the example below, there need to
> be A records set up for MALVM3 and MALVM9... in some versions prior
> to 5.2, these A records were 'forged'.. with the more complex attributes
> (views, multiple formats, etc.) in Bind 9, this is not yet a feature.  
> The A records need to be manually added...
>
> Is this working on other architectures for you but not I64?
>
> Thanks
>
> -Ralph Young
> Process Software
>


I have not experimented with MultiNet 5.2 on Alpha yet - when I get a
chance I wll.

It has been my experience that prior to MultiNet 5.2 (on VAX and
Alpha), Multinet always forged the A RRs for the cluster serviced name
- so, no there are not A RRs in our zone master file. I take it that
you are suggesting that the zone master file be hosted on the cluster
members who will offer the cluster service as they've been delegated
authority for this name. In the past I've been running these systems
as caching-only DNSes and there has not been any zone master present.

Is it expected that an ECO or some future version of MultiNet will
restore that forgery of the A records feature?

Thanks for your feedback.

- Jim

[Malcolm Dunnett]

Jim wrote:
> On Jul 5, 4:45 pm, Ralph Young <***@process.com> wrote:
>> Are there A records set up in your zone file data for the cluster
>> service hosts in question ? i.e., for the example below, there need to
>> be A records set up for MALVM3 and MALVM9... in some versions prior
>> to 5.2, these A records were 'forged'.. with the more complex attributes
>> (views, multiple formats, etc.) in Bind 9, this is not yet a feature.
>> The A records need to be manually added...
>>
>> Is this working on other architectures for you but not I64?

I only have Multinet on Alpha (I have no VAXen left and I don't
have any Multinet licenses for the Itaniums), so I can't comment
on other architectures from direct experience.

I tried adding the addresses in the zone file:

$ttl 300
@ 604800 IN SOA vmscluster.viu.ca.
Postmaster.mala.bc.ca. (
2 ; Serial
7200 ; refresh every 2 hours
3600 ; retry every hour
12096000 ; expire in twenty weeks
300 ) ; minimum TTL

604800 IN NS malvm3.viu.ca.
IN NS malvm9.viu.ca.

MALVM3 IN A 142.25.103.73
MALVM9 IN A 142.25.103.71

but this didn't work - I get a

"*** No address (A) records available for VMSCLUSTER.VIU.CA"

What am I doing wrong?

This wouldn't really be the best solution as one of
the nice things about the cluster service names was that you could
automatically add and remove nodes from the service (eg if a node
went down the address of that node would go away ) and conversely
adding a node would add that address. How would this work with
manual A records? Would the non-existant hosts still show up at
the end of the list?

>
> It has been my experience that prior to MultiNet 5.2 (on VAX and
> Alpha), Multinet always forged the A RRs for the cluster serviced name
> - so, no there are not A RRs in our zone master file. I take it that
> you are suggesting that the zone master file be hosted on the cluster
> members who will offer the cluster service as they've been delegated
> authority for this name. In the past I've been running these systems
> as caching-only DNSes and there has not been any zone master present.
>

Yes, this is what broke with Multinet 5.2 and the new BIND version.

> Is it expected that an ECO or some future version of MultiNet will
> restore that forgery of the A records feature?
>

I have been told by support that this is being investigated, no
info on an ETA.

[Malcolm Dunnett]

Malcolm Dunnett wrote:
> $ttl 300
> @ 604800 IN SOA vmscluster.viu.ca.
> Postmaster.mala.bc.ca. (
> 2 ; Serial
> 7200 ; refresh every 2 hours
> 3600 ; retry every hour
> 12096000 ; expire in twenty weeks
> 300 ) ; minimum TTL
>
> 604800 IN NS malvm3.viu.ca.
> IN NS malvm9.viu.ca.
>
> MALVM3 IN A 142.25.103.73
> MALVM9 IN A 142.25.103.71
>
> but this didn't work - I get a
>
> "*** No address (A) records available for VMSCLUSTER.VIU.CA"
>
> What am I doing wrong?

never mind - I figure it out, I need to put :

@ IN A 142.25.103.73
@ IN A 142.25.103.71

ie give the A records to the cluster alias, not the actual hosts.

> This wouldn't really be the best solution as one of
> the nice things about the cluster service names was that you could
> automatically add and remove nodes from the service (eg if a node
> went down the address of that node would go away ) and conversely
> adding a node would add that address. How would this work with
> manual A records? Would the non-existant hosts still show up at
> the end of the list?

Figured this out too: the answer is no, the hosts that aren't up
(actually those that don't have their DNS running) will not
show up in the cluster alias even if they're defined in the
zone file. So having to set up the zone information and add
all the potential IP addresses isn't really that big an issue.

One thing that I still haven't figured out is if there's a way
to change the ttl on the cluster alias records. It appears the
ttl is always 5 minutes, regardless of the entries in the
zone file. This seems rather odd as I found a document on the
net (at http://www.process.com/techsupport/multinet/787/46.html )
that indicates the timers are much shorter for the actual
load average updates. With a 5 minute ttl it could take up to
5 minutes for the DNS to recognize that a node has come or
gone, whereas it appears the actual cluster alias service
will notice in about 1 minute - so why not make the ttl 1 minute
also?

[Jim]

On Jul 7, 5:33 am, Malcolm Dunnett <***@spammers.are.scum> wrote:
> Malcolm Dunnett wrote:
>
> One thing that I still haven't figured out is if there's a way
> to change the ttl on the cluster alias records. It appears the
> ttl is always 5 minutes, regardless of the entries in the
> zone file. This seems rather odd as I found a document on the
> net (athttp://www.process.com/techsupport/multinet/787/46.html)
> that indicates the timers are much shorter for the actual
> load average updates. With a 5 minute ttl it could take up to
> 5 minutes for the DNS to recognize that a node has come or
> gone, whereas it appears the actual cluster alias service
> will notice in about 1 minute - so why not make the ttl 1 minute
> also?- Hide quoted text -
>


Here's what has worked for me prior to MN 5.2...

SERVER-CONFIG>show/full domain
Service "DOMAINNAME":
INIT() = Merge_Image
Program = "MULTINET:LOADABLE_NAMED_CONTROL"
Parameters = "rewrite-ttl 0"

[Malcolm Dunnett]

Jim wrote:
>
> Here's what has worked for me prior to MN 5.2...
>
> SERVER-CONFIG>show/full domain
> Service "DOMAINNAME":
> INIT() = Merge_Image
> Program = "MULTINET:LOADABLE_NAMED_CONTROL"
> Parameters = "rewrite-ttl 0"

That doesn't appear to work on MN 5.2 on Alpha. When I
put it in the parameters it ignores it on a server
restart (ttl stays at 5 minutes). If I try to enter
it directly as a NETCONTROL command I get an error:

$mu netcon domain rewrite-ttl 60
Connected to NETCONTROL server on "LOCALHOST"
< malvm9.mala.bc.ca Network Control V5.2(10) at Mon 7-Jul-2008 4:40PM-PDT
< Query error, %SYSTEM-F-ILLIOFUNC, illegal I/O function code

[Jim]

On Jul 7, 7:43 pm, Malcolm Dunnett <***@spammers.are.scum> wrote:
> Jim wrote:
>
> > Here's what has worked for me prior to MN 5.2...
>
> > SERVER-CONFIG>show/full domain
> > Service "DOMAINNAME":
> >         INIT() = Merge_Image
> >         Program = "MULTINET:LOADABLE_NAMED_CONTROL"
> >         Parameters = "rewrite-ttl 0"
>
> That doesn't appear to work on MN 5.2 on Alpha. When I
> put it in the parameters it ignores it on a server
> restart (ttl stays at 5 minutes). If I try to enter
> it directly as a NETCONTROL command I get an error:
>
> $mu netcon domain rewrite-ttl 60
> Connected to NETCONTROL server on "LOCALHOST"
> < malvm9.mala.bc.ca Network Control V5.2(10) at Mon 7-Jul-2008 4:40PM-PDT
> < Query error, %SYSTEM-F-ILLIOFUNC, illegal I/O function code

And now that I've gotten DNS load balancing working again (with
assistance from Mike Corbett), I can see that this no longer works on
IA64 either. I suspect that the TTL was applied when the A records
were constructed on the fly and now the value is being taken from the
zone file. It had been our practice to set the TTL for these RRs to 0
to prevent caching and the associated round robin-ing (as might be
prevalent when larger terminal servers are used).Looks like this will
no longer be possible...

[Jim]

On Jul 14, 2:51 pm, Jim <***@saic.com> wrote:
> On Jul 7, 7:43 pm, Malcolm Dunnett <***@spammers.are.scum> wrote:
>
>
>
>
>
> > Jim wrote:
>
> > > Here's what has worked for me prior to MN 5.2...
>
> > > SERVER-CONFIG>show/full domain
> > > Service "DOMAINNAME":
> > >         INIT() = Merge_Image
> > >         Program = "MULTINET:LOADABLE_NAMED_CONTROL"
> > >         Parameters = "rewrite-ttl 0"
>
> > That doesn't appear to work on MN 5.2 on Alpha. When I
> > put it in the parameters it ignores it on a server
> > restart (ttl stays at 5 minutes). If I try to enter
> > it directly as a NETCONTROL command I get an error:
>
> > $mu netcon domain rewrite-ttl 60
> > Connected to NETCONTROL server on "LOCALHOST"
> > < malvm9.mala.bc.ca Network Control V5.2(10) at Mon 7-Jul-2008 4:40PM-PDT
> > < Query error, %SYSTEM-F-ILLIOFUNC, illegal I/O function code
>
> And now that I've gotten DNS load balancing working again (with
> assistance from Mike Corbett), I can see that this no longer works on
> IA64 either. I suspect that the TTL was applied when the A records
> were constructed on the fly and now the value is being taken from the
> zone file. It had been our practice to set the TTL for these RRs to 0
> to prevent caching and the associated round robin-ing (as might be
> prevalent when larger terminal servers are used).Looks like this will
> no longer be possible...

It appears that a "$ttl n" directive in your zone master file, where n
is an integer (I've tried as low a 1), will permit you to control the
TTL on the A RRs.

[Malcolm Dunnett]

Jim wrote:
> On Jul 14, 2:51 pm, Jim <***@saic.com> wrote:

>
> It appears that a "$ttl n" directive in your zone master file, where n
> is an integer (I've tried as low a 1), will permit you to control the
> TTL on the A RRs.

Doesn't seem to work for me:

------ zone file -----------

$ttl 1
@ 1s IN SOA malvm9.viu.ca. Postmaster.viu.ca. (
2008070602 ; Serial
7200 ; refresh every 2 hours
3600 ; retry every hour
12096000 ; expire in twenty weeks
1s) ; maximum NXDOMAIN cache

IN NS malvm3.viu.ca.
IN NS malvm9.viu.ca.

@ IN A 142.25.103.73
@ IN A 142.25.103.71

I restart the server:

MALVM9> mu netcon domain restart
Connected to NETCONTROL server on "LOCALHOST"
< malvm9.mala.bc.ca Network Control V5.2(10) at Mon 14-Jul-2008 9:55PM-PDT
< Shutting Down Nameserver
< Nameserver Shut Down
< Starting Nameserver
< Nameserver Started, process id 34600CBD

And do a lookup:

MALVM9> mu nslook vmscluster.mala.bc.ca localhost /debug
;; res_nmkquery(QUERY, 1.0.0.127.in-addr.arpa, IN, PTR)
------------
Got answer:
HEADER:
opcode = QUERY, id = 756, rcode = NOERROR
header flags: response, auth. answer, want recursion,
recursion avail.
questions = 1, answers = 1, authority records = 1,
additional = 1

QUESTIONS:
1.0.0.127.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 1.0.0.127.in-addr.arpa
name = LOCALHOST
ttl = 86400 (1D)
AUTHORITY RECORDS:
-> 0.0.127.in-addr.arpa
nameserver = LOCALHOST
ttl = 604800 (1W)
ADDITIONAL RECORDS:
-> LOCALHOST
internet address = 127.0.0.1
ttl = 86400 (1D)

------------
Server: LOCALHOST
Address: 127.0.0.1

;; res_nmkquery(QUERY, VMSCLUSTER.MALA.BC.CA, IN, A)
------------
Got answer:
HEADER:
opcode = QUERY, id = 757, rcode = NOERROR
header flags: response, auth. answer, want recursion,
recursion avail.
questions = 1, answers = 2, authority records = 0,
additional = 0

QUESTIONS:
VMSCLUSTER.MALA.BC.CA, type = A, class = IN
ANSWERS:
-> VMSCLUSTER.MALA.BC.CA
internet address = 142.25.103.71
ttl = 300 (5M)
-> VMSCLUSTER.MALA.BC.CA
internet address = 142.25.103.73
ttl = 300 (5M)

------------
Name: VMSCLUSTER.MALA.BC.CA
Addresses: 142.25.103.71, 142.25.103.73

TTL still says 5 minutes. What did I do wrong?

[Jim]

On Jul 15, 1:00 am, Malcolm Dunnett <***@spammers.are.scum> wrote:
> Jim wrote:
> > On Jul 14, 2:51 pm, Jim <***@saic.com> wrote:
>
> > It appears that a "$ttl n" directive in your zone master file, where n
> > is an integer (I've tried as low a 1), will permit you to control the
> > TTL on the A RRs.
>
> Doesn't seem to work for me:
>
>    ------ zone file -----------
>
> $ttl 1
> @       1s      IN      SOA     malvm9.viu.ca.     Postmaster.viu.ca. (
>                                          2008070602      ; Serial
>                                          7200    ; refresh every 2 hours
>                                          3600    ; retry every hour
>                                          12096000 ; expire in twenty weeks
>                                          1s) ; maximum NXDOMAIN cache
>
>                  IN      NS      malvm3.viu.ca.
>                  IN      NS      malvm9.viu.ca.
>
> @               IN      A       142.25.103.73
> @               IN      A       142.25.103.71
>
>    I restart the server:
>
> MALVM9> mu netcon domain restart
> Connected to NETCONTROL server on "LOCALHOST"
> < malvm9.mala.bc.ca Network Control V5.2(10) at Mon 14-Jul-2008 9:55PM-PDT
> < Shutting Down Nameserver
> < Nameserver Shut Down
> < Starting Nameserver
> < Nameserver Started, process id 34600CBD
>
>    And do a lookup:
>
> MALVM9> mu nslook vmscluster.mala.bc.ca localhost /debug
> ;; res_nmkquery(QUERY, 1.0.0.127.in-addr.arpa, IN, PTR)
> ------------
> Got answer:
>      HEADER:
>          opcode = QUERY, id = 756, rcode = NOERROR
>          header flags:  response, auth. answer, want recursion,
> recursion avail.
>          questions = 1,  answers = 1,  authority records = 1,
> additional = 1
>
>      QUESTIONS:
>          1.0.0.127.in-addr.arpa, type = PTR, class = IN
>      ANSWERS:
>      ->  1.0.0.127.in-addr.arpa
>          name = LOCALHOST
>          ttl = 86400 (1D)
>      AUTHORITY RECORDS:
>      ->  0.0.127.in-addr.arpa
>          nameserver = LOCALHOST
>          ttl = 604800 (1W)
>      ADDITIONAL RECORDS:
>      ->  LOCALHOST
>          internet address = 127.0.0.1
>          ttl = 86400 (1D)
>
> ------------
> Server:  LOCALHOST
> Address:  127.0.0.1
>
> ;; res_nmkquery(QUERY, VMSCLUSTER.MALA.BC.CA, IN, A)
> ------------
> Got answer:
>      HEADER:
>          opcode = QUERY, id = 757, rcode = NOERROR
>          header flags:  response, auth. answer, want recursion,
> recursion avail.
>          questions = 1,  answers = 2,  authority records = 0,
> additional = 0
>
>      QUESTIONS:
>          VMSCLUSTER.MALA.BC.CA, type = A, class = IN
>      ANSWERS:
>      ->  VMSCLUSTER.MALA.BC.CA
>          internet address = 142.25.103.71
>          ttl = 300 (5M)
>      ->  VMSCLUSTER.MALA.BC.CA
>          internet address = 142.25.103.73
>          ttl = 300 (5M)
>
> ------------
> Name:    VMSCLUSTER.MALA.BC.CA
> Addresses:  142.25.103.71, 142.25.103.73
>
> TTL still says 5 minutes. What did I do wrong?

My config where the TTL on the A records are reported as 1S is similar
to yours - if you changed your

> $ttl 1
> @ 1s IN SOA malvm9.viu.ca. Postmaster.viu.ca. (
> 2008070602 ; Serial
> 7200 ; refresh every 2 hours
> 3600 ; retry every hour
> 12096000 ; expire in twenty weeks
> 1s) ; maximum NXDOMAIN cache

to the following it would mimic mine.

$ttl 1
@ 604800 IN SOA malvm9.viu.ca.
Postmaster.viu.ca. (
2008070602 ; Serial
7200 ; refresh every 2
hours
3600 ; retry every hour
12096000 ; expire in twenty
weeks
300) ; maximum NXDOMAIN
cache

[Malcolm Dunnett]

Jim wrote:

> My config where the TTL on the A records are reported as 1S is similar
> to yours - if you changed your
>
>> $ttl 1
>> @ 1s IN SOA malvm9.viu.ca. Postmaster.viu.ca. (
>> 2008070602 ; Serial
>> 7200 ; refresh every 2 hours
>> 3600 ; retry every hour
>> 12096000 ; expire in twenty weeks
>> 1s) ; maximum NXDOMAIN cache
>
> to the following it would mimic mine.
>
> $ttl 1
> @ 604800 IN SOA malvm9.viu.ca.
> Postmaster.viu.ca. (
> 2008070602 ; Serial
> 7200 ; refresh every 2
> hours
> 3600 ; retry every hour
> 12096000 ; expire in twenty
> weeks
> 300) ; maximum NXDOMAIN
> cache
>

hmm..

If I change the $ttl directive or if I add a ttl to the SOA or NS
records the server reports the proper TTL on an nslookup of those
records.

However nothing I do appears to change the ttl on the A records.
I also note it's five minutes, which doesn't appear anywhere
in my zone file - so I conclude that the 5 minutes comes
from the default value for rewrite-ttl in the DNS parameters;
this being the value I am not currently able to change
without generating an illegal i/o function error (as per
the bug noted earlier).

Not sure why yours is working and mine isn't - different
version or patch level? Mine are:

Process Software MultiNet V5.2 Rev A-X, AlphaServer ES40, OpenVMS AXP V8.3

VERSION V5.2
REVISION A-X
DATE 25-DEC-2006
PRODUCER PSC
INSTALLED_IPAPPS YES
INSTALLED_SSH YES
INSTALLED_NFSCLIENT YES
INSTALLED_NFSSERVER YES
INSTALLED_NETWARESERVER NO
INSTALLED_SECUREIP_CLIENT YES
INSTALLED_SECUREIP_SERVER YES
INSTALLED_WEB_SERVER NO
INSTALLED_DOCUMENTATION YES
INSTALLED_LIBRARIES YES
XREPLACED IF_SE.VUI KERNEL-UPDATE-040_A052 13-OCT-2007
XREPLACED MULTINET.VUI KERNEL-UPDATE-040_A052 13-OCT-2007
XREPLACED NAMED.VUI NAMED-030_A052 13-OCT-2007
XREPLACED RNDC-CONFGEN.VUI NAMED-030_A052 13-OCT-2007
XREPLACED RNDC.VUI NAMED-030_A052 13-OCT-2007
XREPLACED PUBLICKEY-SERVER.VUI SSH-020_A052 13-OCT-2007
XREPLACED PUBLICKEY_ASSISTANT.VUI SSH-020_A052 13-OCT-2007
XREPLACED SCP-SERVER1.VUI SSH-020_A052 13-OCT-2007
XREPLACED SCP2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SFTP-SERVER2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SFTP2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SSH-ADD2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SSH-KEYGEN2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SSH2.VUI SSH-020_A052 13-OCT-2007
XREPLACED SSHD2.VUI SSH-020_A052 13-OCT-2007
XREPLACED FTP_SERVER.VUI FTP-010_A052 15-OCT-2007
XREPLACED RTSOLD.VUI RTSOLD-010_A052 15-OCT-2007
XREPLACED UCX$IPC_SHR.VUI
UCX_LIBRARY_EMULATION-020_A052 15-OCT-2007
XREPLACED SERVER.VUI MASTER_SERVER-020_A052 15-OCT-2007
XREPLACED START_SERVER_COM.VUF MASTER_SERVER-020_A052
15-OCT-2007
XREPLACED UCXDRIVER.VUI UCXDRIVER-030_A052 15-OCT-2007
XREPLACED UCX$IPC_SHR.VUI
UCX_LIBRARY_EMULATION-060_A052 18-DEC-2007
XREPLACED IF_SE.VUI KERNEL-UPDATE-060_A052 21-DEC-2007
XREPLACED MULTINET.VUI KERNEL-UPDATE-060_A052 21-DEC-2007
XREPLACED NAMED.VUI NAMED-040_A052 27-JUN-2008
XREPLACED RNDC-CONFGEN.VUI NAMED-040_A052 27-JUN-2008
XREPLACED RNDC.VUI NAMED-040_A052 27-JUN-2008

[Jim]

On Jul 15, 1:01 pm, Malcolm Dunnett <***@spammers.are.scum> wrote:
> Jim wrote:
> > My config where the TTL on the A records are reported as 1S is similar
> > to yours - if you changed your
>
> >> $ttl 1
> >> @       1s      IN      SOA     malvm9.viu.ca.     Postmaster.viu.ca. (
> >>                                          2008070602      ; Serial
> >>                                          7200    ; refresh every 2 hours
> >>                                          3600    ; retry every hour
> >>                                          12096000 ; expire in twenty weeks
> >>                                          1s) ; maximum NXDOMAIN cache
>
> > to the following it would mimic mine.
>
> > $ttl 1
> > @       604800      IN      SOA     malvm9.viu.ca.
> > Postmaster.viu.ca. (
> >                                           2008070602      ; Serial
> >                                           7200    ; refresh every 2
> > hours
> >                                           3600    ; retry every hour
> >                                           12096000 ; expire in twenty
> > weeks
> >                                           300) ; maximum NXDOMAIN
> > cache
>
> hmm..
>
> If I change the $ttl directive or if I add a ttl to the SOA or NS
> records the server reports the proper TTL on an nslookup of those
> records.
>
> However nothing I do appears to change the ttl on the A records.
> I also note it's five minutes, which doesn't appear anywhere
> in my zone file - so I conclude that the 5 minutes comes
> from the default value for rewrite-ttl in the DNS parameters;
> this being the value I am not currently able to change
> without generating an illegal i/o function error (as per
> the bug noted earlier).
>
> Not sure why yours is working and mine isn't - different
> version or patch level? Mine are:
>
> Process Software MultiNet V5.2 Rev A-X, AlphaServer ES40, OpenVMS AXP V8.3
>
> VERSION                     V5.2
> REVISION                    A-X
> DATE                        25-DEC-2006
> PRODUCER                    PSC
> INSTALLED_IPAPPS            YES
> INSTALLED_SSH               YES
> INSTALLED_NFSCLIENT         YES
> INSTALLED_NFSSERVER         YES
> INSTALLED_NETWARESERVER     NO
> INSTALLED_SECUREIP_CLIENT   YES
> INSTALLED_SECUREIP_SERVER   YES
> INSTALLED_WEB_SERVER        NO
> INSTALLED_DOCUMENTATION     YES
> INSTALLED_LIBRARIES         YES
> XREPLACED                   IF_SE.VUI KERNEL-UPDATE-040_A052 13-OCT-2007
> XREPLACED                   MULTINET.VUI KERNEL-UPDATE-040_A052 13-OCT-2007
> XREPLACED                   NAMED.VUI NAMED-030_A052 13-OCT-2007
> XREPLACED                   RNDC-CONFGEN.VUI NAMED-030_A052 13-OCT-2007
> XREPLACED                   RNDC.VUI NAMED-030_A052 13-OCT-2007
> XREPLACED                   PUBLICKEY-SERVER.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   PUBLICKEY_ASSISTANT.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SCP-SERVER1.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SCP2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SFTP-SERVER2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SFTP2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SSH-ADD2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SSH-KEYGEN2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SSH2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   SSHD2.VUI SSH-020_A052 13-OCT-2007
> XREPLACED                   FTP_SERVER.VUI FTP-010_A052 15-OCT-2007
> XREPLACED                   RTSOLD.VUI RTSOLD-010_A052 15-OCT-2007
> XREPLACED                   UCX$IPC_SHR.VUI
> UCX_LIBRARY_EMULATION-020_A052 15-OCT-2007
> XREPLACED                   SERVER.VUI MASTER_SERVER-020_A052 15-OCT-2007
> XREPLACED                   START_SERVER_COM.VUF MASTER_SERVER-020_A052
> 15-OCT-2007
> XREPLACED                   UCXDRIVER.VUI UCXDRIVER-030_A052 15-OCT-2007
> XREPLACED                   UCX$IPC_SHR.VUI
> UCX_LIBRARY_EMULATION-060_A052 18-DEC-2007
> XREPLACED                   IF_SE.VUI KERNEL-UPDATE-060_A052 21-DEC-2007
> XREPLACED                   MULTINET.VUI KERNEL-UPDATE-060_A052 21-DEC-2007
> XREPLACED                   NAMED.VUI NAMED-040_A052 27-JUN-2008
> XREPLACED                   RNDC-CONFGEN.VUI NAMED-040_A052 27-JUN-2008
> XREPLACED                   RNDC.VUI NAMED-040_A052 27-JUN-2008- Hide quoted text -
>
> - Show quoted text -

The software is different - mine is MN V5.2 on IA64 VMS V8.3

$ sear multinet:multinet_version. named,ucx
XREPLACED NAMED.VUI NAMED-030_A052 22-FEB-2008
XREPLACED RNDC-CONFGEN.VUI NAMED-030_A052 22-
FEB-2008
XREPLACED RNDC.VUI NAMED-030_A052 22-FEB-2008
XREPLACED UCXDRIVER.VUI UCXDRIVER-030_A052 22-
FEB-2008
XREPLACED UCX$IPC_SHR.VUI
UCX_LIBRARY_EMULATION-080_A052 22-FEB-2008
XREPLACED UCX$IPC_SHR.VUI
UCX_LIBRARY_EMULATION-090_A052 18-APR-2008
XREPLACED UCXDRIVER.VUI UCXDRIVER-050_A052 27-
MAY-2008
XREPLACED UCX$RPCXDR_SHR.VUI RPC40-010_A052 23-
JUN-2008

[Malcolm Dunnett]

Jim wrote:
> And now that I've gotten DNS load balancing working again (with
> assistance from Mike Corbett), I can see that this no longer works on
> IA64 either. I suspect that the TTL was applied when the A records
> were constructed on the fly and now the value is being taken from the
> zone file. It had been our practice to set the TTL for these RRs to 0
> to prevent caching and the associated round robin-ing (as might be
> prevalent when larger terminal servers are used).Looks like this will
> no longer be possible...

This has been logged as a bug by Process, so I expect a patch at some
point.

[Michael Corbett]

Jim wrote:
> On Jul 5, 4:45 pm, Ralph Young <***@process.com> wrote:
>> Are there A records set up in your zone file data for the cluster
>> service hosts in question ? i.e., for the example below, there need to
>> be A records set up for MALVM3 and MALVM9... in some versions prior
>> to 5.2, these A records were 'forged'.. with the more complex attributes
>> (views, multiple formats, etc.) in Bind 9, this is not yet a feature.
>> The A records need to be manually added...
>>
>> Is this working on other architectures for you but not I64?
>>
>> Thanks
>>
>> -Ralph Young
>> Process Software
>>
>
>
> I have not experimented with MultiNet 5.2 on Alpha yet - when I get a
> chance I wll.
>
> It has been my experience that prior to MultiNet 5.2 (on VAX and
> Alpha), Multinet always forged the A RRs for the cluster serviced name
> - so, no there are not A RRs in our zone master file. I take it that
> you are suggesting that the zone master file be hosted on the cluster
> members who will offer the cluster service as they've been delegated
> authority for this name. In the past I've been running these systems
> as caching-only DNSes and there has not been any zone master present.

Yes, the A RR records are no long forged just by having the
cluster service logical defined. The nameserver has to be configured
to be a master for the cluster service name and A RR records added for
each member.


>
> Is it expected that an ECO or some future version of MultiNet will
> restore that forgery of the A records feature?
>

I hope so.

regards
Mike

--
+-------------------------------------------------------------------------+
Michael Corbett Email: ***@process.com
Process Software Phone: [phone] x369
959 Concord St. 508 879-6994 x369
Framingham MA 01701-4682 FAX: [phone]