|
|
Jim wrote:
On Jul 5, 4:45 pm, Ralph Young <yo...@xxxxxxxxxxx> 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.
|
|