Re: bind-9.11.0-P2 on Debian 9.0 (stretch)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 Finchwrote: 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)
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 Finchwrote: > > 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)
Wolfgang Riedelwrote: > > 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
bind-9.11.0-P2 on Debian 9.0 (stretch)
Hi Folks,Just wonder if someone had success compiling bind-9.11.0-P2 on Debian 9.0 (stretch)?1) OpenSSL dependency danceI removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from sourceopenssl versionOpenSSL 1.0.2e 3 Dec 20152) configure./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc/bind --localstatedir=/var --enable-threads --enable-largefile --with-libtool --enable-shared --enable-static --with-openssl=/usr --with-gnu-ld --with-dlz-postgres=no --with-dlz-mysql=no --with-dlz-bdb=yes --with-dlz-filesystem=yes --with-dlz-stub=yes CFLAGS=-fno-strict-aliasing --enable-rrl --enable-newstats --enable-rrl===Configuration summary:---Optional features enabled: Multiprocessing support (--enable-threads) GOST algorithm support (encoding: raw) (--with-gost) ECDSA algorithm support (--with-ecdsa) Print backtrace on crash (--enable-backtrace) Use symbol table for backtrace, named only (--enable-symtable) Use GNU libtool (--with-libtool) Dynamically loadable zone (DLZ) drivers: Berkeley DB (--with-dlz-bdb) Filesystem (--with-dlz-filesystem) Stub (--with-dlz-stub)Features disabled or unavailable on this platform: Large-system tuning (--with-tuning) Allow 'dnstap' packet logging (--enable-dnstap) GeoIP access control (--with-geoip) GSS-API (--with-gssapi) Allow 'fixed' rrset-order (--enable-fixed-rrset) PKCS#11/Cryptoki support (--with-pkcs11) Native PKCS#11/Cryptoki support (--enable-native-pkcs11) Use libseccomp system call filtering (--enable-seccomp) Very verbose query trace logging (--enable-querytrace) Automated Testing Framework (--with-atf) Python tools (--with-python) XML statistics (--with-libxml2) JSON statistics (--with-libjson) HTTP zlib compression (--with-zlib) LMDB database to store configuration for 'addzone' zones (--with-lmdb)Unrecognized options: --enable-rrl, --enable-newstats, --enable-rrl---For more detail, use --enable-full-report.===3. make:/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/usr/bin/ld: final link failed: Bad valuecollect2: error: ld returned 1 exit statusMakefile:519: recipe for target 'libisc.la' failedmake[2]: *** [libisc.la] Error 1make[2]: Leaving directory '/opt/f1/isc-bind/bind-9.11.0-P2/lib/isc'Makefile:78: recipe for target 'subdirs' failedmake[1]: *** [subdirs] Error 1make[1]: Leaving directory '/opt/f1/isc-bind/bind-9.11.0-P2/lib'Makefile:83: recipe for target 'subdirs' failedmake: *** [subdirs] Error 1Any idea what I am missing?Thank you!--With best regards,Wolfgang RiedelWolfgang Riedel | Principal Engineer | CCIE#13804 | VCP #42559 make.log Description: Binary data 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.8.2 "no valid signature found"
Jim Garrison via bind-userswrote: > > Looking at the traffic with Wireshark, I see the RRSIG uses > ECDSA Curve P-256 with SHA-256. Should bind 9.8.2 be able to > recognize that algorithm or is a newer version of bind needed? The CHANGES file on the 9.8 branch says ECDSA support was added in 9.8.4. https://ftp.isc.org/isc/bind9/9.8.4b1/CHANGES Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Plymouth, Biscay: South or southeast 5 to 7, increasing gale 8 at times, decreasing 4 at times later. Moderate or rough, occasionally very rough. Rain at times. Moderate or good. ___ 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: Question on Bind validating resolver
Volker Janzenwrote: > > when my Bind resolver tries to get the A record for info.nominet.uk the > syslog gets lots of messages like this: > > Jan 25 21:15:52 box named[25097]: DNS format error from 173.245.58.93#53 > resolving info.nominet.uk/DS: invalid response OK, this is interesting. The domain is hosted by Cloudflare who have their own DNS implementation, and they try to make their responses as small as possible. In this case the response from the Cloudflare servers is quoted below. There is a fun feature in the NSEC record - they are using minimal covering NSEC records, hence the info\000.nominet.uk which is the DNS name lexically following info.nominet.uk - yes, that is a null byte! But this isn't relevant to the problem. The actual problem is to do with how BIND classifies negative responses according to RFC 2308 - see https://tools.ietf.org/html/rfc2308#page-6 Cloudflare are trying to generate a Type 3 response (the smallest, with no SOA or NS records in the authority section) - this isn't great because it means the negative answer cannot be cached :-( BIND detects a Type 3 response by looking for empty answer and authority sections - but in this case there is a DNSSEC proof of nonexistence in the authority section! So BIND's response classification fails. I'm inclined to blame Cloudflare for omitting the SOA record from the response, which breaks negative caching, as well as making BIND think Cloudflare's DNS server is insane. In fact Cloudflare do return SOA records with other kinds of negative response, so I guess it is just a bug/omission in their DS negative response handling. For those who like code, the Type 3 classification happens here https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/resolver.c;hb=HEAD#l6444 and eventually BIND ends up generating the SERVFAIL error here https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/resolver.c;hb=HEAD#l6696 ; <<>> DiG 9.12.0-dev <<>> +multiline +dnssec +norec @173.245.58.93 info.nominet.uk DS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59655 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;info.nominet.uk. IN DS ;; AUTHORITY SECTION: info.nominet.uk.3600 IN NSEC info\000.nominet.uk. NS RRSIG NSEC info.nominet.uk.3600 IN RRSIG NSEC 13 3 3600 ( 20170127110035 20170125090035 35273 nominet.uk. oRPIbo4LJvBa+JKROY9ZRuKP8EzFCHbhLBD84rQRUriu he0MBbZdzkYWLdkHgP7v1aENGYNSASsTwMUgztFoXw== ) ;; Query time: 3 msec ;; SERVER: 173.245.58.93#53(173.245.58.93) ;; WHEN: Thu Jan 26 10:00:47 GMT 2017 ;; MSG SIZE rcvd: 188 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon, Rockall, Malin, Hebrides, Bailey: Southerly or southeasterly, becoming cyclonic, 7 to severe gale 9, occasionally storm 10 at first in Rockall and Bailey, becoming variable 4 for a time in west Shannon, west Rockall and west Bailey. Very rough or high, occasionally rough except in Bailey. Rain or squally showers. Good, occasionally 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
allow-notify in catalog zones?
BIND 9.11 introduces catalog zones to simplify the management of slave servers. The documentation just mentions support for the "masters" (also with key), "allow-query" and "allow-transfer" options within the contents of a catalog zone. Can the "allow-notify" option be used, too, as an APL RR or does the "masters" option implicitly allow for notifications from the corresponding master (e.g. in cases where this master does not occur in the NS RRs of that zone)? Generally speaking: are catalog zones already fully equivalent to the configuration possibilities by editing a file or executing rndc commands? Thank you, Wolfgang Gehrke -- netplace Telematic GmbH ___ 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