Re: [External] Re: Request assistance configuring RPZ
On 5/29/19 3:15 PM, Jon wrote: Hi Grant, Hi, I don't usually wade in on these but I also believe RPZ would be the simplest way to achieve this. I tend to agree. DNSSEC can complicate this a bit (requiring additional settings). In order to keep the same zone working with 10. Addressing for all other (not in bubble) clients, create CNAME records in your master internal.local zone for these two records you want to have a 192. Address for. On the same master, create a new zone where you will have the A record your CNAME will resolve to, a 10. Address. This will take care of all clients not in the bubble. I don't think that David has any influence on the "internal.local" zone on buzz and woody. As such, CNAMEing to alternate zones is not likely to happen. On zurg, with your RPZ, have that configured for the same domain as the new domain you've created on the master. Why use CNAMEs to a separate zone on woody & buzz but not use the same separate zones on zurg? I'd think that you'd use separate zones everywhere (woody, buzz, and zurg) or nowhere. Yes, RPZ can make it trivial to override the names in the bubble. This should mean that, all queries are forwarded to your other boxes, except anything for that domain in the RPZ. The initial query for Andy or sid will be forwarded to the forwarding servers but will return a CNAME for the zurg recursor. Zurg should then go to resolve the cname but check its RPZ first, responding with the 192.x addressing you've got in the RPZ for each of the two hosts. I'm not tracking what you're saying. (If we want to delve further into this, seeing as how David can't change the zone on woody or buzz.) Please outline what zones you would have on what server as well as where the CNAMEs would be and what they would refer to. It's not tidy, I'll give you that but, this is an interesting scenario for more than just this DNS, you're bridging 2 networks with multiple multi-homed machines. This is not recommended from a security perspective and should use a gateway/FW to perform this work, routing between the networks. I largely agree. However there is no reason that there can't also be DNS separation in addition to routing / firewall. Thus this scenario can exist even with routing and firewalls. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: [External] Re: Request assistance configuring RPZ
Hi Grant, I don't usually wade in on these but I also believe RPZ would be the simplest way to achieve this. You're close I think. Using Carl's information and what you've done there, add the following. In order to keep the same zone working with 10. Addressing for all other (not in bubble) clients, create CNAME records in your master internal.local zone for these two records you want to have a 192. Address for. On the same master, create a new zone where you will have the A record your CNAME will resolve to, a 10. Address. This will take care of all clients not in the bubble. On zurg, with your RPZ, have that configured for the same domain as the new domain you've created on the master. This should mean that, all queries are forwarded to your other boxes, except anything for that domain in the RPZ. The initial query for Andy or sid will be forwarded to the forwarding servers but will return a CNAME for the zurg recursor. Zurg should then go to resolve the cname but check its RPZ first, responding with the 192.x addressing you've got in the RPZ for each of the two hosts. It's not tidy, I'll give you that but, this is an interesting scenario for more than just this DNS, you're bridging 2 networks with multiple multi-homed machines. This is not recommended from a security perspective and should use a gateway/FW to perform this work, routing between the networks. All the best. Jon On Thu, 30 May 2019, 02:14 Carl Byington via bind-users, < bind-users@lists.isc.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Wed, 2019-05-29 at 09:05 -0400, David Bank wrote: > > Re-reading the ARM, it seemed to me that I needed to add a > > After adding the zone and the response-policy statement to named.conf, I > presume you did: > > rndc reconfig > > To test that you can: > > dig rpz.internal.local axfr @zurg > > That should dump the rpz zone, and verify that zurg is serving it. The > response-policy should be in the global options. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlzuk4QACgkQL6j7milTFsEtgQCaA2gk7mvDO9jWYlAGTm+soYty > aEcAn1L7goSEfLdCIBIChF8wklA4MRFA > =q+pb > -END PGP 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 > ___ 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.14 configure error
On 29 May 2019, at 18:28, greg.ra...@bt.com wrote: Having trouble running 'configure' script for BIND 9.14.2 on CentOS 7 system. I have python 2.7.5 installed, but not the PLY package. The configure script complains: configure: error: Python >= 2.7 or >= 3.2 and the PLY package are required for dnssec-keymgr and other Python-based tools. PLY may be available from your OS package manager as python-ply or python3-ply; it can also be installed via pip. To build without Python/PLY, use --disable-python. However, running './configure -disable-python' results in the same error. Is this a known issue? Regards, Greg Rabil ___ 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 It is a known issue, and one that has been fixed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964 The correct option is --without-python -- Stacey ___ 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.14 configure error
Having trouble running 'configure' script for BIND 9.14.2 on CentOS 7 system. I have python 2.7.5 installed, but not the PLY package. The configure script complains: configure: error: Python >= 2.7 or >= 3.2 and the PLY package are required for dnssec-keymgr and other Python-based tools. PLY may be available from your OS package manager as python-ply or python3-ply; it can also be installed via pip. To build without Python/PLY, use --disable-python. However, running './configure -disable-python' results in the same error. Is this a known issue? Regards, Greg Rabil ___ 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: A little baffled by bind 9.14.2 wanting some special python?
On Wed, May 29, 2019 at 11:09:45AM -0400, Dennis Clarke wrote: > On 5/29/19 2:22 AM, Michał Kępień wrote: > > > For reasons unknown the configure process blows up even if I specify > > > the option --disable-python and in the config.log I see : > > > > The option is actually called --without-python; the fix for that mistake > > is already committed: > > > > https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964 > > > > Apologies about the confusion. > > > > Thanks but won't matter much anyways. Time to shutdown all the Solaris > systems and move to FreeBSD or similar. Sadly there is nothing that can > run on these Fujitsu sparc boxes I have. Nothing that I know of. From: https://www.isc.org/downloads/software-support-policy/ > BIND 9.11 is an Extended upport version, and will be supported until > December, 2021 which is more than 2 years from now. Unless you need a feature from 9.12 and above, 9.11 is still a good choice if you were able to build it on your Solaris platform. ISC maintains its older non-EOL BIND versions well (and 9.11 is likely more stable too from the years of public's usage it has got). +1 on deciding to move from Solaris to a BSD or Linux though. ;) Mukund ___ 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: A little baffled by bind 9.14.2 wanting some special python?
On 5/29/19 2:22 AM, Michał Kępień wrote: For reasons unknown the configure process blows up even if I specify the option --disable-python and in the config.log I see : The option is actually called --without-python; the fix for that mistake is already committed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964 Apologies about the confusion. Thanks but won't matter much anyways. Time to shutdown all the Solaris systems and move to FreeBSD or similar. Sadly there is nothing that can run on these Fujitsu sparc boxes I have. Nothing that I know of. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: [External] Re: Request assistance configuring RPZ
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2019-05-29 at 09:05 -0400, David Bank wrote: > Re-reading the ARM, it seemed to me that I needed to add a After adding the zone and the response-policy statement to named.conf, I presume you did: rndc reconfig To test that you can: dig rpz.internal.local axfr @zurg That should dump the rpz zone, and verify that zurg is serving it. The response-policy should be in the global options. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlzuk4QACgkQL6j7milTFsEtgQCaA2gk7mvDO9jWYlAGTm+soYty aEcAn1L7goSEfLdCIBIChF8wklA4MRFA =q+pb -END PGP 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: [External] Re: Request assistance configuring RPZ
On Tue, 28 May 2019, Carl Byington via bind-users wrote:
Hi, Carl - thanks for replying.
On zurg, add a new dns zone rpz.ncdot.gov
Your suggestion didn't work for me.
To test your suggestion, I had to add a "forwarders" statement to get
zurg to query buzz/woody; prior to testing, zurg had a zone file for
internal.local that told him he was the Master of the Zone, and the only
entries in it were for andy and sid. I commented that out for testing your
suggestion.
When I implemented your suggestion, queries to zurg for andy and sid
were resolved to their 10/8 addresses (meaning zurg forwarded the request
to buzz/woody and returned an answer without alteration). zurg seemed to
ignore the RPZ config.
Re-reading the ARM, it seemed to me that I needed to add a
zone "rpz.internal.local" { file "rpz.internal.local"; };
statement as well. When I did that, zurg still gave the 10/8 replies.
On zurg, all other names in internal.local will get the normal
processing, with answers via buzz. But when someone uses zurg to lookup
andy.internal.local, it will reply with 192.168.10.10 without even
asking buzz.
That IS what I'm trying to do. Unfortunately, the config you suggested
didn't get me there.
___
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: bug in ifiter_getifaddrs.c cannot find include file: ??
> Not sure where the need for ifaddrs.h came from but it doesn't exist in > ye old Solaris 10 sparc boxen : It comes from getifaddrs() being the only supported network interface enumeration mechanism supported in BIND 9.14+. Other such mechanisms were removed as part of code cleanups during the 9.13 development cycle: https://gitlab.isc.org/isc-projects/bind9/merge_requests/668 Thus, BIND 9.14+ will not compile on Solaris 10, as indicated in the PLATFORMS.md file. BIND 9.11 will. Both work on Solaris 11. -- Best regards, Michał Kępień ___ 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: bug in ifiter_getifaddrs.c cannot find include file: ??
Hi Dennis,
see PLATFORMS.md from the distribution. Unfortunately, Solaris 10 is just too
old
to be supported. You will either need to upgrade to Solaris 11 or use BIND
9.11 ESV
—cut here—
[…]
## Supported platforms
In general, this version of BIND will build and run on any POSIX-compliant
system with a C99-compliant C compiler, BSD-style sockets with RFC-compliant
IPv6 support, POSIX-compliant threads, and the OpenSSL cryptography library.
Atomic operations support from the compiler is needed, either in the form of
builtin operations, C11 atomics or the Interlocked family of functions on
Windows.
ISC regularly tests BIND on many operating systems and architectures, but
lacks the resources to test all of them. Consequently, ISC is only able to
offer support on a "best effort" basis for some.
[…]
## Unsupported platforms
These are platforms on which BIND 9.15 is known *not* to build or run:
* Platforms without at least OpenSSL 1.0.2
* Windows 10 / x86
* Windows Server 2012 and older
* Solaris 10 and older
* Platforms that don't support IPv6 Advanced Socket API (RFC 3542)
* Platforms that don't support atomic operations (via compiler or library)
* Linux without NPTL (Native POSIX Thread Library)
[…]
—cut here—
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 29 May 2019, at 07:34, Dennis Clarke wrote:
>
>
> Not sure where the need for ifaddrs.h came from but it doesn't exist in
> ye old Solaris 10 sparc boxen :
>
> /opt/developerstudio12.6/bin/cc
> -I/usr/local/build/bind-9.14.2_SunOS5.10_sparc64vii+.002 -I../../..
> -I./include -I./../pthreads/include -I../include -I./../include -I./..
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full
> -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl
> -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs
> -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none
> -D_POSIX_PTHREAD_SEMANTICS -mt -I/usr/local/include/libxml2
> -I/usr/local/include -I/usr/local/include -KPIC-c interfaceiter.c
> "ifiter_getifaddrs.c", line 21: cannot find include file:
> "ifiter_getifaddrs.c", line 81: warning: implicit function declaration:
> getifaddrs (E_NO_IMPLICIT_DECL_ALLOWED)
> "ifiter_getifaddrs.c", line 107: warning: implicit function declaration:
> freeifaddrs (E_NO_IMPLICIT_DECL_ALLOWED)
> "ifiter_getifaddrs.c", line 135: error: undefined struct/union member:
> ifa_name
> "ifiter_getifaddrs.c", line 137: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 137: error: operands have incompatible types:
> struct sockaddr {unsigned short sa_family, array[14] of char sa_data}
> "==" long
> "ifiter_getifaddrs.c", line 140: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 140: error: left operand of "->" must be pointer
> to struct/union
> "ifiter_getifaddrs.c", line 151: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 151: warning: improper pointer/integer
> combination: arg #1 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 156: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 156: warning: improper pointer/integer
> combination: arg #2 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 160: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 163: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 166: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 171: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 171: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 171: error: argument #3 is incompatible with
> prototype:
>prototype: pointer to struct sockaddr {unsigned short sa_family,
> array[14] of char sa_data} : "interfaceiter.c", line 59
>argument : struct sockaddr {unsigned short sa_family, array[14] of
> char sa_data}
> "ifiter_getifaddrs.c", line 171: warning: improper pointer/integer
> combination: arg #4 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 173: error: undefined struct/union member:
> ifa_netmask
> "ifiter_getifaddrs.c", line 174: error: improper member use: ifa_netmask
> "ifiter_getifaddrs.c", line 175: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 174: warning: improper pointer/integer
> combination: arg #3 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 175: warning: improper pointer/integer
> combination: arg #4 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 177: error: improper member use: ifa_ifu
> "ifiter_getifaddrs.c", line 177: error: operands have incompatible types:
> struct sockaddr {unsigned short sa_family, array[14] of char sa_data}
> "!=" long
> "ifiter_getifaddrs.c", line 179: error: improper member use: ifa_ifu
> "ifiter_getifaddrs.c", line 180: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 179:
Re: A little baffled by bind 9.14.2 wanting some special python?
> For reasons unknown the configure process blows up even if I specify > the option --disable-python and in the config.log I see : The option is actually called --without-python; the fix for that mistake is already committed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964 Apologies about the confusion. -- Best regards, Michał Kępień ___ 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
