Another BIND vulnerability (cache poisoning) - VMS

This is a discussion on Another BIND vulnerability (cache poisoning) - VMS ; Jan-Erik Söderholm wrote: > Jeffrey H. Coffield wrote: >> I contacted HP support for one of my customers and got the following >> response: >> >>> There are 2 part to DNS. >>> 1) Server >>> - The vulnerability only ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 72

Thread: Another BIND vulnerability (cache poisoning)

  1. Re: Another BIND vulnerability (cache poisoning)



    Jan-Erik Söderholm wrote:
    > Jeffrey H. Coffield wrote:
    >> I contacted HP support for one of my customers and got the following
    >> response:
    >>
    >>> There are 2 part to DNS.
    >>> 1) Server
    >>> - The vulnerability only affects the servers and may render it
    >>> "compromised", and there is a fix for this.
    >>>
    >>> 2) Resolver/client
    >>> - The vulnerability will not affect the clients directly and there is
    >>> no fix for it.
    >>>
    >
    > I take it for granted that the above was regarding VMS, right ?
    >

    Yes

  2. Re: Another BIND vulnerability (cache poisoning)

    On Mon, 28 Jul 2008 08:12:34 -0700, wrote:

    > In article , "Tom Linden"
    > writes:
    >> On Mon, 28 Jul 2008 06:42:43 -0700, wrote:
    >>
    >>> No - unpatched internal DNS servers which are setup to do recursive
    >>> queries are
    >>> vulnerable to attack from compromised internal windows systems.
    >>
    >> How do you check if it is set up that way?
    >>
    >
    > Look in TCPIP$BIND.CONF
    >
    > If recursion is restricted to internal systems you will have something
    > like
    >
    > acl "internal" {
    > xxx.xxx.xxxx/24 ; 10/8 ;
    > };
    >
    > options {
    > directory "SYS$SPECIFIC:[TCPIP$BIND]";
    > allow-recursion { "internal"; };
    > max-cache-size 10M;
    > };
    >
    > If there is no allow-recursion option specified then recursion is allowed
    > from all hosts.
    >
    Don't have an acl statement, and only

    options {
    directory "TCPIP$BIND_COMMON:[TCPIP$BIND]";
    recursion yes;

    > see
    >
    > http://www.openvms.compaq.com/doc/83...nd9_access_tab
    >
    > and for the acl statement
    >
    > http://www.openvms.compaq.com/doc/83...#bind9_acl_sec
    >
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University
    >
    >> --
    >> PL/I for OpenVMS
    >> www.kednos.com



    --
    PL/I for OpenVMS
    www.kednos.com

  3. Re: Another BIND vulnerability (cache poisoning)

    On 28 Jul, 14:12, davi...@alpha1.mdx.ac.uk wrote:
    > In article , koeh...@eisner.nospam..encompasserve.org (Bob Koehler) writes:
    >
    > >In article <488a10c0$0$14356$c3e8...@news.astraweb.com>, JF Mezei writes:
    >
    > >> If VMS is not affected, then HP should post this info on the CERT web
    > >> site to indicate that VMS has been tested and while the public tests
    > >> show it as vulnerable, it is not vulnerable to actual "attacks".
    >
    > > * How does HP define whether VMS is affected, when HP doesn't own all
    > > * the BIND implementations being run on VMS? * The best HP can do is
    > > * tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS")
    > > * is affected.
    >
    > That is ALL that is being asked of them.
    >
    > > * What has Process got to say about theirs?
    >
    > They have already released patches for the vulnerability
    >
    > see
    >
    > http://www.multinet.process.com/scri...NAMED-050_A052
    >
    > released 16th July
    >
    > and for TCPWARE
    >
    > http://vms.process.com/scripts/eco/e...NAMED_V582P010
    >
    > released 18th July
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University


    Note those are for the current versions. Patches for earlier versions
    (e.g. TCPWARE V5.7-2) will be along sometime.

  4. Re: Another BIND vulnerability (cache poisoning)

    On 28 Jul, 14:12, Jan-Erik Söderholm
    wrote:
    > IanMiller wrote:
    > > On Jul 25, 9:37 pm, Jan-Erik Söderholm
    > > wrote:
    >
    > >> I'm failing to see how this is a major problem for
    > >> my VMS systems, at least...
    >
    > >> Jan-Erik.
    >
    > > As far as I can see you only have a problem if you have BIND resolver
    > > that does recursive searches *using DNS servers you don't control.
    > > So if you use local host file then not a problem. If you use internal
    > > corporate DNS servers only then not a problem either.
    > > I suspect few VMS systems are vulnerable in practice.
    >
    > OK, as I thought.
    >
    > So probably the only affected VMS systems are a few hobbyist
    > systems with direct Internet connections here and there.
    > Hardly something to care *that* much about.
    >
    > And I'd guess that the only case when a VMS systems has to
    > resolve a lot of external domains, is if you use your
    > VMS systems for "surfing", and I can't realy see why
    > you'd want to do that. There are much better and cheaper
    > "surf-platforms" available...
    >
    > So, again, where *is* the problem ?? Besides of the
    > possible perception that HP don't care, of course...
    >
    > Jan-Erik.
    >
    > > As usual, the problem is perception not reality. HP have not yet
    > > produced a patch therefore they don't care rather than actually
    > > looking at how many VMS systems that you manage have problem and doing
    > > something about it (if necessary).



    The reaction here is as expected. The usual arguments rehashed. :-(
    I expect those few people that have had a potential problem on their
    VMS systems have done something about it - changed configuration or
    contacted the vendor of their TCPIP product.

  5. Re: Another BIND vulnerability (cache poisoning)

    In article <488e0fbb$0$1845$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >david20@alpha1.mdx.ac.uk wrote:
    >> Look in TCPIP$BIND.CONF
    >>
    >> If recursion is restricted to internal systems you will have something like
    >>
    >> acl "internal" {
    >> xxx.xxx.xxxx/24 ; 10/8 ;
    >> };
    >>
    >> options {
    >> directory "SYS$SPECIFIC:[TCPIP$BIND]";
    >> allow-recursion { "internal"; };
    >> max-cache-size 10M;
    >> };
    >>
    >> If there is no allow-recursion option specified then recursion is allowed
    >> from all hosts.
    >
    >
    >Pardon my ignorance, but this latest issue happens when a local client
    >tries to resolve a list of foreign hosts and uses his designated DNS
    >server to do this. So the requests come from the internal lan and are
    >thus validated in the above rule, aren't they ?

    Yes the above just shows the the DNS being set up so that only internal hosts
    can send requests for recursive replies. This is a fairly common setup since
    providing recursion for external hosts has long been frowned upon.

    (
    note. If you turn off recursion totally then the DNS server will then send
    back a referral to your client which will then have to contact a more
    authorative server itself. This would mean that your DNS server would do no
    caching but would also slow down DNS lookups. It would also mean that your
    internal DNS clients would need to have the ability to make direct calls to
    external DNS servers over udp 53 (and possibly tcp 53 depending upon the
    client) through your firewall.
    )

    The issue is the DNS cache being poisoned by someone managing to get a record
    for say google.com into your DNS' cache pointing at their site.
    To do this they send requests for domain1.google.com, domain2.google.com ...
    to your DNS and at the same time forge lots of responses which contain as
    additional information that the DNS server should goto google.com
    (with their address) for an authorative answer. The address they provide for
    google.com is then cached by your server. Without the patch getting this to
    work ie getting the false google record cached is a low probability event but
    is feasible in a reasonable amount of time by just keeping repeating this
    attack. With the patch the amount of time required becomes pretty much
    totally infeasible.
    This can all theoretically be carried out from an owned internal system
    ie virus infected system, system which has downloaded something from the
    web etc etc



    David Webb
    Security team leader
    CCSS
    Middlesex University

  6. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Mon, 28 Jul 2008 08:12:34 -0700, wrote:
    >
    >> In article , "Tom Linden"
    >> writes:
    >>> On Mon, 28 Jul 2008 06:42:43 -0700, wrote:
    >>>
    >>>> No - unpatched internal DNS servers which are setup to do recursive
    >>>> queries are
    >>>> vulnerable to attack from compromised internal windows systems.
    >>>
    >>> How do you check if it is set up that way?
    >>>
    >>
    >> Look in TCPIP$BIND.CONF
    >>
    >> If recursion is restricted to internal systems you will have something
    >> like
    >>
    >> acl "internal" {
    >> xxx.xxx.xxxx/24 ; 10/8 ;
    >> };
    >>
    >> options {
    >> directory "SYS$SPECIFIC:[TCPIP$BIND]";
    >> allow-recursion { "internal"; };
    >> max-cache-size 10M;
    >> };
    >>
    >> If there is no allow-recursion option specified then recursion is allowed
    >> from all hosts.
    >>
    >Don't have an acl statement, and only
    >
    >options {
    > directory "TCPIP$BIND_COMMON:[TCPIP$BIND]";
    > recursion yes;
    >


    In that case it looks like anyone, internal or external, who can send a
    DNS query on udp or tcp 53 to your server can send a recursive query.
    (Of course you may have firewalls in place protecting the DNS server from
    external access).

    David Webb
    Security team leader
    CCSS
    Middlesex University






    >> see
    >>
    >> http://www.openvms.compaq.com/doc/83...nd9_access_tab
    >>
    >> and for the acl statement
    >>
    >> http://www.openvms.compaq.com/doc/83...#bind9_acl_sec
    >>
    >>
    >> David Webb
    >> Security team leader
    >> CCSS
    >> Middlesex University
    >>
    >>> --
    >>> PL/I for OpenVMS
    >>> www.kednos.com
    >
    >
    >
    >--
    >PL/I for OpenVMS
    >www.kednos.com

  7. Re: Another BIND vulnerability (cache poisoning)

    In article <090544ea-822b-4c3c-99f3-2325bc826c1a@c65g2000hsa.googlegroups.com>, IanMiller writes:
    >On 28 Jul, 14:12, davi...@alpha1.mdx.ac.uk wrote:
    >> In article , koeh...@eisner.nospam=
    >..encompasserve.org (Bob Koehler) writes:
    >>
    >> >In article <488a10c0$0$14356$c3e8...@news.astraweb.com>, JF Mezei
    >ei.spam...@vaxination.ca> writes:
    >>
    >> >> If VMS is not affected, then HP should post this info on the CERT web
    >> >> site to indicate that VMS has been tested and while the public tests
    >> >> show it as vulnerable, it is not vulnerable to actual "attacks".
    >>
    >> > =A0 How does HP define whether VMS is affected, when HP doesn't own all
    >> > =A0 the BIND implementations being run on VMS? =A0 The best HP can do i=
    >s
    >> > =A0 tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS"=
    >)
    >> > =A0 is affected.
    >>
    >> That is ALL that is being asked of them.
    >>
    >> > =A0 What has Process got to say about theirs?
    >>
    >> They have already released patches for the vulnerability
    >>
    >> see
    >>
    >> http://www.multinet.process.com/scri...NAMED-050_A052
    >>
    >> released 16th July
    >>
    >> and for TCPWARE
    >>
    >> http://vms.process.com/scripts/eco/e...NAMED_V582P010
    >>
    >> released 18th July
    >>
    >> David Webb
    >> Security team leader
    >> CCSS
    >> Middlesex University
    >
    >
    >Note those are for the current versions. Patches for earlier versions
    >(e.g. TCPWARE V5.7-2) will be along sometime.

    Though that is slightly less of an issue since the latest versions of
    TCPWARE and Multinet will run on versions of VMS back to VMS 5.5-2.
    Hence it is much more likely users will either already be running the latest
    version or will be able to upgrade without too much difficulty.
    With UCX it is more of an issue since recent versions have been much more tied
    to the OS version hence upgrading to the latest DEC TCPIP service version may
    also mean upgrading to a new OS version.

    David Webb
    Security team leader
    CCSS
    Middlesex University


  8. Re: Another BIND vulnerability (cache poisoning)

    Note that Apple is behind on this patch too:

    http://db.tidbits.com/article/9706


  9. Re: Another BIND vulnerability (cache poisoning)

    In article , "Richard Whalen" writes:
    > Note that Apple is behind on this patch too:
    >
    > http://db.tidbits.com/article/9706

    How many folks are using thier Macs as DNS servers? Suns are much
    more popular for that purpose, although I no longer know what is
    being used "around here".

  10. Re: Another BIND vulnerability (cache poisoning)

    On 29 Jul, 13:37, "Richard Whalen" wrote:
    > Note that Apple is behind on this patch too:
    >
    > http://db.tidbits.com/article/9706


    and are the apple mac newsgroups filled with people shouting that this
    is the end of the mac? I guess not.

  11. Re: Another BIND vulnerability (cache poisoning)

    On Tue, 29 Jul 2008 04:04:03 -0700, wrote:

    > In article , "Tom Linden"
    > writes:
    >> On Mon, 28 Jul 2008 08:12:34 -0700, wrote:
    >>
    >>> In article , "Tom
    >>> Linden"
    >>> writes:
    >>>> On Mon, 28 Jul 2008 06:42:43 -0700, wrote:
    >>>>
    >>>>> No - unpatched internal DNS servers which are setup to do recursive
    >>>>> queries are
    >>>>> vulnerable to attack from compromised internal windows systems.
    >>>>
    >>>> How do you check if it is set up that way?
    >>>>
    >>>
    >>> Look in TCPIP$BIND.CONF
    >>>
    >>> If recursion is restricted to internal systems you will have something
    >>> like
    >>>
    >>> acl "internal" {
    >>> xxx.xxx.xxxx/24 ; 10/8 ;
    >>> };
    >>>
    >>> options {
    >>> directory "SYS$SPECIFIC:[TCPIP$BIND]";
    >>> allow-recursion { "internal"; };
    >>> max-cache-size 10M;
    >>> };
    >>>
    >>> If there is no allow-recursion option specified then recursion is
    >>> allowed
    >>> from all hosts.
    >>>
    >> Don't have an acl statement, and only
    >>
    >> options {
    >> directory "TCPIP$BIND_COMMON:[TCPIP$BIND]";
    >> recursion yes;
    >>
    >
    >
    > In that case it looks like anyone, internal or external, who can send a
    > DNS query on udp or tcp 53 to your server can send a recursive query.
    > (Of course you may have firewalls in place protecting the DNS server from
    > external access).
    >

    So how should it be configured to obviate this flaw?

    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University
    >
    >
    >
    >
    >
    >
    >>> see
    >>>
    >>> http://www.openvms.compaq.com/doc/83...nd9_access_tab
    >>>
    >>> and for the acl statement
    >>>
    >>> http://www.openvms.compaq.com/doc/83...#bind9_acl_sec
    >>>
    >>>
    >>> David Webb
    >>> Security team leader
    >>> CCSS
    >>> Middlesex University
    >>>
    >>>> --
    >>>> PL/I for OpenVMS
    >>>> www.kednos.com
    >>
    >>
    >>
    >> --
    >> PL/I for OpenVMS
    >> www.kednos.com



    --
    PL/I for OpenVMS
    www.kednos.com

  12. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Tue, 29 Jul 2008 04:04:03 -0700, wrote:
    >
    >> In article , "Tom Linden"
    >> writes:
    >>> On Mon, 28 Jul 2008 08:12:34 -0700, wrote:
    >>>
    >>>> In article , "Tom
    >>>> Linden"
    >>>> writes:
    >>>>> On Mon, 28 Jul 2008 06:42:43 -0700, wrote:
    >>>>>
    >>>>>> No - unpatched internal DNS servers which are setup to do recursive
    >>>>>> queries are
    >>>>>> vulnerable to attack from compromised internal windows systems.
    >>>>>
    >>>>> How do you check if it is set up that way?
    >>>>>
    >>>>
    >>>> Look in TCPIP$BIND.CONF
    >>>>
    >>>> If recursion is restricted to internal systems you will have something
    >>>> like
    >>>>
    >>>> acl "internal" {
    >>>> xxx.xxx.xxxx/24 ; 10/8 ;
    >>>> };
    >>>>
    >>>> options {
    >>>> directory "SYS$SPECIFIC:[TCPIP$BIND]";
    >>>> allow-recursion { "internal"; };
    >>>> max-cache-size 10M;
    >>>> };
    >>>>
    >>>> If there is no allow-recursion option specified then recursion is
    >>>> allowed
    >>>> from all hosts.
    >>>>
    >>> Don't have an acl statement, and only
    >>>
    >>> options {
    >>> directory "TCPIP$BIND_COMMON:[TCPIP$BIND]";
    >>> recursion yes;
    >>>
    >>
    >>
    >> In that case it looks like anyone, internal or external, who can send a
    >> DNS query on udp or tcp 53 to your server can send a recursive query.
    >> (Of course you may have firewalls in place protecting the DNS server from
    >> external access).
    >>
    >
    >So how should it be configured to obviate this flaw?
    >

    Set it up with an ACL to restrict recursion to your internal systems which will
    stop external attacks and then patch this vulnerability when a patch is
    released.

    David Webb
    Security team leader
    CCSS
    Middlesex University


    >> David Webb
    >> Security team leader
    >> CCSS
    >> Middlesex University
    >>
    >>
    >>
    >>
    >>
    >>
    >>>> see
    >>>>
    >>>> http://www.openvms.compaq.com/doc/83...nd9_access_tab
    >>>>
    >>>> and for the acl statement
    >>>>
    >>>> http://www.openvms.compaq.com/doc/83...#bind9_acl_sec
    >>>>
    >>>>
    >>>> David Webb
    >>>> Security team leader
    >>>> CCSS
    >>>> Middlesex University
    >>>>
    >>>>> --
    >>>>> PL/I for OpenVMS
    >>>>> www.kednos.com
    >>>
    >>>
    >>>
    >>> --
    >>> PL/I for OpenVMS
    >>> www.kednos.com
    >
    >
    >
    >--
    >PL/I for OpenVMS
    >www.kednos.com

  13. Re: Another BIND vulnerability (cache poisoning)

    On Jul 29, 8:30*am, IanMiller wrote:
    > On 29 Jul, 13:37, "Richard Whalen" wrote:
    >
    > > Note that Apple is behind on this patch too:
    >
    > >http://db.tidbits.com/article/9706
    >
    > and are the apple mac newsgroups filled with people shouting that this
    > is the end of the mac? I guess not.

    No, but there are a lot of very unhappy and heated posts about it; I
    imagine Apple is catching flak more directly too. We'll see how they
    respond (since they already missed the boat on a proactive one)
    compared to HP.

  14. Re: Another BIND vulnerability (cache poisoning)

    Richard Whalen wrote:
    > Note that Apple is behind on this patch too:
    >
    > http://db.tidbits.com/article/9706
    >


    This is bad for Apple that is trying to make it into offices. And it is
    made even worse because tidbits picked up on it and that will give
    OS-X/Apple a bad image.

    VMS is lucky in the sense that the media won't mention the fact that HP
    isn't publically releasing a patch or making any mention of VMS in this
    issue.

    BTW, Ricky Branson unveiled a new aircraft yesterday, the one that will
    get his space capsule high enough to be launched. Its name uses 2
    formerly copywrited terms in the VMS community:

    VMS eve !!!!!!

    (I lost a lot of respect for him when his ISP business in the UK
    publically announced that net neutrality was bull**** and that it woudl
    fight efforts to preserve net neutrality).

  15. Re: Another BIND vulnerability (cache poisoning)

    Hi Richard

    "Richard Whalen" wrote in message
    news:g6n2uh$25k$1@news.process.com...
    > Note that Apple is behind on this patch too:
    >
    > http://db.tidbits.com/article/9706
    >
    >

    Apparently it's because Steve Jobs is coding the changes himself, and is
    feeling (certainly looking) a bit off-colour at the moment.

    Should be along shortly; just after Java 6 :-)

    Cheers Richard Maher


  16. Re: Another BIND vulnerability (cache poisoning)

    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes in article dated 29 Jul 2008 07:59:57 -0500:
    >In article , "Richard Whalen" writes:
    >> Note that Apple is behind on this patch too:
    >>
    >> http://db.tidbits.com/article/9706
    >
    > How many folks are using thier Macs as DNS servers? Suns are much
    > more popular for that purpose, although I no longer know what is
    > being used "around here".

    Only a hobbyist would use a boutique OS like VMS or MACOS for a service as
    mundane as DNS in the first place. But this threat was enough to make me
    migrate to Linux. All it took was some minor editing of the .conf file;
    the .db files just worked.

    Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).

    --Spud Demon

  17. Re: Another BIND vulnerability (cache poisoning)

    On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
    wrote:

    > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes in article
    > dated 29 Jul 2008 07:59:57 -0500:
    >> In article , "Richard Whalen"
    >> writes:
    >>> Note that Apple is behind on this patch too:
    >>>
    >>> http://db.tidbits.com/article/9706
    >>
    >> How many folks are using thier Macs as DNS servers? Suns are much
    >> more popular for that purpose, although I no longer know what is
    >> being used "around here".
    >
    > Only a hobbyist would use a boutique OS like VMS or MACOS for a service
    > as
    > mundane as DNS in the first place. But this threat was enough to make me
    > migrate to Linux. All it took was some minor editing of the .conf file;
    > the .db files just worked.
    >
    > Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).

    What don't you like about WASD or MX?

    >
    > --Spud Demon



    --
    PL/I for OpenVMS
    www.kednos.com

  18. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
    > wrote:
    >
    >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes in article
    >> dated 29 Jul 2008 07:59:57 -0500:
    >>> In article , "Richard Whalen"
    >>> writes:
    >>>> Note that Apple is behind on this patch too:
    >>>>
    >>>> http://db.tidbits.com/article/9706
    >>>
    >>> How many folks are using thier Macs as DNS servers? Suns are much
    >>> more popular for that purpose, although I no longer know what is
    >>> being used "around here".
    >>
    >> Only a hobbyist would use a boutique OS like VMS or MACOS for a service
    >> as
    >> mundane as DNS in the first place. But this threat was enough to make me
    >> migrate to Linux. All it took was some minor editing of the .conf file;
    >> the .db files just worked.
    >>
    >> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).
    >
    >What don't you like about WASD or MX?
    >
    Or PMDF

    or even Communigate PRO


    David Webb
    Security team leader
    CCSS
    Middlesex

    >>
    >> --Spud Demon
    >
    >
    >
    >--
    >PL/I for OpenVMS
    >www.kednos.com

  19. Re: Another BIND vulnerability (cache poisoning)

    On Jul 29, 7:37*am, "Richard Whalen" wrote:
    > Note that Apple is behind on this patch too:
    >
    > http://db.tidbits.com/article/9706

    Apple has released a fix for OS-X 10.4 and 10.5

    http://support.apple.com/kb/HT2647

    So I guess now we're just waiting on HP for a fix or at least a
    statement.

  20. Re: Another BIND vulnerability (cache poisoning)

    In article , Rich Jordan writes:
    >On Jul 29, 7:37=A0am, "Richard Whalen" wrote:
    >> Note that Apple is behind on this patch too:
    >>
    >> http://db.tidbits.com/article/9706
    >
    >Apple has released a fix for OS-X 10.4 and 10.5
    >
    >http://support.apple.com/kb/HT2647
    >
    >So I guess now we're just waiting on HP for a fix or at least a
    >statement.

    It seems they do have a fix available but for some reason don't seem to be
    publicising that fact

    "
    As I mentioned before, we do have the updated images in hand -- just need to
    confirm that you need them and for which platform and version (Alpha or
    Integrity; V5.6, V5.5, or V5.4). I guess another option would be to go ahead
    and distribute a saveset containing images for all those versions; we have
    such a saveset built also.
    I am pleased to hear that you are using the BIND server on OpenVMS, and I
    wish more customers would choose such a configuration.
    "

    Maybe VMS engineering should for security patches think of following the HP-UX
    teams lead by notifying comp.os.vms. They regularly publish security patch
    notifications to

    comp.sys.hp.hpux,
    comp.security.unix
    and
    comp.security.misc


    David Webb
    Security team leader
    CCSS
    Middlesex University
« TCPware ECO kit available: NAMED_V572P012 | Disk remains in HostUnavailable for a very long time »