Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-27 Thread Wolfgang Riedel 
Hi Fajar,

OK sounds familiar to me ;-)

OK let me try your proposal and install libssl1.0-dev and see if I can get 
bind-9.11.0-P2 to build.

Many thanks,
Wolfgang

> On 27 Jan 2017, at 14:40PM, Fajar A. Nugraha  wrote:
> 
> On Fri, Jan 27, 2017 at 7:20 PM, Wolfgang Riedel  > wrote:
> Just wonder if there is some agreed guidance on what steps I SHOULD take to 
> get bind-9.11.0-P2 successfully build on Debian 9.0?
> 
> 
> The generic recommendation on debian would probably be 'use whatever the 
> distro comes with, as they maintain security fixes for those as well'. 
> Debian's bind9 package uses native-pkcs11 with libsofthsm2.so, but I haven't 
> been able to get this to work with bind-9.11.0-P2.
> 
> If you 'just want to build bind-9.11.0-P2', debian stretch has libssl1.0-dev. 
> Install that, then bind's simple ./configure (plus --prefix=/opt/bind9, if 
> you want) should be able to pick it up correctly.
> 
> --
> Fajar



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-27 Thread Thomas Schulz 
> Just wonder if there is some agreed guidance on what steps I SHOULD take =
> to get bind-9.11.0-P2 successfully build on Debian 9.0?
> 
> 
> /usr/bin/ld: //lib64/libcrypto.a(a_object.o):
> relocation R_X86_64_PC32 against symbol `ASN1_OBJECT_free'
> can not be used when making a shared object; 
> recompile with -fPIC

It looks like openssl was not built to create shared libraries. So bind
built against your self compiled openssl can not create shared libraries.
Either rebuild openssl to create shared libraries or change binds configure
to remove --enable-shared, possibly adding --disable-shared.

Tom Schulz
Applied Dynamics Intl.
sch...@adi.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-27 Thread Fajar A. Nugraha 
On Fri, Jan 27, 2017 at 7:20 PM, Wolfgang Riedel  wrote:

> Just wonder if there is some agreed guidance on what steps I SHOULD take
> to get bind-9.11.0-P2 successfully build on Debian 9.0?
>
>
The generic recommendation on debian would probably be 'use whatever the
distro comes with, as they maintain security fixes for those as well'.
Debian's bind9 package uses native-pkcs11 with libsofthsm2.so, but I
haven't been able to get this to work with bind-9.11.0-P2.

If you 'just want to build bind-9.11.0-P2', debian stretch has
libssl1.0-dev. Install that, then bind's simple ./configure (plus
--prefix=/opt/bind9, if you want) should be able to pick it up correctly.

-- 
Fajar
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-27 Thread Wolfgang Riedel 
Hi Folks,

many thanks for the candidate feedback and the deep dive on what I should not 
have done ;-)
Not a big deal as it’s just a VM and I can easily start from scratch but I am 
burning a lot of time trying instead of learning.

Just wonder if there is some agreed guidance on what steps I SHOULD take to get 
bind-9.11.0-P2 successfully build on Debian 9.0?

Many thanks for your help!
Wolfgang




signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Reindl Harald 



Am 26.01.2017 um 19:50 schrieb Dennis Clarke:

On 01/26/2017 06:39 PM, Alan Clegg wrote:

On 1/26/17 1:31 PM, Dennis Clarke wrote:

The POSIX and XPG4 approach [is a great idea]


(My text in brackets)

Said no one, ever.


That wasn't the point however. The point is that the sources do
exist for very valid reasons and that a user can and should be able to
compile as they choose and to install as they choose.  Merely some sort
of logic in the separation is needed and the POSIX/XPG4 manner works in
a very stable way.  Go install a MySQL package from the Oracle download
and see where it goes.


and if they chose ./configure --prefix=/usr there is no seperation wich 
is the whole point - which was yours excatly?


yeah you can even choose to --prefix=/usr and you will be able, but in 
most cases others are asked a few weeks later how to cleanup the broken 
stuff

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Reindl Harald 



Am 26.01.2017 um 19:55 schrieb Dennis Clarke:

On 01/26/2017 06:48 PM, Reindl Harald wrote:

libraries got overwritten by the package manager


Impossible.

If the user built or the vendor supplied software follows the rules
of separation along with the RPATH and RUNPATH data inside the ELF
dynamic sections then what you say is impossible.  Clearly impossible.


but he used ./configure --prefix=/usr and that's all we where talking 
about until you came in - so the separation does *not* exist and so what 
i say is not only possible it will happen *for sure*


your bikeshedding *where* to sepearte it to not collide with the package 
manager is off-topic and pointless

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Alan Clegg 
On 1/26/17 1:50 PM, Dennis Clarke wrote:
> On 01/26/2017 06:39 PM, Alan Clegg wrote:
>> On 1/26/17 1:31 PM, Dennis Clarke wrote:
>>> The POSIX and XPG4 approach [is a great idea]
>>
>> (My text in brackets)
>>
>> Said no one, ever.
> 
>Clearly I just said it ... and have before ... as have others for
> about twenty years or at least since 1999.

http://www.informatica.co.cr/linux/research/1992/0302.htm

And I've been saying otherwise since 1992 (which I believe pre-dates ELF
and RUNPATH/RPATH).

But, enough flamage.  I blame Trump (and Oracle).



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Dennis Clarke 

On 01/26/2017 06:48 PM, Reindl Harald wrote:

librarie sgot overwritten by the package manager


Impossible.

If the user built or the vendor supplied software follows the rules
of separation along with the RPATH and RUNPATH data inside the ELF
dynamic sections then what you say is impossible.  Clearly impossible.


dc
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Dennis Clarke 

On 01/26/2017 06:39 PM, Alan Clegg wrote:

On 1/26/17 1:31 PM, Dennis Clarke wrote:

The POSIX and XPG4 approach [is a great idea]


(My text in brackets)

Said no one, ever.


   Clearly I just said it ... and have before ... as have others for
about twenty years or at least since 1999. Essentially any ELF file that
does not specify a RUNPATH and/or RPATH leaves the dependencies to be
found anywhere the runtime linker chooses. This is how a very bad mix
of user built software can end up messing up their lives. Full and
clear separation is best with full specification to the runtime linker
also.  That wasn't the point however. The point is that the sources do
exist for very valid reasons and that a user can and should be able to
compile as they choose and to install as they choose.  Merely some sort
of logic in the separation is needed and the POSIX/XPG4 manner works in
a very stable way.  Go install a MySQL package from the Oracle download
and see where it goes.

Dennis Clarke


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Reindl Harald 



Am 26.01.2017 um 19:31 schrieb Dennis Clarke:

1) OpenSSL dependency dance

I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source


You'll probably have better luck installing Debian's libssl1.0-dev and
related packages, rather than installing it yourself. Plain libssl-dev in
Stretch is OpenSSL 1.1.

If you install stuff yourself from source then it is particularly unwise
to put it in /usr where it'll collide with files managed by dpkg - put it
in /usr/local or /opt.


I have always been amused by the defacto approach of Linux people
who compile software and install it into /usr/local as a way to keep
non-vendor software outside of /usr.  Given that /usr/local is *inside*
the /usr tree of course


but it don't collide with the package manager which is the whole point 
and so dunno what you find amusing at all


http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html

/usr/local
The original idea behind '/usr/local' was to have a separate ('local') 
'/usr' directory on every machine besides '/usr', which might be just 
mounted read-only from somewhere else. It copies the structure of 
'/usr'. These days, '/usr/local' is widely regarded as a good place in 
which to keep self-compiled or third-party programs. The /usr/local 
hierarchy is for use by the system administrator when installing 
software locally. It needs to be safe from being overwritten when the 
system software is updated. It may be used for programs and data that 
are shareable amongst a group of hosts, but not found in /usr. Locally 
installed software must be placed within /usr/local rather than /usr 
unless it is being installed to replace or upgrade software in /usr.



 The POSIX and XPG4 approach has always been to provide some real
separation and install software in /opt/{vendor_name} with the config
files place under the /etc tree at /etc/opt/{vendor_name}


nothing different with /usr/local (it has the same hierarchy with bin, 
sbin, etc) and there are additional good reasons to use it because it 
has the same protections with ProtectSystem=true from get compromised 
(on modern systems /sbin and /bin are just symlinks to /usr/sbin and 
/usr/bin)


https://www.freedesktop.org/software/systemd/man/systemd.exec.html

ProtectSystem=
Takes a boolean argument or the special values "full" or "strict". If 
true, mounts the /usr and /boot directories read-only for processes 
invoked by this unit. If set to "full", the /etc directory is mounted 
read-only, too. If set to "strict" the entire file system hierarchy is 
mounted read-only, except for the API file system subtrees /dev, /proc 
and /sys



created ELF file binaries. However the folks in the Debian project and
many other Linux distro projects often release software to the world
wherein there is no RPATH or RUNPATH data in the ELF dynamic section
and thus the libs needed are left to the runtime linker to sort out. In
this case they could be from where ever the user decides and if they
very dangerously use LD_LIBRARY_PATH then an over ride may be enforced


https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

but that's completly offtopic, the whole reason why you never use /usr 
as prefix for your own builds is that at any time in the future 
something may introduce a new dependency and with random updates your 
self built stuff get overwritten and in case something just pulls 
libraries it will get *destroyed* because your unmanaged executable 
stuff is still present in the version you did "make install" but it's 
librarie sgot overwritten by the package manager which has no clue and 
needs not have a clue that somebody did overwrite randomly stuff where 
he ha no business to do so



The point of ALL of the above is that users of open software should
always have the freedom to build software on their own computers from
sources as they please and to install the results of their work as they
please.  However a bit of caution should be used in the placement of
the resultant executables and the libraries such that they do not
affect the runtime characteristics of their distro.  However the freedom
is there and the sources exist for very good reasons and if a user makes
the choice to dance in a minefield then by all means let them. However a
caution sign should be posted on the outer edge with some fine print
which says "you have the freedom to do so but here are some guidelines."


yes, you have the freedom to intall whatever you want where you want, 
but the problem

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Alan Clegg 
On 1/26/17 1:31 PM, Dennis Clarke wrote:
> The POSIX and XPG4 approach [is a great idea]

(My text in brackets)

Said no one, ever.

AlanC



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Dennis Clarke 





1) OpenSSL dependency dance

I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source


You'll probably have better luck installing Debian's libssl1.0-dev and
related packages, rather than installing it yourself. Plain libssl-dev in
Stretch is OpenSSL 1.1.

If you install stuff yourself from source then it is particularly unwise
to put it in /usr where it'll collide with files managed by dpkg - put it
in /usr/local or /opt.

Tony.



I have always been amused by the defacto approach of Linux people 
who compile software and install it into /usr/local as a way to keep 
non-vendor software outside of /usr.  Given that /usr/local is *inside*

the /usr tree of course.

The POSIX and XPG4 approach has always been to provide some real
separation and install software in /opt/{vendor_name} with the config
files place under the /etc tree at /etc/opt/{vendor_name}.  Various log
files are other bits may exist in /var/opt/{vendor_name} with temp files
which may or may not persist across boots in /var/tmp/{vendor_name}. 
Essentially full separation from the source OS area called /usr but in

fact even further one must be careful of the RPATH values inside the
created ELF file binaries. However the folks in the Debian project and
many other Linux distro projects often release software to the world
wherein there is no RPATH or RUNPATH data in the ELF dynamic section
and thus the libs needed are left to the runtime linker to sort out. In
this case they could be from where ever the user decides and if they
very dangerously use LD_LIBRARY_PATH then an over ride may be enforced:


sedna$ uname -a
Linux sedna 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 
GNU/Linux


sedna$ cat /etc/debian_version
9.0

sedna$ readelf -d /bin/dig

Dynamic section at offset 0x18560 contains 40 entries:
  TagType Name/Value
 0x0001 (NEEDED)  Shared library: [libdns.so.162]
 0x0001 (NEEDED)  Shared library: [libgssapi_krb5.so.2]
 0x0001 (NEEDED)  Shared library: [libkrb5.so.3]
 0x0001 (NEEDED)  Shared library: [libk5crypto.so.3]
 0x0001 (NEEDED)  Shared library: [libcom_err.so.2]
 0x0001 (NEEDED)  Shared library: [libcrypto.so.1.0.2]
 0x0001 (NEEDED)  Shared library: [liblwres.so.141]
 0x0001 (NEEDED)  Shared library: [libbind9.so.140]
 0x0001 (NEEDED)  Shared library: [libisccfg.so.140]
 0x0001 (NEEDED)  Shared library: [libisc.so.160]
 0x0001 (NEEDED)  Shared library: [libdl.so.2]
 0x0001 (NEEDED)  Shared library: [libcap.so.2]
 0x0001 (NEEDED)  Shared library: [libpthread.so.0]
 0x0001 (NEEDED)  Shared library: [libm.so.6]
 0x0001 (NEEDED)  Shared library: [libGeoIP.so.1]
 0x0001 (NEEDED)  Shared library: [libxml2.so.2]
 0x0001 (NEEDED)  Shared library: [libc.so.6]

That is the list of dynamic libs needed and more info :

 0x000c (INIT)   0x49b0
 0x000d (FINI)   0x124d4
 0x0019 (INIT_ARRAY) 0x218428
 0x001b (INIT_ARRAYSZ)   8 (bytes)
 0x001a (FINI_ARRAY) 0x218430
 0x001c (FINI_ARRAYSZ)   8 (bytes)
 0x6ef5 (GNU_HASH)   0x298
 0x0005 (STRTAB) 0x1ac0
 0x0006 (SYMTAB) 0x2d8
 0x000a (STRSZ)  4606 (bytes)
 0x000b (SYMENT) 24 (bytes)
 0x0015 (DEBUG)  0x0
 0x0003 (PLTGOT) 0x218820
 0x0007 (RELA)   0x2f10
 0x0008 (RELASZ) 6816 (bytes)
 0x0009 (RELAENT)24 (bytes)
 0x0018 (BIND_NOW)
 0x6ffb (FLAGS_1)Flags: NOW PIE
 0x6ffe (VERNEED)0x2ec0
 0x6fff (VERNEEDNUM) 2
 0x6ff0 (VERSYM) 0x2cbe
 0x6ff9 (RELACOUNT)  38
 0x (NULL)   0x0
sedna$


However no where is there an RPATH or RUNPATH or any way to tell
the run time linker where the correct libs *should* reside. Thus
on SVR4 compliant systems one *should* ( not must ) specify such
a path thus :

dclarke@thor_$ file /usr/local/bin/dig
/usr/local/bin/dig: ELF 64-bit MSB executable SPARCV9 Version 1, 
UltraSPARC1 Extensions Required, dynamically linked, not stripped


dclarke@thor_$ elfdump -devl /usr/local/bin/dig

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
  ei_osabi:   ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
  e_machine:  EM_SPARCV9  e_version: EV_CURRENT
  e_type: ET_EXEC
  e_flags:[ EF_SPARCV9_TSO EF_SPARC_SUN_US1 ]
  e_entry:   0x10002e780  e_ehsize: 64  e_shstrndx:  28
  e_shoff:  0x8c9c40  e_shentsize:  64  e_shnum: 30

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Reindl Harald 


Am 26.01.2017 um 18:59 schrieb Dennis Clarke:



OpenSSL 1.1 is currently not supported because they made
backwards-incompatible API changes ...


Is this issue documented somewhere?


it was discussed multiple times here
https://www.google.com/search?q=bind+openssl+1.1

when you follow several discussions on the web you also see that it#s 
one thing to get a sofwtare compile against 1.1 but that don't mean it 
works really as expected without testing everything again


https://news.ycombinator.com/item?id=13284648
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Dennis Clarke 




OpenSSL 1.1 is currently not supported because they made

> backwards-incompatible API changes ...

Is this issue documented somewhere ?


Dennis Clarke



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Reindl Harald 



Am 26.01.2017 um 16:30 schrieb Wolfgang Riedel:

I agree and also didn’t like it but I had been told that OpenSSL 1.1 is currently 
not supported because they made backwards-incompatible API changes and this is the 
default on Debian stretch. That’s the reason why I compiled from source to get to 
1.0 < 1.1


but you should never use /usr for anything which don't end in a package
especially playing around with openssl will sooner ot later break your 
whole system and then named is your smallest problem


additionall your major mistake here was that you *first* tried something 
dangerous at your own while ask before would have leaded someone 
pointing you to https://packages.debian.org/stretch/libssl1.0-dev


for Fedora 26 (Rawhide) a similar compat-package exists


On 26 Jan 2017, at 16:22PM, Tony Finch  wrote:

Wolfgang Riedel  wrote:


Just wonder if someone had success compiling bind-9.11.0-P2 on Debian 9.0 
(stretch)?


I haven't tried it myself.


1) OpenSSL dependency dance

I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source


You'll probably have better luck installing Debian's libssl1.0-dev and
related packages, rather than installing it yourself. Plain libssl-dev in
Stretch is OpenSSL 1.1.

If you install stuff yourself from source then it is particularly unwise
to put it in /usr where it'll collide with files managed by dpkg - put it
in /usr/local or /opt.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Wolfgang Riedel 
Hi Tony,

I agree and also didn’t like it but I had been told that OpenSSL 1.1 is 
currently not supported because they made backwards-incompatible API changes 
and this is the default on Debian stretch. That’s the reason why I compiled 
from source to get to 1.0 < 1.1

Wolfgang

> On 26 Jan 2017, at 16:22PM, Tony Finch  wrote:
> 
> Wolfgang Riedel  wrote:
>> 
>> Just wonder if someone had success compiling bind-9.11.0-P2 on Debian 9.0 
>> (stretch)?
> 
> I haven't tried it myself.
> 
>> 1) OpenSSL dependency dance
>> 
>> I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source
> 
> You'll probably have better luck installing Debian's libssl1.0-dev and
> related packages, rather than installing it yourself. Plain libssl-dev in
> Stretch is OpenSSL 1.1.
> 
> If you install stuff yourself from source then it is particularly unwise
> to put it in /usr where it'll collide with files managed by dpkg - put it
> in /usr/local or /opt.
> 
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Faeroes, East Southeast Iceland: Southerly 6 to gale 8, occasionally severe
> gale 9. Very rough or high. Rain. Moderate or poor.



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

2017-01-26 Thread Tony Finch 
Wolfgang Riedel  wrote:
>
> Just wonder if someone had success compiling bind-9.11.0-P2 on Debian 9.0 
> (stretch)?

I haven't tried it myself.

> 1) OpenSSL dependency dance
>
> I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source

You'll probably have better luck installing Debian's libssl1.0-dev and
related packages, rather than installing it yourself. Plain libssl-dev in
Stretch is OpenSSL 1.1.

If you install stuff yourself from source then it is particularly unwise
to put it in /usr where it'll collide with files managed by dpkg - put it
in /usr/local or /opt.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Faeroes, East Southeast Iceland: Southerly 6 to gale 8, occasionally severe
gale 9. Very rough or high. Rain. Moderate or poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users