Re: views-based RPZ
Hi Petr, great that you mention where to look into the code, I'm not familiar with it yet. This is certainly what I'm looking for, the search algorithm for a client IP to find its view. The lab test depends on an investment in a Supernic (and the appropriate chassis/Motherboard/PCI architecture for it) , thus I prefer to look into the code first and see if it deserves hardware-based acceleration. @Greg we have a bunch of rpz resolvers for ISPs ranging from 4 to 15MQueries/5 min. But bigger ISPs with 10 fold more traffic have manifested the rpz policies should be as flexible as possible for individual corporate customers. Nowadays loading zones with millions of rpz domains with ixfr takes a long time on platinum-xeon on a single view where bind 9.18* is not very responsive. Yes this deserves a single lab test for e.g. 2 or 3 views and see if loading time varies. Thank you all for your insights, Carlos On 26/08/2024 10:20, Petr Špaček wrote: On 25. 08. 24 9:20, Greg Choules via bind-users wrote: Regarding view selection, I don't know exactly how the code works or how efficient it is. But certainly I have seen some configs with a lot of views and they seem to function OK. Views are matched one by one, you can have a look at function get_matching_view() in file bin/named/server.c. Having said that, the matching can be fast enough or not depending on the configuration. Typically it's better to do a test in lab than theorize. Petr Špaček Internet Systems Consortium What sort of QPS are each of your servers handling? Cheers, Greg On Sun, 25 Aug 2024 at 05:27, Grant Taylor via bind-users mailto:bind-users@lists.isc.org>> wrote: On 8/24/24 07:37, Carlos Horowicz via bind-users wrote: > 2. if RPZ records are held in memory, why would an RPZ zone need to be > stored n times if there are n orthogonal views ? That is, why the more > views the more memory needed. Maybe you meant the qpcache, to store > different answers, though I don't understand how that works. I believe that some newer versions of BIND can share zone information across multiple views. Check out the "in-view" statement that goes in a zone {...} clause. Link - Chapter 7 BIND zone clause - https://www.zytrax.com/books/dns/ch7/zone.html#in-view <https://www.zytrax.com/books/dns/ch7/zone.html#in-view> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
On 25. 08. 24 9:20, Greg Choules via bind-users wrote: Regarding view selection, I don't know exactly how the code works or how efficient it is. But certainly I have seen some configs with a lot of views and they seem to function OK. Views are matched one by one, you can have a look at function get_matching_view() in file bin/named/server.c. Having said that, the matching can be fast enough or not depending on the configuration. Typically it's better to do a test in lab than theorize. Petr Špaček Internet Systems Consortium What sort of QPS are each of your servers handling? Cheers, Greg On Sun, 25 Aug 2024 at 05:27, Grant Taylor via bind-users mailto:bind-users@lists.isc.org>> wrote: On 8/24/24 07:37, Carlos Horowicz via bind-users wrote: > 2. if RPZ records are held in memory, why would an RPZ zone need to be > stored n times if there are n orthogonal views ? That is, why the more > views the more memory needed. Maybe you meant the qpcache, to store > different answers, though I don't understand how that works. I believe that some newer versions of BIND can share zone information across multiple views. Check out the "in-view" statement that goes in a zone {...} clause. Link - Chapter 7 BIND zone clause - https://www.zytrax.com/books/dns/ch7/zone.html#in-view <https://www.zytrax.com/books/dns/ch7/zone.html#in-view> -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
Hi Grant. That doesn't work for zones that then get used in a `response-policy` block. In this case you *must* define a zone §each time; so one (or up to 64) per view/instance of `response-policy`. Test it on your laptop/in a VM. What this does mean is that (if you are using views) you *could* have a different set of RPZ rules (different zone/zone contents) per view, perhaps because certain domains are fine for one set of clients but not fine for others. @Carlos to respond to your mail from yesterday: The 64 zone limit applies to the `response-policy` block (see above). Here's the reference for that: https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-response-policy Since there can be only one `r-p` globally (if you don't have user-defined views) or per view (if you do) it kinda amounts to the same thing, but I just wanted to clarify. Regarding view selection, I don't know exactly how the code works or how efficient it is. But certainly I have seen some configs with a lot of views and they seem to function OK. What sort of QPS are each of your servers handling? Cheers, Greg On Sun, 25 Aug 2024 at 05:27, Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 8/24/24 07:37, Carlos Horowicz via bind-users wrote: > > 2. if RPZ records are held in memory, why would an RPZ zone need to be > > stored n times if there are n orthogonal views ? That is, why the more > > views the more memory needed. Maybe you meant the qpcache, to store > > different answers, though I don't understand how that works. > > I believe that some newer versions of BIND can share zone information > across multiple views. Check out the "in-view" statement that goes in a > zone {...} clause. > > Link - Chapter 7 BIND zone clause > - https://www.zytrax.com/books/dns/ch7/zone.html#in-view > > > > -- > Grant. . . . > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
On 8/24/24 07:37, Carlos Horowicz via bind-users wrote: 2. if RPZ records are held in memory, why would an RPZ zone need to be stored n times if there are n orthogonal views ? That is, why the more views the more memory needed. Maybe you meant the qpcache, to store different answers, though I don't understand how that works. I believe that some newer versions of BIND can share zone information across multiple views. Check out the "in-view" statement that goes in a zone {...} clause. Link - Chapter 7 BIND zone clause - https://www.zytrax.com/books/dns/ch7/zone.html#in-view -- Grant. . . . smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
Hi there, On Sat, 24 Aug 2024, Carlos Horowicz wrote: ... ... is there an algorithm in bind9 or out there that quickly maps a client IP address to a CIDR, e.g. a something like a binary tree quicksearch ? or balanced red-black tree ? I don't know if this is going to help, but we use IP to CIDR lookups routinely in our spam filtering. MaxMind provides the raw data, which we use for this and several other purposes. There's a lot more in the raw data than just IP/CIDR relationships. We do some processing on the raw data from MaxMind to populate tables in the forms we want to have available. Lookups using Postgres from a database server which runs on _very_ modest hardware take of the order of milliseconds. I'll be happy to give more details of the setup (on or off list) if it would be useful. It isn't rocket science but I will be the first to admit that, although a hardware implementation could probably cost under a hundred dollars, it may sound rather like a sledgehammer to crack this particular nut. I wondered to myself if there might be any mileage in using something like Docker to provide per-client resolver instances instead of using multiple BIND views. I probably just need more sleep. -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
Hi Greg, thanks for your insights. Ok so the limit of 64 response policy zones applies to one view. I wonder, assuming the views are orthogonal (no overlapping of CIDRs, as in an ISP assigning CIDRs to local loops): 1. is there an algorithm in bind9 or out there that quickly maps a client IP address to a CIDR, e.g. a something like a binary tree quicksearch ? or balanced red-black tree ? top-down sequential processing sounds very inefficient. 2. if RPZ records are held in memory, why would an RPZ zone need to be stored n times if there are n orthogonal views ? That is, why the more views the more memory needed. Maybe you meant the qpcache, to store different answers, though I don't understand how that works. Best regards Carlos On 24/08/2024 08:36, Greg Choules wrote: Hi Carlos. If you have enough RAM it should be possible to create multiple views, each with a zone (primary or secondary, up to you) that contains the RPZ data for that view and a response-policy that uses that zone. The limit on number of zones is per response-policy block. But if you're using separate blocks inside each view, each r-p block referring to only one zone, then that limit is not relevant. Bear in mind that views are processed top down, so if you have a lot of them it can take a (relatively) long time to match clients to the ones at the bottom. Also, by default, each view has its own cache, hence the need for a lot of RAM. I would try it out on a lab server first. Hope that helps. Cheers, Greg On Fri, 23 Aug 2024 at 20:43, Carlos Horowicz via bind-users wrote: Hello List, an ISP has brought a case where several customers do not agree with our web interface portal that lets select different RPZ zones to be activated for a set of resolvers that are common to all customers. They even belong to different countries where some domains are banned. Given the case that I start treating provisioned CIDRs from customers as a base for views, does bind9.18.* support a huge number of views with different rpz zones activated per view ? I recall having read in the documentation about a limitation of 64 rpz zones in total, is this a number that can be configured, or even be set to "unlimited" ? Thanks in advance Carlos Horowicz Planisys -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: views-based RPZ
Hi Carlos. If you have enough RAM it should be possible to create multiple views, each with a zone (primary or secondary, up to you) that contains the RPZ data for that view and a response-policy that uses that zone. The limit on number of zones is per response-policy block. But if you're using separate blocks inside each view, each r-p block referring to only one zone, then that limit is not relevant. Bear in mind that views are processed top down, so if you have a lot of them it can take a (relatively) long time to match clients to the ones at the bottom. Also, by default, each view has its own cache, hence the need for a lot of RAM. I would try it out on a lab server first. Hope that helps. Cheers, Greg On Fri, 23 Aug 2024 at 20:43, Carlos Horowicz via bind-users < bind-users@lists.isc.org> wrote: > Hello List, > > an ISP has brought a case where several customers do not agree with our > web interface portal that lets select different RPZ zones to be activated > for a set of resolvers that are common to all customers. They even belong > to different countries where some domains are banned. > > Given the case that I start treating provisioned CIDRs from customers as a > base for views, does bind9.18.* support a huge number of views with > different rpz zones activated per view ? > > I recall having read in the documentation about a limitation of 64 rpz > zones in total, is this a number that can be configured, or even be set to > "unlimited" ? > > Thanks in advance > > Carlos Horowicz > Planisys > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
views-based RPZ
Hello List, an ISP has brought a case where several customers do not agree with our web interface portal that lets select different RPZ zones to be activated for a set of resolvers that are common to all customers. They even belong to different countries where some domains are banned. Given the case that I start treating provisioned CIDRs from customers as a base for views, does bind9.18.* support a huge number of views with different rpz zones activated per view ? I recall having read in the documentation about a limitation of 64 rpz zones in total, is this a number that can be configured, or even be set to "unlimited" ? Thanks in advance Carlos Horowicz Planisys -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
views-based RPZ
Hello List, an ISP has brought a case where several customers do not agree with our web interface portal that lets select different RPZ zones to be activated for a set of resolvers that are common to all customers. They even belong to different countries where some domains are banned. Given the case that I start treating provisioned CIDRs from customers as a base for views, does bind9.18.* support a huge number of views with different rpz zones activated per view ? I recall having read in the documentation about a limitation of 64 rpz zones in total, is this a number that can be configured, or even be set to "unlimited" ? Thanks in advance Carlos Horowicz Planisys -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reuse RPZ zones between views
On 12/6/24 21:46, Mark Andrews wrote: Have you read the fine documentation on BIND where it is stated this is not (currently) possible? If you want to extend named to support this we would be happy to review a change request. It is complicated however which is why it has not been done. Oh, a single line in page 257: "An in-view zone cannot be used as a response policy zone.". Acked. Ok. I have checked the source code in librpz.h and dnsrps.c. Quite scary... So, I have a question about what are the best practices to configure different RPZs for different clients without paying the overhead of loading multiple times the same RPZ. With 8 different RPZ, there are 256 combinations (views) and the memory overhead would be RPZx128! I wonder about librpz and dnsrps. The source is quite difficult and opaque, and I see no documentation anywhere beside a passing mention to "dnsrps-enable" and "dnsrps-options". Any hint? -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reuse RPZ zones between views
Have you read the fine documentation on BIND where it is stated this is not (currently) possible? If you want to extend named to support this we would be happy to review a change request. It is complicated however which is why it has not been done. -- Mark Andrews > On 13 Jun 2024, at 02:38, Jesus Cea wrote: > > My RPZ zones are quite big, and I would like to be able to reuse them in > several views sharing the memory instead of independent data structures. > > I thought that zone "in-view" would work, but it doesn't. > > I am doing something like: > > """ > view honeypot { >match-clients { honeypot; }; >allow-recursion { honeypot; }; > >zone "rpz" { > type slave; > [...]; >}; >response-policy { >zone "rpz" policy disabled; //cname prueba.xx.xx; > } break-dnssec yes; > }; > > view default { >match-clients { any; }; >allow-recursion { any; }; >zone "rpz" { in-view "honeypot"; }; >response-policy { > zone "rpz"; >} break-dnssec yes; > }; > """ > > Trying to activate that configuration produce an error: > > """ > response-policy zone 'rpz' for view default is not a primary or secondary zone > """ > > But "rpz" is secondary (slave) in "honeypot" > I would think this a bug in bind?. I am using version 9.18.25. > > Any suggestion beside loading the "rpz" zone separately in each view?. That > would explode my memory usage (I have quite a few views). > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Reuse RPZ zones between views
My RPZ zones are quite big, and I would like to be able to reuse them in several views sharing the memory instead of independent data structures. I thought that zone "in-view" would work, but it doesn't. I am doing something like: """ view honeypot { match-clients { honeypot; }; allow-recursion { honeypot; }; zone "rpz" { type slave; [...]; }; response-policy { zone "rpz" policy disabled; //cname prueba.xx.xx; } break-dnssec yes; }; view default { match-clients { any; }; allow-recursion { any; }; zone "rpz" { in-view "honeypot"; }; response-policy { zone "rpz"; } break-dnssec yes; }; """ Trying to activate that configuration produce an error: """ response-policy zone 'rpz' for view default is not a primary or secondary zone """ But "rpz" is secondary (slave) in "honeypot" I would think this a bug in bind?. I am using version 9.18.25. Any suggestion beside loading the "rpz" zone separately in each view?. That would explode my memory usage (I have quite a few views). -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind_dlz and views and samba
On 15. 05. 24 17:21, Peter Carlson wrote: As I understand it bind_dlz does not support multiple views, I have to following scenario and am trying to figure out how to configure it: * Internal (192.168.10.0/24) o resolve internal domain xyz.com o resolve internal samba domain xyz.lab o resolve single address xyz.3cx.us to 192.168.10.25 * External is resolved by a different server and xyz.3cx.us resolves to a public address * VPN (10.9.0.0/24) o resolve internal domain xyz.com o resolve internal samba domain xyz.lab o resolve single address xyz.3cx.us via normal public dns or alternatively resolve to external address I initially set this up with views: acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; }; acl vpn { 10.9.0.0/24; }; view trusted { match-clients { internals; }; zone "MYDOMAIN.com" IN { type master; file "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; }; zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us"; allow-update { none; }; }; }; view vpn { match-clients { vpn; }; zone "MYDOMAIN.com" IN { type master; file "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; }; }; But this crashes as soon as I add: dlz "AD DNS Zone" { database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_18.so"; }; So I split out DNS from ADDC, configured bind on DC to forward to another DNS and setup views there, but that doesnt work either as all requests now come from IP of the DC and so the ACLs wont match. Any ideas how I can accomplish this? The DLZ interface does support views and there is no reason why it should crash. This might be a bug in Samba DLZ module so I suggest to: 1. Write complete bug reports including all and exact version numbers 2. Add complete minimal configuration which demonstrates the issue 3. Take it to relevant Samba DLZ mailing list If there are bugs in BIND we will have a look. Good luck! -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind_dlz and views and samba
As I understand it bind_dlz does not support multiple views, I have to following scenario and am trying to figure out how to configure it: * Internal (192.168.10.0/24) o resolve internal domain xyz.com o resolve internal samba domain xyz.lab o resolve single address xyz.3cx.us to 192.168.10.25 * External is resolved by a different server and xyz.3cx.us resolves to a public address * VPN (10.9.0.0/24) o resolve internal domain xyz.com o resolve internal samba domain xyz.lab o resolve single address xyz.3cx.us via normal public dns or alternatively resolve to external address I initially set this up with views: acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; }; acl vpn { 10.9.0.0/24; }; view trusted { match-clients { internals; }; zone "MYDOMAIN.com" IN { type master; file "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; }; zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us"; allow-update { none; }; }; }; view vpn { match-clients { vpn; }; zone "MYDOMAIN.com" IN { type master; file "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; }; }; But this crashes as soon as I add: dlz "AD DNS Zone" { database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_18.so"; }; So I split out DNS from ADDC, configured bind on DC to forward to another DNS and setup views there, but that doesnt work either as all requests now come from IP of the DC and so the ACLs wont match. Any ideas how I can accomplish this? Peter -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to use different views on DNS-over-HTTPS vs normal DNS on port 53
Hello, How can I configure BIND9 to reply to requests from DNS-over-HTTPS with view A, and if the requests is from normal DNS on port 53, reply with view B? Example: client 192.168.1.5 requests A record test.example.com with DNS over HTTPS, BIND should reply with view A client 192.168.1.5 requests A record test.example.com with DNS on port 53, BIND should reply with view B -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Thanks all for the responses and guidance. This is just me doing some tweaky things with a few local bind servers with systems on multiple vlans trying to properly resolve traversing multiple subnets and thinking I could leverage views for something it wasn't meant for [but I think would be handy if it could]. I'll be adding the unique hostname entries into the appropriate bind server so that they replicate to the primary server to be accessible. To answer the question about search domains, I always try to do FQDN to single out what it is that I'm trying to get to. Again, thanks! On Thu, Jun 29, 2023 at 8:32 AM Greg Choules < gregchoules+bindus...@googlemail.com> wrote: > Hi. > Ah, I got the networks the wrong way round. > > Sorry, it wasn't until I saw Sten's response that it occurred to me that > not everyone knows how views work. Indeed a query will be tested against > each view, top down. If it satisfies the criteria for a view (either/both > match-clients and match-destinations) it stops there. If that view can't > answer, sorry. No further views are tested. This is why the 'any' view is > last, like a default route. > > Having system10/system-10, system20, system30 etc.. or some such naming > convention, all in "lab.domain.com" will certainly work. The goal is > uniqueness. How you achieve it is down to preference. > > I have an additional thought about primaries and secondaries. In my > experience, unless there are completely different teams who don't talk much > to each other running separate DNS servers, it is best to keep all your > primary zones in one place (or two for resilience). It makes it easier to > administer and to understand which way data is flowing. > > Cheers, Greg > > On Thu, 29 Jun 2023 at 16:14, Ubence Quevedo wrote: > >> Hi, >> >> Actually, that config was from the primary at 192.168.10.3. >> >> Below is the config from the lab DNS server at 10.32.1.6/192.168.10.183: >> include "/etc/bind/rndc.key"; >> include "/etc/bind/ddns-key.key"; >> >> zone "lab.domain.com" { >> type master; >> forwarders {}; >> file "/var/lib/bind/db.lab.domain.com"; >> update-policy { >> grant ddns-key wildcard *.lab.domain.com A DHCID; >> }; >> notify yes; >> allow-transfer { 192.168.10.3; }; >> }; >> >> zone "domain.com" { >> type secondary; >> masterfile-format text; >> file "/var/lib/bind/db.domain.com"; >> primaries { 192.168.10.3; }; >> }; >> >> zone "1.32.10.in-addr.arpa" { >> type master; >> forwarders {}; >> file "/var/lib/bind/db.1.32.10.in-addr.arpa"; >> update-policy { >> grant ddns-key wildcard *.domain.com A DHCID; >> }; >> }; >> >> zone "10.32.10.in-addr.arpa" { >> type master; >> forwarders {}; >> file "/var/lib/bind/db.10.32.10.in-addr.arpa"; >> update-policy { >> grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR; >> }; >> }; >> >> zone "20.32.10.in-addr.arpa" { >> type master; >> forwarders {}; >> file "/var/lib/bind/db.20.32.10.in-addr.arpa"; >> update-policy { >> grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR; >> }; >> }; >> >> zone "30.32.10.in-addr.arpa" { >> type master; >> forwarders {}; >> file "/var/lib/bind/db.30.32.10.in-addr.arpa"; >> update-policy { >> grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR; >> }; >> }; >> >> I now realize that views is *NOT* what I want to do since it's either one >> view or the other not an and type of thing. >> >> The reason I was trying to do just both domain.com and lab.domain.com is >> that I have let's encrypt certificates setup through both domain names. >> Doing the net2.domain.com, net3.domain.com, etc. I think would mean that >> I'd need certificates for each of those zones. >> >> However, I think if I just slightly change the hostname for the >> lab.domain.com like system10.lab.domain.com, system20.lab.domain.com, >> etc. and have those setup with different IP addresses, that *should* work. >> No ambiguity there since it's an entirely different hostname being resolved >> and still keep the lab.domain.com domain name. >> >> Ultimately, views won't work, which is very clear now, but having >> distinct hostnames for each instance on a different subnet *should* work >> and could
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi. Ah, I got the networks the wrong way round. Sorry, it wasn't until I saw Sten's response that it occurred to me that not everyone knows how views work. Indeed a query will be tested against each view, top down. If it satisfies the criteria for a view (either/both match-clients and match-destinations) it stops there. If that view can't answer, sorry. No further views are tested. This is why the 'any' view is last, like a default route. Having system10/system-10, system20, system30 etc.. or some such naming convention, all in "lab.domain.com" will certainly work. The goal is uniqueness. How you achieve it is down to preference. I have an additional thought about primaries and secondaries. In my experience, unless there are completely different teams who don't talk much to each other running separate DNS servers, it is best to keep all your primary zones in one place (or two for resilience). It makes it easier to administer and to understand which way data is flowing. Cheers, Greg On Thu, 29 Jun 2023 at 16:14, Ubence Quevedo wrote: > Hi, > > Actually, that config was from the primary at 192.168.10.3. > > Below is the config from the lab DNS server at 10.32.1.6/192.168.10.183: > include "/etc/bind/rndc.key"; > include "/etc/bind/ddns-key.key"; > > zone "lab.domain.com" { > type master; > forwarders {}; > file "/var/lib/bind/db.lab.domain.com"; > update-policy { > grant ddns-key wildcard *.lab.domain.com A DHCID; > }; > notify yes; > allow-transfer { 192.168.10.3; }; > }; > > zone "domain.com" { > type secondary; > masterfile-format text; > file "/var/lib/bind/db.domain.com"; > primaries { 192.168.10.3; }; > }; > > zone "1.32.10.in-addr.arpa" { > type master; > forwarders {}; > file "/var/lib/bind/db.1.32.10.in-addr.arpa"; > update-policy { > grant ddns-key wildcard *.domain.com A DHCID; > }; > }; > > zone "10.32.10.in-addr.arpa" { > type master; > forwarders {}; > file "/var/lib/bind/db.10.32.10.in-addr.arpa"; > update-policy { > grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR; > }; > }; > > zone "20.32.10.in-addr.arpa" { > type master; > forwarders {}; > file "/var/lib/bind/db.20.32.10.in-addr.arpa"; > update-policy { > grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR; > }; > }; > > zone "30.32.10.in-addr.arpa" { > type master; > forwarders {}; > file "/var/lib/bind/db.30.32.10.in-addr.arpa"; > update-policy { > grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR; > }; > }; > > I now realize that views is *NOT* what I want to do since it's either one > view or the other not an and type of thing. > > The reason I was trying to do just both domain.com and lab.domain.com is > that I have let's encrypt certificates setup through both domain names. > Doing the net2.domain.com, net3.domain.com, etc. I think would mean that > I'd need certificates for each of those zones. > > However, I think if I just slightly change the hostname for the > lab.domain.com like system10.lab.domain.com, system20.lab.domain.com, > etc. and have those setup with different IP addresses, that *should* work. > No ambiguity there since it's an entirely different hostname being resolved > and still keep the lab.domain.com domain name. > > Ultimately, views won't work, which is very clear now, but having distinct > hostnames for each instance on a different subnet *should* work and could > be put on the lab.domain.com system so that when they are replicated to > the primary name server they will resolve appropriately. > > Does that sound about right? > > On Thu, Jun 29, 2023 at 7:53 AM Greg Choules < > gregchoules+bindus...@googlemail.com> wrote: > >> Hi Ubence. >> That is starting to get complex! >> >> Firstly, yes BIND parses views top down, so order matters. >> Secondly, most specific domain wins (like more specific routes). >> >> I now see that you have created three levels of zones: >> domain.com >> lab.domain.com >> system.lab.domain.com >> >> This config looks like it's from the 10... primary, correct? Can you send >> the config from 192.168.10.183 as well please? >> What zones does it have and are there views on it too? >> >> Rather than speculate why adding that secondary zone has started the >> problems, dump the database - rndc dumpdb -all - and see what it contains. >> That should show you what the server thinks it should be doing. Also, check >> the
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
On 6/29/23 6:44 AM, Matus UHLAR - fantomas wrote: bind has "sortlist" statement that could do what you want. It will provide all IPs but sorted differently. +1 to "sortlist". I couldn't remember the exact nomenclature nor how it was used. Otherwise, you can set up multiple views with different versions of the same zone, configured to provide different verision according to source IP. This is much harder to set up. One thing that I was concerned with in Ubence's original message is I wasn't entirely clear if search domains were coming into play, and if so, what the possible domains were. This could also be a contributing complication. Grant. . . . -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi, Actually, that config was from the primary at 192.168.10.3. Below is the config from the lab DNS server at 10.32.1.6/192.168.10.183: include "/etc/bind/rndc.key"; include "/etc/bind/ddns-key.key"; zone "lab.domain.com" { type master; forwarders {}; file "/var/lib/bind/db.lab.domain.com"; update-policy { grant ddns-key wildcard *.lab.domain.com A DHCID; }; notify yes; allow-transfer { 192.168.10.3; }; }; zone "domain.com" { type secondary; masterfile-format text; file "/var/lib/bind/db.domain.com"; primaries { 192.168.10.3; }; }; zone "1.32.10.in-addr.arpa" { type master; forwarders {}; file "/var/lib/bind/db.1.32.10.in-addr.arpa"; update-policy { grant ddns-key wildcard *.domain.com A DHCID; }; }; zone "10.32.10.in-addr.arpa" { type master; forwarders {}; file "/var/lib/bind/db.10.32.10.in-addr.arpa"; update-policy { grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR; }; }; zone "20.32.10.in-addr.arpa" { type master; forwarders {}; file "/var/lib/bind/db.20.32.10.in-addr.arpa"; update-policy { grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR; }; }; zone "30.32.10.in-addr.arpa" { type master; forwarders {}; file "/var/lib/bind/db.30.32.10.in-addr.arpa"; update-policy { grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR; }; }; I now realize that views is *NOT* what I want to do since it's either one view or the other not an and type of thing. The reason I was trying to do just both domain.com and lab.domain.com is that I have let's encrypt certificates setup through both domain names. Doing the net2.domain.com, net3.domain.com, etc. I think would mean that I'd need certificates for each of those zones. However, I think if I just slightly change the hostname for the lab.domain.com like system10.lab.domain.com, system20.lab.domain.com, etc. and have those setup with different IP addresses, that *should* work. No ambiguity there since it's an entirely different hostname being resolved and still keep the lab.domain.com domain name. Ultimately, views won't work, which is very clear now, but having distinct hostnames for each instance on a different subnet *should* work and could be put on the lab.domain.com system so that when they are replicated to the primary name server they will resolve appropriately. Does that sound about right? On Thu, Jun 29, 2023 at 7:53 AM Greg Choules < gregchoules+bindus...@googlemail.com> wrote: > Hi Ubence. > That is starting to get complex! > > Firstly, yes BIND parses views top down, so order matters. > Secondly, most specific domain wins (like more specific routes). > > I now see that you have created three levels of zones: > domain.com > lab.domain.com > system.lab.domain.com > > This config looks like it's from the 10... primary, correct? Can you send > the config from 192.168.10.183 as well please? > What zones does it have and are there views on it too? > > Rather than speculate why adding that secondary zone has started the > problems, dump the database - rndc dumpdb -all - and see what it contains. > That should show you what the server thinks it should be doing. Also, check > the logs for what got transferred. > > I don't understand the purpose of both lab.domain.com and > system.lab.domain.com, unless the intention is to provide a general zone > for all things 'lab' and a set of more specific zones for just this system? > > > I stand by my opinion that I still wouldn't use views for this and that > the way to do it is to give every numbered interface on every machine its > own domain. > So if "system" has six addresses it has six FQDNs, each one in a different > zone. That alone may sound at first like it is complicating matters, but > consider this: each address exists for a reason and in a different network > (or you wouldn't need a different address), so a domain suffix can be > viewed as the domain for a given network and all interfaces of all devices > that sit in that network share a domain suffix. > > If "system" is the end host itself I wouldn't give it its own zone. It's > not illegal (and can actually be useful in some edge cases), just overly > complicated. If this were my network I'd do something like: > > zone "domain.com" { > type primary; > #contains delegations for net1, net2...net6 > > zone "net1.domain.com" { > # 192.168.10.0/24 > etc... > > zone "net2.domain.com" { > # 10.32.1.0/24 > etc... > > zone "net3.domain.com" { > # 10.32.10.0/24 > etc... > > zone "net4.domain.com" { > # 10.32.20.0/24 &g
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi Ubence. That is starting to get complex! Firstly, yes BIND parses views top down, so order matters. Secondly, most specific domain wins (like more specific routes). I now see that you have created three levels of zones: domain.com lab.domain.com system.lab.domain.com This config looks like it's from the 10... primary, correct? Can you send the config from 192.168.10.183 as well please? What zones does it have and are there views on it too? Rather than speculate why adding that secondary zone has started the problems, dump the database - rndc dumpdb -all - and see what it contains. That should show you what the server thinks it should be doing. Also, check the logs for what got transferred. I don't understand the purpose of both lab.domain.com and system.lab.domain.com, unless the intention is to provide a general zone for all things 'lab' and a set of more specific zones for just this system? I stand by my opinion that I still wouldn't use views for this and that the way to do it is to give every numbered interface on every machine its own domain. So if "system" has six addresses it has six FQDNs, each one in a different zone. That alone may sound at first like it is complicating matters, but consider this: each address exists for a reason and in a different network (or you wouldn't need a different address), so a domain suffix can be viewed as the domain for a given network and all interfaces of all devices that sit in that network share a domain suffix. If "system" is the end host itself I wouldn't give it its own zone. It's not illegal (and can actually be useful in some edge cases), just overly complicated. If this were my network I'd do something like: zone "domain.com" { type primary; #contains delegations for net1, net2...net6 zone "net1.domain.com" { # 192.168.10.0/24 etc... zone "net2.domain.com" { # 10.32.1.0/24 etc... zone "net3.domain.com" { # 10.32.10.0/24 etc... zone "net4.domain.com" { # 10.32.20.0/24 etc... zone "net5.domain.com" { # 10.32.30.0/24 etc... zone "net6.domain.com" { # ?.?.?.? etc... "system" has A records in all of these, with the relevant interface address for the network. Clients lookup the FQDN of interest to them at the time. This way there is guaranteed no ambiguity. Cheers, Greg On Thu, 29 Jun 2023 at 15:00, Ubence Quevedo wrote: > Hi Greg, > > Here's the most recent config that I tried that seemed to work, but > ultimately broke resolution for the main zone domain.com, even though I > set it to match-clients { any; }. > > What I didn't mention in my original post was that I have other subnets > configured for this remote host through vlans with different IP addresses. > That's why there are so many other views. I was hoping the match-clients > per each view would return the appropriate IP address per subnet making the > request. > > include "/etc/bind/rndc.key"; > include "/etc/bind/ddns-key.key"; > > view "192.168.10-net" { > match-clients { 192.168.10.0/24; }; > zone "system.lab.domain.com" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.192.168.10"; > }; > }; > > view "10.32.1-net" { > match-clients { 10.32.1.0/24; }; > zone "system.lab.domain.com" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.1"; > }; > }; > > view "10.32.10-net" { > match-clients { 10.32.10.0/24; }; > zone "system.lab.domain.com" { > type master; >file "/var/lib/bind/db.system.lab.domain.com.10.32.10"; > }; > }; > > view "10.32.20-net" { > match-clients { 10.32.20.0/24; }; > zone "system.lab.domain.com" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.20"; > }; > }; > > view "10.32.30-net" { > match-clients { 10.32.30.0/24; }; > zone "system.lab.domain.com" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.30"; > }; > }; > > view "main" { > match-clients { any; }; > zone "domain.com" { > type master; > forwarders {}; > file "/var/lib/bind/db.domain.com"; > update-policy { > grant ddns-key wildcard *.domain.com A DHCID; > }; > notify yes; > allow-transfer { 192.168.10.183; }; > }; > zone "lab.domain.com" { > type secondary; > masterfile-format text; > file "/var/lib/bind/db.lab.domain.com"; > primaries { 192.168.10.183; }; > }; > zone "10.168.192.in-addr.arpa&
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
> On 29 Jun 2023, at 15.59, Ubence Quevedo wrote: > > Hi Greg, > > Here's the most recent config that I tried that seemed to work, but > ultimately broke resolution for the main zone domain.com > <http://domain.com/>, even though I set it to match-clients { any; }. Please remember that ONLY ONE view is matched. Your main view is only used if none of the other views match. > > What I didn't mention in my original post was that I have other subnets > configured for this remote host through vlans with different IP addresses. > That's why there are so many other views. I was hoping the match-clients per > each view would return the appropriate IP address per subnet making the > request. > > include "/etc/bind/rndc.key"; > include "/etc/bind/ddns-key.key"; > > view "192.168.10-net" { > match-clients { 192.168.10.0/24 <http://192.168.10.0/24>; }; > zone "system.lab.domain.com <http://system.lab.domain.com/>" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.192.168.10"; > }; > }; > > view "10.32.1-net" { > match-clients { 10.32.1.0/24 <http://10.32.1.0/24>; }; > zone "system.lab.domain.com <http://system.lab.domain.com/>" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.1"; > }; > }; > > view "10.32.10-net" { > match-clients { 10.32.10.0/24 <http://10.32.10.0/24>; }; > zone "system.lab.domain.com <http://system.lab.domain.com/>" { > type master; >file "/var/lib/bind/db.system.lab.domain.com.10.32.10"; > }; > }; > > view "10.32.20-net" { > match-clients { 10.32.20.0/24 <http://10.32.20.0/24>; }; > zone "system.lab.domain.com <http://system.lab.domain.com/>" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.20"; > }; > }; > > view "10.32.30-net" { > match-clients { 10.32.30.0/24 <http://10.32.30.0/24>; }; > zone "system.lab.domain.com <http://system.lab.domain.com/>" { > type master; > file "/var/lib/bind/db.system.lab.domain.com.10.32.30"; > }; > }; > > view "main" { > match-clients { any; }; > zone "domain.com <http://domain.com/>" { > type master; > forwarders {}; > file "/var/lib/bind/db.domain.com <http://db.domain.com/>"; > update-policy { > grant ddns-key wildcard *.domain.com <http://domain.com/> A DHCID; > }; > notify yes; > allow-transfer { 192.168.10.183; }; > }; > zone "lab.domain.com <http://lab.domain.com/>" { > type secondary; > masterfile-format text; > file "/var/lib/bind/db.lab.domain.com <http://db.lab.domain.com/>"; > primaries { 192.168.10.183; }; > }; > zone "10.168.192.in-addr.arpa" { > type master; > forwarders {}; > file "/var/lib/bind/db.10.168.192.in-addr.arpa"; > update-policy { > grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR; > }; > }; > }; > > The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10: > $ORIGIN . > $TTL 604800 ; 1 week > system.lab.domain.com <http://system.lab.domain.com/> IN SOA > ns1.domain.com <http://ns1.domain.com/>. thatrat.gmail.com > <http://thatrat.gmail.com/>. ( > 2023062800 ; serial > 604800 ; refresh (1 week) > 86400 ; retry (1 day) > 2419200; expire (4 weeks) > 604800 ; minimum (1 week) > ) > NS ns1.domain.com <http://ns1.domain.com/>. > $ORIGIN system.lab.domain.com <http://system.lab.domain.com/>. > A 192.168.10.170 > > The other /var/lib/bind/db.system.lab.domain.com.10.32.X.X follow a similar > format with the domain name pointing to a different IP address for each > "version" of the domain matching a view for a different entry subnet. > > Again, the domain.com <http://domain.com/> zone currently has an entry for > system.lab.domain.com <http://system.lab.domain.com/> for 192.168.10.170 and > the secondary lab.domain.com <http://lab.domain.com/> has an entry for > system.lab.domain.com <http://system.lab.domain.com/> with 10.32.10.1. > > This was all working perfectly until I added the secondary domain to my > config [essentially just the contents of the main view above] which it > sta
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi Greg, Here's the most recent config that I tried that seemed to work, but ultimately broke resolution for the main zone domain.com, even though I set it to match-clients { any; }. What I didn't mention in my original post was that I have other subnets configured for this remote host through vlans with different IP addresses. That's why there are so many other views. I was hoping the match-clients per each view would return the appropriate IP address per subnet making the request. include "/etc/bind/rndc.key"; include "/etc/bind/ddns-key.key"; view "192.168.10-net" { match-clients { 192.168.10.0/24; }; zone "system.lab.domain.com" { type master; file "/var/lib/bind/db.system.lab.domain.com.192.168.10"; }; }; view "10.32.1-net" { match-clients { 10.32.1.0/24; }; zone "system.lab.domain.com" { type master; file "/var/lib/bind/db.system.lab.domain.com.10.32.1"; }; }; view "10.32.10-net" { match-clients { 10.32.10.0/24; }; zone "system.lab.domain.com" { type master; file "/var/lib/bind/db.system.lab.domain.com.10.32.10"; }; }; view "10.32.20-net" { match-clients { 10.32.20.0/24; }; zone "system.lab.domain.com" { type master; file "/var/lib/bind/db.system.lab.domain.com.10.32.20"; }; }; view "10.32.30-net" { match-clients { 10.32.30.0/24; }; zone "system.lab.domain.com" { type master; file "/var/lib/bind/db.system.lab.domain.com.10.32.30"; }; }; view "main" { match-clients { any; }; zone "domain.com" { type master; forwarders {}; file "/var/lib/bind/db.domain.com"; update-policy { grant ddns-key wildcard *.domain.com A DHCID; }; notify yes; allow-transfer { 192.168.10.183; }; }; zone "lab.domain.com" { type secondary; masterfile-format text; file "/var/lib/bind/db.lab.domain.com"; primaries { 192.168.10.183; }; }; zone "10.168.192.in-addr.arpa" { type master; forwarders {}; file "/var/lib/bind/db.10.168.192.in-addr.arpa"; update-policy { grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR; }; }; }; The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10: $ORIGIN . $TTL 604800 ; 1 week system.lab.domain.com IN SOA ns1.domain.com. thatrat.gmail.com. ( 2023062800 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200; expire (4 weeks) 604800 ; minimum (1 week) ) NS ns1.domain.com. $ORIGIN system.lab.domain.com. A 192.168.10.170 The other /var/lib/bind/db.system.lab.domain.com.10.32.X.X follow a similar format with the domain name pointing to a different IP address for each "version" of the domain matching a view for a different entry subnet. Again, the domain.com zone currently has an entry for system.lab.domain.com for 192.168.10.170 and the secondary lab.domain.com has an entry for system.lab.domain.com with 10.32.10.1. This was all working perfectly until I added the secondary domain to my config [essentially just the contents of the main view above] which it started only returning 10.32.10.1 for the system.lab.domain.com which again I think had some type of precedence on the "fuller" FQDN being served, and the system.lab from the domain.com zone taking lesser precedence. It also seems that the bind configuration file is read from top down in processing order? I had the main view on top first, but then moved it below the other views, and then the 192.168.10-net view worked...but the main view did not work. I know this is an overly complicated setup and probably the simplest answer is just to remove the secondary zone from config so that there is only the one entry that resolves for the system.lab.domain.com, I just thought that there might be a away to have the hostname resolve differently based on what the requesting IP address was. I also have Dynamic DNS setup so that the ISC DHCP server will update domain.com with system hostname info which *might* complicate things. On Wed, Jun 28, 2023 at 9:33 PM Greg Choules < gregchoules+bindus...@googlemail.com> wrote: > Hi Ubence. > Firstly, may we see your configs please. It's impossible to say exactly > what's going on from a human description. > > Secondly, views and different answers. Yes it *is* entirely possible to > use views to provide answers based on client IP - `match-clients. I would > start with the most specific view first with a `match-clients` clause, then > a general view without one. If you only have two choices. > > Thirdly, naming of multi-homed systems. A long time ago
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
On 28.06.23 15:45, Ubence Quevedo wrote: My question is, is there any way to "properly" return a hostname/IP based on what network the request is coming from? bind has "sortlist" statement that could do what you want. It will provide all IPs but sorted differently. Otherwise, you can set up multiple views with different versions of the same zone, configured to provide different verision according to source IP. This is much harder to set up. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi Ubence. Firstly, may we see your configs please. It's impossible to say exactly what's going on from a human description. Secondly, views and different answers. Yes it *is* entirely possible to use views to provide answers based on client IP - `match-clients. I would start with the most specific view first with a `match-clients` clause, then a general view without one. If you only have two choices. Thirdly, naming of multi-homed systems. A long time ago, in a previous job, I tried to work out how to make (say) "system.lab.domain.com" resolve to different addresses, depending on who was asking the question, or from which direction they were asking it and it nearly drove me mad. I concluded that "sytem" should not be regarded as one domain, but one domain *per interface*. So let's say that the box called "system" has two interfaces with addresses 192.168.10.170 for its lab side and 10.32.10.1 for its production side. I would do this and not bother with views: zone "domain.com" { type primary; file "db.domain.com"; }; Contents at least: @ SOA etc... @ IN NS lab IN NS ;don't forget the delegation system IN A 10.32.10.1 zone "lab.domain.com" { type primary; file "db.lab.domain.com"; }; Contents at least: @ SOA etc... @ IN NS system IN A 10.32.10.1 Now to reach "system", depending on who you are, which direction you are approaching it from and what network routeing and firewalls will allow you either connect to "system.domain.com" for its production side or system.lab.domain.com" for its lab side. There is no ambiguity about what address "system" has because each one now has a unique name. Note that this requires clients to use FQDNs, which IMHO is a good thing. I always try to avoid "search" in resolv.conf because it leaves the OS stub resolver guessing what the user actually wants. Hope that helps. But as i said, configs please and then *we* don't have to guess :) Cheers, Greg On Wed, 28 Jun 2023 at 23:45, Ubence Quevedo wrote: > Hi, > > I have two domains configured, a production and lab/testing domain [let's > say domain.com and lab.domain.com]. > > I have a few different networks configured [192.168.10.0/24 and > 10.32.10.0/24]. > > I have a system that has two network cards on both the 192.168.10.X > network and 10.32.10.X network. > > I have a remote system that is also configured to on both networks, with > hostnames on both domains/networks. > > I have a hostname entry in my primary master for the domain.com [ > system.lab.domain.com/192.168.10.170], but there are other systems > configured via the bind 9 system that serves out lab.domain.com with an > entry for this system [system.lab.domain.com/10.32.10.1]. > > On the primary DNS server, the system.lab.domain.com worked great and > pointed to 192.168.10.170, however I made the lab server a secondary on the > primary and vice-a-versa so that the lab.domain.com entries would resolve > for systems on the 192.168.10.X network so that the dual network capable > system would be able to resolve lab hostnames from my primary DNS server. > This is a Mac and the primary interface wins for name resolution as far as > I can tell even though the other network interface is configured to point > to the lab DNS server. > > This makes things work great to be able to resolve lab network host names, > but the 10.32.10.X network isn't directly accessible to the 192.168.10.X > network. > > What's happening is the that hostname I have configured on the primary > name server [system.lab.domain.com/192.168.10.170] is not taking > precedence over the secondary domain that is configured [ > system.lab.domain.com/10.32.10.1]. > > Any resolution now for the system.lab.totusmel.coml hostname now brings > back 10.32.10.1 instead of the 192.168.10.170. > > I think it's because the lab domain takes precedence because the domain > name lab.domain.com is a higher priority than domain.com even with the > system.lab tacked onto the primary domain. > > I started dabbling with views and tried to set up specific views that > would return a fully qualified hostname as a domain based on what network > the request came from. If the request came from the 10.32.10.X network, > return the system.lab.domain.com/10.32.10.1 entry and if it came from the > 192.168.10.X network, return the system.lab.domain.com/192.168.10.170 > entry. > > This seemed to work after re-arranging the order of the main configuration > file, and I could resolve the system.lab.domain.com as 192.168.10.170 as > I intended but this then broke all of the host entries I had configured for > domain.com as none were resolvable. > > >
Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
Hi, I have two domains configured, a production and lab/testing domain [let's say domain.com and lab.domain.com]. I have a few different networks configured [192.168.10.0/24 and 10.32.10.0/24]. I have a system that has two network cards on both the 192.168.10.X network and 10.32.10.X network. I have a remote system that is also configured to on both networks, with hostnames on both domains/networks. I have a hostname entry in my primary master for the domain.com [ system.lab.domain.com/192.168.10.170], but there are other systems configured via the bind 9 system that serves out lab.domain.com with an entry for this system [system.lab.domain.com/10.32.10.1]. On the primary DNS server, the system.lab.domain.com worked great and pointed to 192.168.10.170, however I made the lab server a secondary on the primary and vice-a-versa so that the lab.domain.com entries would resolve for systems on the 192.168.10.X network so that the dual network capable system would be able to resolve lab hostnames from my primary DNS server. This is a Mac and the primary interface wins for name resolution as far as I can tell even though the other network interface is configured to point to the lab DNS server. This makes things work great to be able to resolve lab network host names, but the 10.32.10.X network isn't directly accessible to the 192.168.10.X network. What's happening is the that hostname I have configured on the primary name server [system.lab.domain.com/192.168.10.170] is not taking precedence over the secondary domain that is configured [system.lab.domain.com/10.32.10.1]. Any resolution now for the system.lab.totusmel.coml hostname now brings back 10.32.10.1 instead of the 192.168.10.170. I think it's because the lab domain takes precedence because the domain name lab.domain.com is a higher priority than domain.com even with the system.lab tacked onto the primary domain. I started dabbling with views and tried to set up specific views that would return a fully qualified hostname as a domain based on what network the request came from. If the request came from the 10.32.10.X network, return the system.lab.domain.com/10.32.10.1 entry and if it came from the 192.168.10.X network, return the system.lab.domain.com/192.168.10.170 entry. This seemed to work after re-arranging the order of the main configuration file, and I could resolve the system.lab.domain.com as 192.168.10.170 as I intended but this then broke all of the host entries I had configured for domain.com as none were resolvable. My question is, is there any way to "properly" return a hostname/IP based on what network the request is coming from? This seemed like it would work, and it kind of did, but even with a separate view of "any" for the hostnames of the production domain, this didn't quite work. I know this is a somewhat confusing set up, but I thought it might be possible to resolve a hostname difference with views based on the requesting network. Any thoughts or advice would be greatly appreciated! -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KASP: sharing policy and keys between views
Hi Carsten.I've been running split views with a DNSSEC zone using dnssec-policy for at least a couple of years.I'm using a CSK (i.e. combined KSK+ZSK) and haven't yet worked out the best way to automate key rollover wrt DS in parent zone, so my key rollovers are manual currently. Consequently I've only done a key rollover a couple of time in that period.But this setup has been working fine for me the whole time.Nick. Original message From: Matthijs Mekking Date: 18/03/23 3:43 AM (GMT+12:00) To: bind-users@lists.isc.org Subject: Re: KASP: sharing policy and keys between views Hi Carsten,We did have some bugs in the past when it comes to sharing keys with dnssec-policy among different views. But the last one is from a year ago (fixed in 9.16.19).So while I don't have experience myself with a similar setup, we did have some bug reports that used dnssec-policy and views that have been resolved and it has been quiet when it comes to "dnssec-policy with views" related bug reports.Now that doesn't mean there are none, but hopefully adds a bit of confidence.Best regards, MatthijsOn 3/17/23 11:46, Carsten Strotmann via bind-users wrote:> Hi,> > (please do not start a discussion on the usefulness of views. I'm not> in favor of views, but sometimes I have to work with them).> > I have a client that runs a split horizon (internal / external view> of the same domain namespace) setup with BIND 9 on Linux.> > Both the internal and external views of the domain are DNSSEC> signed.> > In the past, the setup was using "auto-dnssec maintain;" on a common,> shared key directory with manually created keys. Both zones in both> views fetched the keys and did the signing. This setup was stable and> working fine.> > Because "auto-dnssec maintain;" is deprecated, we're evaluating to> change the setup to use a shared DNSSEC KASP definition, pointing to> the same key directory (using shared keys and a shared state file).> > The test setup runs without issues for one month now and has> successfully done 3 ZSK rollovers in the time (KSK rollovers are> manual). So it *seems* like a working configuration. We have not seen> errors or race-conditions (but we might have been lucky).> > Does anyone here has experience with a similar setup, or deeper> insight into the code and can tell me if this is a possible solution> to operate a DNSSEC signed split horizon setup?> > Greetings> > Carsten Strotmann> > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KASP: sharing policy and keys between views
Hi Carsten, We did have some bugs in the past when it comes to sharing keys with dnssec-policy among different views. But the last one is from a year ago (fixed in 9.16.19). So while I don't have experience myself with a similar setup, we did have some bug reports that used dnssec-policy and views that have been resolved and it has been quiet when it comes to "dnssec-policy with views" related bug reports. Now that doesn't mean there are none, but hopefully adds a bit of confidence. Best regards, Matthijs On 3/17/23 11:46, Carsten Strotmann via bind-users wrote: Hi, (please do not start a discussion on the usefulness of views. I'm not in favor of views, but sometimes I have to work with them). I have a client that runs a split horizon (internal / external view of the same domain namespace) setup with BIND 9 on Linux. Both the internal and external views of the domain are DNSSEC signed. In the past, the setup was using "auto-dnssec maintain;" on a common, shared key directory with manually created keys. Both zones in both views fetched the keys and did the signing. This setup was stable and working fine. Because "auto-dnssec maintain;" is deprecated, we're evaluating to change the setup to use a shared DNSSEC KASP definition, pointing to the same key directory (using shared keys and a shared state file). The test setup runs without issues for one month now and has successfully done 3 ZSK rollovers in the time (KSK rollovers are manual). So it *seems* like a working configuration. We have not seen errors or race-conditions (but we might have been lucky). Does anyone here has experience with a similar setup, or deeper insight into the code and can tell me if this is a possible solution to operate a DNSSEC signed split horizon setup? Greetings Carsten Strotmann -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
KASP: sharing policy and keys between views
Hi, (please do not start a discussion on the usefulness of views. I'm not in favor of views, but sometimes I have to work with them). I have a client that runs a split horizon (internal / external view of the same domain namespace) setup with BIND 9 on Linux. Both the internal and external views of the domain are DNSSEC signed. In the past, the setup was using "auto-dnssec maintain;" on a common, shared key directory with manually created keys. Both zones in both views fetched the keys and did the signing. This setup was stable and working fine. Because "auto-dnssec maintain;" is deprecated, we're evaluating to change the setup to use a shared DNSSEC KASP definition, pointing to the same key directory (using shared keys and a shared state file). The test setup runs without issues for one month now and has successfully done 3 ZSK rollovers in the time (KSK rollovers are manual). So it *seems* like a working configuration. We have not seen errors or race-conditions (but we might have been lucky). Does anyone here has experience with a similar setup, or deeper insight into the code and can tell me if this is a possible solution to operate a DNSSEC signed split horizon setup? Greetings Carsten Strotmann -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Views vs Separate Authoritative & Recursive DNS
Hi E R. My short answer would be, don't configure views unless you have a good use case for them. For example you are running resolvers that have two different kinds of clients that need to be handled differently - one client set needs RPZ, the other doesn't. Or something like that. BIND has views inside anyway. If you run "rndc stats" it produces a file called "named.stats", in which you will see line like this: [View: _bind] [View: default] The "_bind" view is always there and is used for internal processing. The "default" exists for all client processing and if you define your own views it disappears. So having one user-defined view is functionally equivalent to having no views. One possible reason I can think of for defining a view would be if you know you will need to add more views in future, so would like to standardise the structure of your config day one. It's a bit like configuring an Ethernet switch: do I configure VLANs even though (today) it's one flat network? Hope that helps. Greg On Wed, 4 Jan 2023 at 01:15, E R wrote: > New to BIND and just starting to read the 5th edition from O'Reilly after > watching some videos online while it made its way to me. I am trying to > understand why the view statement appears to be included by default in most > Linux distributions if best practice says you should have separate servers > for each? Based on the comments in the named.conf sample file I am > inclined to remove all of the view statements so it operates in "default > view" on new servers I am setting up to replace old ones. Is the view > statement just there for those who need to ignore best practices or am I > missing something? > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Views vs Separate Authoritative & Recursive DNS
New to BIND and just starting to read the 5th edition from O'Reilly after watching some videos online while it made its way to me. I am trying to understand why the view statement appears to be included by default in most Linux distributions if best practice says you should have separate servers for each? Based on the comments in the named.conf sample file I am inclined to remove all of the view statements so it operates in "default view" on new servers I am setting up to replace old ones. Is the view statement just there for those who need to ignore best practices or am I missing something? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC signing common zone in views
Hello Matthijs, On Thu, Sep 8, 2022 at 11:56 AM Matthijs Mekking wrote: > > Hi Josef, > > First of all I would like to point out the KB article about to > dnssec-policy, especially the part about migrating. > > https://kb.isc.org/docs/dnssec-key-and-signing-policy > > Although we try to asses the current signing situation, since there are > no key state files it will be an educated guess. Switching to a policy > that doesn't match your current situation might lead to withdrawing > existing signatures and keys too soon. > Thank you, I actually know that article pretty well - it helped me several times when I did such migrations. In this particular case, I don't know exactly why, a new key was always generated and the old key with id 14237 was always retired as soon as I enabled dnssec-policy. The algo in policy was set to match the situation, but it happened regardless. I had hit that in the past, before the fix was introduced (https://gitlab.isc.org/isc-projects/bind9/-/issues/2857), so I was prepared :) What helped me in this case was simple. I just created the KACME.cz.+013+14237.state file myself, and told bind little more about the key and how to use it: ; This is the state of key 14237, for ACME.cz. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes > Once BIND is maintaining key states, it is safe to change your > dnssec-policy to whatever you want. BIND will gradually move to the new > desired > policy, possibly doing key (algorithm) rollovers. > > Key rollovers happen automatically, but since you are using an unlimited > lifetime they will never be triggered unless manually with rndc. > > There is one manual step that needs to be performed during CSK and KSK > rollovers, that is updating the DS RRset to the parent. Once that is > done you can run the related 'rndc dnssec -checkds' commands. > > Or you can set up parental-agents that would check for the DS in the > parent automatically. > > As long as you use the same dnssec-policy for the zones, you can use the > same key-directory (since 9.16.18). The key rollover would happen at the > same time for the zone. Thank you! This is exactly the information I was looking for. Cheers Josef > > You can also set a different key-directory. In that case the key is not > shared, each view of the zone would have a separate DNSSEC key. > > I think it is fine using the same key-directory. The only thing is when > you change your configuration in the future such that the dnssec-policy > is different for each view of the zone, you have to also change the > key-directory to be different. > > Best regards, > > Matthijs > > > > On 07-09-2022 15:19, Josef Vybíhal wrote: > > Hello all, > > I am consolidating our old split DNS consisting of internal and > > external dedicated servers(VMs) into one primary server with views > > (there will be secondaries, but they are not important to the > > question). The old previous configuration is using inline-signing and > > auto-dnssec. I will be switching to dnssec-policy with csk. This is > > fine. > > > > My question is what would be considered best practice when I want the > > zone to be signed by the same CSK in every view. Should I point both > > zones to the same "key-directory", or should I use a different > > directory for every view? And how would the key rollover work in such > > a case? > > > > I have tried to use the same key-directory for both zones in each > > view. It seems to technically work. But maybe someone could point out > > some disadvantages I will be facing in the future? Is there common > > consensus on how this is supposed to be approached? Maybe I am > > handling it all wrong and there is a much better way :) > > > > > > The config I tested: > > > > dnssec-policy "ACME" { > > keys { csk key-directory lifetime unlimited algorithm 13; }; > > nsec3param iterations 1 optout false salt-length 16; > > }; > > > > view internal { > > > > match-clients { internal; }; > > > > zone "ACME.cz" { > > type primary; > > file "primary/internal/ACME.cz/ACME.cz.zone"; > > inline-signing yes; > > key-directory "dnssec-keys/ACME.cz"; > > dnssec-policy "ACME"; > > }; > > > > }; > > > > view external { > > > > match-clients { external; }; > > > > zone "ACME.cz" { > > type primary; > > file "primary/external/ACME.cz/ACME.cz.zone"; > > inline-signing yes; > >
Re: DNSSEC signing common zone in views
Hi Josef, First of all I would like to point out the KB article about to dnssec-policy, especially the part about migrating. https://kb.isc.org/docs/dnssec-key-and-signing-policy Although we try to asses the current signing situation, since there are no key state files it will be an educated guess. Switching to a policy that doesn't match your current situation might lead to withdrawing existing signatures and keys too soon. Once BIND is maintaining key states, it is safe to change your dnssec-policy to whatever you want. BIND will gradually move to the new desired policy, possibly doing key (algorithm) rollovers. Key rollovers happen automatically, but since you are using an unlimited lifetime they will never be triggered unless manually with rndc. There is one manual step that needs to be performed during CSK and KSK rollovers, that is updating the DS RRset to the parent. Once that is done you can run the related 'rndc dnssec -checkds' commands. Or you can set up parental-agents that would check for the DS in the parent automatically. As long as you use the same dnssec-policy for the zones, you can use the same key-directory (since 9.16.18). The key rollover would happen at the same time for the zone. You can also set a different key-directory. In that case the key is not shared, each view of the zone would have a separate DNSSEC key. I think it is fine using the same key-directory. The only thing is when you change your configuration in the future such that the dnssec-policy is different for each view of the zone, you have to also change the key-directory to be different. Best regards, Matthijs On 07-09-2022 15:19, Josef Vybíhal wrote: Hello all, I am consolidating our old split DNS consisting of internal and external dedicated servers(VMs) into one primary server with views (there will be secondaries, but they are not important to the question). The old previous configuration is using inline-signing and auto-dnssec. I will be switching to dnssec-policy with csk. This is fine. My question is what would be considered best practice when I want the zone to be signed by the same CSK in every view. Should I point both zones to the same "key-directory", or should I use a different directory for every view? And how would the key rollover work in such a case? I have tried to use the same key-directory for both zones in each view. It seems to technically work. But maybe someone could point out some disadvantages I will be facing in the future? Is there common consensus on how this is supposed to be approached? Maybe I am handling it all wrong and there is a much better way :) The config I tested: dnssec-policy "ACME" { keys { csk key-directory lifetime unlimited algorithm 13; }; nsec3param iterations 1 optout false salt-length 16; }; view internal { match-clients { internal; }; zone "ACME.cz" { type primary; file "primary/internal/ACME.cz/ACME.cz.zone"; inline-signing yes; key-directory "dnssec-keys/ACME.cz"; dnssec-policy "ACME"; }; }; view external { match-clients { external; }; zone "ACME.cz" { type primary; file "primary/external/ACME.cz/ACME.cz.zone"; inline-signing yes; key-directory "dnssec-keys/ACME.cz"; dnssec-policy "ACME"; }; }; --- ns1-new /var/named/dnssec-keys/ACME.cz # cat KACME.cz.+013+14237.state ; This is the state of key 14237, for ACME.cz. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20190611121855 (Tue Jun 11 14:18:55 2019) Published: 20190611121855 (Tue Jun 11 14:18:55 2019) Active: 20190611121855 (Tue Jun 11 14:18:55 2019) PublishCDS: 20190612132355 (Wed Jun 12 15:23:55 2019) DNSKEYChange: 20220907123627 (Wed Sep 7 14:36:27 2022) ZRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) KRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) DSChange: 20220907123627 (Wed Sep 7 14:36:27 2022) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent # named -V BIND 9.18.6 (Stable Release) running on Linux x86_64 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2 16:19:42 UTC 2022 Thanks, Josef -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC signing common zone in views
Hello all, I am consolidating our old split DNS consisting of internal and external dedicated servers(VMs) into one primary server with views (there will be secondaries, but they are not important to the question). The old previous configuration is using inline-signing and auto-dnssec. I will be switching to dnssec-policy with csk. This is fine. My question is what would be considered best practice when I want the zone to be signed by the same CSK in every view. Should I point both zones to the same "key-directory", or should I use a different directory for every view? And how would the key rollover work in such a case? I have tried to use the same key-directory for both zones in each view. It seems to technically work. But maybe someone could point out some disadvantages I will be facing in the future? Is there common consensus on how this is supposed to be approached? Maybe I am handling it all wrong and there is a much better way :) The config I tested: dnssec-policy "ACME" { keys { csk key-directory lifetime unlimited algorithm 13; }; nsec3param iterations 1 optout false salt-length 16; }; view internal { match-clients { internal; }; zone "ACME.cz" { type primary; file "primary/internal/ACME.cz/ACME.cz.zone"; inline-signing yes; key-directory "dnssec-keys/ACME.cz"; dnssec-policy "ACME"; }; }; view external { match-clients { external; }; zone "ACME.cz" { type primary; file "primary/external/ACME.cz/ACME.cz.zone"; inline-signing yes; key-directory "dnssec-keys/ACME.cz"; dnssec-policy "ACME"; }; }; --- ns1-new /var/named/dnssec-keys/ACME.cz # cat KACME.cz.+013+14237.state ; This is the state of key 14237, for ACME.cz. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20190611121855 (Tue Jun 11 14:18:55 2019) Published: 20190611121855 (Tue Jun 11 14:18:55 2019) Active: 20190611121855 (Tue Jun 11 14:18:55 2019) PublishCDS: 20190612132355 (Wed Jun 12 15:23:55 2019) DNSKEYChange: 20220907123627 (Wed Sep 7 14:36:27 2022) ZRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) KRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022) DSChange: 20220907123627 (Wed Sep 7 14:36:27 2022) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent # named -V BIND 9.18.6 (Stable Release) running on Linux x86_64 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2 16:19:42 UTC 2022 Thanks, Josef -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: response policy zones (rpz) and views - memory consumption
Jiri Hromadka wrote: > > Is there any way to reuse already loaded rpz zone in memory for other > views ? I know in-view is not an option for rpz, using one master / > slave zones has same memory effect. Yeah, in-view would be perfect, if only :-) You might try setting up a view that only does recursive resolution and RPZ, and configure the per-client views to forward to the RPZ view. It's probably also worth configuring a small cache size limit in the per-client views to avoid too much duplication. Self-forwarding won't have amazingly good performance but you only need to worry about that if you are running at many thousands of queries per second. Tony. -- f.anthony.n.finchhttps://dotat.at/ Forth, Tyne: North or northeast 3 to 5. Slight or moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
response policy zones (rpz) and views - memory consumption
Hi, I’ve read many archived mails here and I haven’t found solution / answer, so let me ask you guys. I’m running Bind 9.11+ and using views for around 10 clients on single server, all clients has different settings and everything was working great, until we’ve decided to implement RPZ for them. We build single rpz zone file from opensource/paid sources and it contains more than 200k malicious/adware/phishing domains that we want our clients protect from. When we use this zone and set response policy for testing view, everything was working perfect and binds memory consumption has increased by ~100MB. However when we’ve set the same rpz zone any response policy for other views (we want all view has the same RPZ zone and policy), binds memory consumption has increased by ~100MB for each zone. This might be a problem in future when rpz zone file gets bigger. Is there any way to reuse already loaded rpz zone in memory for other views ? I know in-view is not an option for rpz, using one master / slave zones has same memory effect. Thank you for any advice. Jiri ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with internal/external VIEWs
Well! That was the quickest & simplest WORKING solution I have ever received from a mailing list! Thank you! On 2021-07-05 17:55, Mark Andrews wrote: If you want the content to be the same in both views and to be dynamically updatable then use view view1 { zone example.com { type primary; [ allow-update / update-policy ] { … }; … }; }; view view2 { zone example.com { in-view “view1”; }; }; ... On 2021-07-05 12:36, Dean Gibson (DNS Administrator) wrote: Currently running Bind v9.11.4: Several years ago, I implemented multiple VIEWs using (almost) the exact example in the Reference Manual. However, I wanted the "example-internal.db" and "example-external.db" to be the same file. This worked until I wanted to have "example.com" updateable via ddns. I don't remember the exact error, but I have a note in my configuration file of /"don't do that!"/ (use the same file). So, I removed the first zone declaration for "example.com". That was still with Bind v9, but a lesser minor version. So, the result is that I can't do a "dig -k tsig.file @localhost -t axfr example.com" from the server command line. The transfer is denied, because "match-clients" forces me into the first (internal) VIEW. The server is behind a firewall (which has a forward to the server), so "dig" works if I specify "dig -k tsig.file @ns1.example.com". Because of this, I can still use "dig" like I want on the server. However, I'd think this must be a common issue. Any resolution (like recognizing & dealing with two references to a dynamically updated file)? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with internal/external VIEWs
If you want the content to be the same in both views and to be dynamically updatable then use view view1 { zone example.com { type primary; [ allow-update / update-policy ] { … }; … }; }; view view2 { zone example.com { in-view “view1”; }; }; If you want the zone content to be different then use different file names for the zone and use different TSIG names to select views for NOTIFY, UPDATE, and AXFR. key view1-update-example.com { … }; key view2-update-example.com { … }; key view1-xfr-example.com { … }; key view2-xfr-example.com { … }; view view1 { match-clients { view1-update-example.com; !view2-update-example.com; view1-xfr-example.com; !view2-xfr-example.com; … }; server { key view1-xfr-example.com; // so NOTIFY goes to the correct view }; zone example.com { type primary; allow-update { view1-update-example.com; }; // or update-policy allow-transfer { view1-xfr-example.com; }; file “view1/example.com.db”; }; }; view view2 { match-clients { !view1-update-example.com; view2-update-example.com; !view1-xfr-example.com; view2-xfr-example.com; … }; server { key view1-xfr-example.com; // so NOTIFY goes to the correct view }; zone example.com { type primary; allow-update { view2-update-example.com; }; // or update-policy allow-transfer { view2-xfr-example.com; }; file “view2/example.com.db”; }; }; and on the secondaries you key view1-update-example.com { … }; key view2-update-example.com { … }; key view1-xfr-example.com { … }; key view2-xfr-example.com { … }; view view1 { match-clients { view1-update-example.com; !view2-update-example.com; view1-xfr-example.com; !view2-xfr-example.com; … }; server { key view1-xfr-example.com; // so SOA, IXFR and AXFR go to the correct view. }; zone example.com { type secondary; primaries { ; }; allow-transfer { view1-xfr-example.com; }; file “view1/example.com.db”; }; }; view view2 { match-clients { !view1-update-example.com; view2-update-example.com; !view1-xfr-example.com; view2-xfr-example.com; … }; server { key view2-xfr-example.com; // so SOA, IXFR and AXFR go to the correct view. }; zone example.com { type secondary; primaries { ; }; allow-transfer { view2-xfr-example.com; }; file “view2/example.com.db”; }; }; > On 6 Jul 2021, at 05:36, Dean Gibson (DNS Administrator) > wrote: > > Currently running Bind v9.11.4: > > Several years ago, I implemented multiple VIEWs using (almost) the exact > example in the Reference Manual. However, I wanted the "example-internal.db" > and "example-external.db" to be the same file. > > This worked until I wanted to have "example.com" updateable via ddns. I > don't remember the exact error, but I have a note in my configuration file of > "don't do that!" (use the same file). So, I removed the first zone > declaration for "example.com". That was still with Bind v9, but a lesser > minor version. > > So, the result is that I can't do a "dig -k tsig.file @localhost -t axfr > example.com" from the server command line. The transfer is denied, because > "match-clients" forces me into the first (internal) VIEW. > > The server is behind a firewall (which has a forward to the server), so "dig" > works if I specify "dig -k tsig.file @ns1.example.com". Because of this, I > can still use "dig" like I want on the server. > > However, I'd think this must be a common issue. Any resolution (like > recognizing & dealing with two references to a dynamically updated file)? > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___
Problem with internal/external VIEWs
Currently running Bind v9.11.4: Several years ago, I implemented multiple VIEWs using (almost) the exact example in the Reference Manual. However, I wanted the "example-internal.db" and "example-external.db" to be the same file. This worked until I wanted to have "example.com" updateable via ddns. I don't remember the exact error, but I have a note in my configuration file of /"don't do that!"/ (use the same file). So, I removed the first zone declaration for "example.com". That was still with Bind v9, but a lesser minor version. So, the result is that I can't do a "dig -k tsig.file @localhost -t axfr example.com" from the server command line. The transfer is denied, because "match-clients" forces me into the first (internal) VIEW. The server is behind a firewall (which has a forward to the server), so "dig" works if I specify "dig -k tsig.file @ns1.example.com". Because of this, I can still use "dig" like I want on the server. However, I'd think this must be a common issue. Any resolution (like recognizing & dealing with two references to a dynamically updated file)? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy & views
Hi Graham, On 2/29/20 5:27 PM, Graham Clinch wrote: > How does the new-in-9.16 dnssec-policy interact with views - in > particular for key generation/rollover? > > For example, we have a zone defined in multiple views with different > contents (and thus not suitable for in-view), being signed by the same > set of keys (currently maintained by dnssec-keymgr) - this allows us to > publish only a single set of DS records for that zone. > > If a zone 'example.net' is defined in view 'a', and a zone 'example.net' > is defined in view 'b', but both views share a single key-directory, is > it 'safe' to configure dnssec-policy in both views? Thanks for sharing your use case. I tried it and it is unsafe to do so in 9.16.0. The dnssec-policy does not take into account shared keys. But with views you sort of implicitly have shared keys because you have multiple versions of the zone. In the current code there is a race condition on running key management on the different versions of the zone which may result in too many keys. I created an issue for this bug: https://gitlab.isc.org/isc-projects/bind9/issues/1653 And I have a proposed fix for it. It may make the 9.16.1 release, otherwise 9.16.2. With this fix you should be able to safely configure dnssec-policy for a zone in multiple views, sharing the same set of keys. Best regards, Matthijs > > Graham > ___ > 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 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
dnssec-policy & views
How does the new-in-9.16 dnssec-policy interact with views - in particular for key generation/rollover? For example, we have a zone defined in multiple views with different contents (and thus not suitable for in-view), being signed by the same set of keys (currently maintained by dnssec-keymgr) - this allows us to publish only a single set of DS records for that zone. If a zone 'example.net' is defined in view 'a', and a zone 'example.net' is defined in view 'b', but both views share a single key-directory, is it 'safe' to configure dnssec-policy in both views? Graham ___ 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: "overlay" views
On 1/20/20 6:28 AM, Brian J. Murrell wrote: I'm really not sure about what the name of this feature I am going to describe would be. I would probably call it an "overlay view". But I am sure there are better names. I get why you say "overlay view", but I think I'd try to avoid the "overlay" term for various reasons. Imagine I have a BIND 9 server for the following network topology: Network 1 192.168.1.0/24 -|.254 | | Router | Network 2| | 192.168.2.0/24 | | -|.254 | | | Network 3| | 192.168.3.0/24 | | -|.254 | There are a few dozen hosts/services on Network 3 which hosts from Network 1 and Network 2 need to resolve names of. All pretty straightforward. But the hosts on Network 1 and Network 2 need to resolve the same name (let's call it "gateway") to the address of their interface on Router. So that is, hosts on Network 1 want a query of "gateway." to resolve to 192.168.1.254 and hosts on Network 2 want a query of "gateway." to resolve to 192.168.2.254. Okay. So this is currently all achievable through "views" in BIND 9, but requires that the zone data for each view be 98% duplicate (Network 3 resources) and continually copy-n-paste updated whenever names on Network 3 are added. Yep. What I am looking for is a way to save the duplicate copying of Network 3 resources to the views for Network 1 and Network 2. This is where the term "overlay" comes in. What I'd like to do is reference a single copy of data from Network 3 in Network 1 and 2's views but "overlay" some view-specific resources on top of that, namely the "gateway." name, with it's per-view specific value. Thoughts? A couple of things come to mind. 1) Do you /need/ the gateway name to resolve exclusively to the single IP of the connected network? Or could you possibly leverage BIND's ability to sort / order responses based on client network? I.e. return the IP in the client's network /first/. 2) Split things into two levels of zones. The first being the common example.net and the second being gateway.example.net. Have the parent delegate gateway. Then have the parent in all three views (possibly via "in-view" that Tony mentioned) and each network's specific gateway.example.net in each respective view. You would simply put the gatteway's IP in the apex of the gateway.example.net zone. The behavior of #2 would be quite similar to what Bob suggested, but would avoid CNAMEs and just answer with authority directly. -- 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: "overlay" views
On Mon, Jan 20, 2020 at 8:28 AM Brian J. Murrell wrote: > I'm really not sure about what the name of this feature I am going to > describe would be. I would probably call it an "overlay view". But I > am sure there are better names. > > Imagine I have a BIND 9 server for the following network topology: > > > Network 1 > 192.168.1.0/24 > -|.254 | > | Router | > Network 2| | > 192.168.2.0/24 | | > -|.254 | > | | > Network 3| | > 192.168.3.0/24 | | > -|.254 | > > > There are a few dozen hosts/services on Network 3 which hosts from > Network 1 and Network 2 need to resolve names of. All pretty > straightforward. > > But the hosts on Network 1 and Network 2 need to resolve the same name > (let's call it "gateway") to the address of their interface on Router. > So that is, hosts on Network 1 want a query of "gateway." to resolve to > 192.168.1.254 and hosts on Network 2 want a query of "gateway." to > resolve to 192.168.2.254. > > So this is currently all achievable through "views" in BIND 9, but > requires that the zone data for each view be 98% duplicate (Network 3 > resources) and continually copy-n-paste updated whenever names on > Network 3 are added. > > What I am looking for is a way to save the duplicate copying of Network > 3 resources to the views for Network 1 and Network 2. This is where > the term "overlay" comes in. What I'd like to do is reference a single > copy of data from Network 3 in Network 1 and 2's views but "overlay" > some view-specific resources on top of that, namely the "gateway." > name, with it's per-view specific value. > > Thoughts? > > b. > > What I have set up, is for the few names that need to be different, use CNAME to a zone that is different in each view: This zone is same in all views: zone example.com host1.example.com IN A 10.0.0.4 host2.example.com IN A 10.1.1.7 router.example.com CNAME router.splitview.example.com Then in one view: zone splitview.example.com router.splitview.example.com IN A 10.0.0.1 And the other view: zone splitview.example.com router.splitview.example.com IN A 10.1.1.1 Any downsides that I have not thought about? -- Bob Harold ___ 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: "overlay" views
Brian J. Murrell wrote: > > But the hosts on Network 1 and Network 2 need to resolve the same name > (let's call it "gateway") to the address of their interface on Router. > So that is, hosts on Network 1 want a query of "gateway." to resolve to > 192.168.1.254 and hosts on Network 2 want a query of "gateway." to > resolve to 192.168.2.254. This is a strange requirement. It sounds to me like you have dug yourself into a hole made of unwise decisions and you'd be better off revisiting them rather than solving the immediate problem. > What I am looking for is a way to save the duplicate copying of Network > 3 resources to the views for Network 1 and Network 2. This is where > the term "overlay" comes in. What I'd like to do is reference a single > copy of data from Network 3 in Network 1 and 2's views but "overlay" > some view-specific resources on top of that, namely the "gateway." > name, with it's per-view specific value. Use "in-view" zones for the shared data, and view-specific zones for the data that differs. On our authoritative servers we have a "main" view which has all the zones configured in the usual way, and an "external" view which refers to the public zones using "in-view main". Our internal zone private.cam.ac.uk is configured in the external view with a static empty zone file to return NXDOMAIN to errant queries, because using an ACL to return REFUSED causes problems with query retries and CAA lookup failures, amongst other things. Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: Westerly or southwesterly, 6 or 7 until later north and west of Islay, otherwise 4 or 5. Moderate or rough, occasionally very rough from Islay northwards. Occasional rain or drizzle. Moderate or 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
"overlay" views
I'm really not sure about what the name of this feature I am going to describe would be. I would probably call it an "overlay view". But I am sure there are better names. Imagine I have a BIND 9 server for the following network topology: Network 1 192.168.1.0/24 -|.254 | | Router | Network 2| | 192.168.2.0/24 | | -|.254 | | | Network 3| | 192.168.3.0/24 | | -|.254 | There are a few dozen hosts/services on Network 3 which hosts from Network 1 and Network 2 need to resolve names of. All pretty straightforward. But the hosts on Network 1 and Network 2 need to resolve the same name (let's call it "gateway") to the address of their interface on Router. So that is, hosts on Network 1 want a query of "gateway." to resolve to 192.168.1.254 and hosts on Network 2 want a query of "gateway." to resolve to 192.168.2.254. So this is currently all achievable through "views" in BIND 9, but requires that the zone data for each view be 98% duplicate (Network 3 resources) and continually copy-n-paste updated whenever names on Network 3 are added. What I am looking for is a way to save the duplicate copying of Network 3 resources to the views for Network 1 and Network 2. This is where the term "overlay" comes in. What I'd like to do is reference a single copy of data from Network 3 in Network 1 and 2's views but "overlay" some view-specific resources on top of that, namely the "gateway." name, with it's per-view specific value. Thoughts? b. signature.asc Description: This is a digitally signed message part ___ 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 with views: forward any public domain in one view
Thanks a lot !!! El jue., 15 ago. 2019 a las 13:09, Matus UHLAR - fantomas (< uh...@fantomas.sk>) escribió: > On 15.08.19 12:18, Roberto Carna wrote: > >Dear, I have a BIND 9 working with two views. > > > >One view forwards two public domains to our resolver. > > > >And I want the second view to forward any public domain to our resolver in > >order to let navigate withouth restrictions. > > what restricions and where are they applied? > > >I need something like this: > > > >zone "ANY" { > >type forward; > >forward only; > >forwarders { > >8.8.8.8; > >}; > >}; > > > >How can I implement this second option ??? Can I replace ANY for the > >correct wildcard ??? > > "." should be enough, but note that BIND can do the same that google > servers > (8.8.8.8) can do, and you'll avoid one hop. > > simply don't forward but let BIND to resolve. > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > The early bird may get the worm, but the second mouse gets the cheese. > ___ > 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 with views: forward any public domain in one view
On 15.08.19 12:18, Roberto Carna wrote: Dear, I have a BIND 9 working with two views. One view forwards two public domains to our resolver. And I want the second view to forward any public domain to our resolver in order to let navigate withouth restrictions. what restricions and where are they applied? I need something like this: zone "ANY" { type forward; forward only; forwarders { 8.8.8.8; }; }; How can I implement this second option ??? Can I replace ANY for the correct wildcard ??? "." should be enough, but note that BIND can do the same that google servers (8.8.8.8) can do, and you'll avoid one hop. simply don't forward but let BIND to resolve. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese. ___ 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 with views: forward any public domain in one view
Dear, I have a BIND 9 working with two views. One view forwards two public domains to our resolver. And I want the second view to forward any public domain to our resolver in order to let navigate withouth restrictions. I need something like this: zone "ANY" { type forward; forward only; forwarders { 8.8.8.8; }; }; How can I implement this second option ??? Can I replace ANY for the correct wildcard ??? Thanks a lot !!! ___ 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 with Views: zone transfer refused from master to slave
Dear people, finalla I could put to work my zone transfers. I have review my config one more time and I am using one TSIG key for each view. Thanks a lot, regards!!! El jue., 4 jul. 2019 a las 9:38, Tony Finch () escribió: > Roberto Carna wrote: > > > > As I have shown above, I use two views with a TSIG key for each view, but > > the zone transfer doesn't work. > > The redacted config you posted did not consistently use key one in view > one and key two in view two. I don't know if your real config has the same > mistake or not. > > You might find your logs help you to debug the problem, though recent > versions of BIND are better at logging details of TSIG keys. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Trafalgar: Cyclonic 4 or 5, occasionally 6 in north. Moderate or rough. > Thundery 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
Re: Bind 9 with Views: zone transfer refused from master to slave
Roberto Carna wrote: > > As I have shown above, I use two views with a TSIG key for each view, but > the zone transfer doesn't work. The redacted config you posted did not consistently use key one in view one and key two in view two. I don't know if your real config has the same mistake or not. You might find your logs help you to debug the problem, though recent versions of BIND are better at logging details of TSIG keys. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic 4 or 5, occasionally 6 in north. Moderate or rough. Thundery 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
Re: Bind 9 with Views: zone transfer refused from master to slave
Dear, thanks for your help. As I have shown above, I use two views with a TSIG key for each view, but the zone transfer doesn't work. Please can you send me your Bind views configuration if you can, on master and slave sides? Thanks a lot again. Regards!!! El mié., 3 jul. 2019 a las 17:27, Sten Carlsen () escribió: > > > On 03/07/2019 22.14, Grant Taylor via bind-users wrote: > > On 7/3/19 2:04 PM, Lightner, Jeffrey wrote: > > You have to use separate IPs for the separate views on the master and the > slave. > > > I thought you could use different TSIG keys to identify different zones > with a single IP at each end. > > Is that not the case? > > As far as I am aware the two views must use different keys, with the same > IP the key (or the view's ACL) is the only thing to distinguish between the > views. > > You can use the same IP for both views at least on the master, I have that > setup and have for a very long time seen it running without any problem. I > do not use keys but let view ACL do the work. > > > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing > listbind-us...@lists.isc.orghttps://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 > ___ 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 with Views: zone transfer refused from master to slave
On 03/07/2019 22.14, Grant Taylor via bind-users wrote: > On 7/3/19 2:04 PM, Lightner, Jeffrey wrote: >> You have to use separate IPs for the separate views on the master and >> the slave. > > I thought you could use different TSIG keys to identify different > zones with a single IP at each end. > > Is that not the case? As far as I am aware the two views must use different keys, with the same IP the key (or the view's ACL) is the only thing to distinguish between the views. You can use the same IP for both views at least on the master, I have that setup and have for a very long time seen it running without any problem. I do not use keys but let view ACL do the work. > > > > > ___ > 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 with Views: zone transfer refused from master to slave
On 7/3/19 2:04 PM, Lightner, Jeffrey wrote: You have to use separate IPs for the separate views on the master and the slave. I thought you could use different TSIG keys to identify different zones with a single IP at each end. Is that not the case? -- 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: Bind 9 with Views: zone transfer refused from master to slave
You have to use separate IPs for the separate views on the master and the slave. Here we just put alias IPs on the primary interfaces and use those for the second view. From: bind-users On Behalf Of Roberto Carna Sent: Wednesday, July 03, 2019 3:21 PM To: ML BIND Users Subject: Bind 9 with Views: zone transfer refused from master to slave Hi people, I have a master/slave Bind 9.10.3 servers configured with views and TSIG keys on a Debian 9 host. But the transfer from master to slave is refused in the slave side, there is no a descriptive error. In both Views I have delegated the same two zones: black.com<http://black.com> and white.com<http://white.com>, with different records according to the view. Please if I send my configuration, can you help me to detect the fail in the zone transfer from master to slave??? Thanks a lot in advance. MASTER named.conf: key "rndc-key" { algorithm hmac-md5; secret "+PGWO1r5rrT8hcA47Anu0w=="; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc-key; }; }; include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; named.conf.options: options { directory "/var/cache/bind"; also-notify { 10.0.0.2; }; dnssec-validation no; dnssec-enable yes; auth-nxdomain no; allow-query { any; }; notify explicit; recursion no; version "none"; }; named.conf.local: key one { algorithm HMAC-MD5; secret "uohej/pa1oLBK4Cfhi3zAA=="; }; key two { algorithm HMAC-MD5; secret "HcKSpnKhqg/+KFvOg2uTag=="; }; key three { algorithm HMAC-MD5; secret "1JikGx1kdjq/cTCsi36/JQ=="; }; acl one { !key two; !key three; key one; 10.10.0.0/24<http://10.10.0.0/24>; }; acl two { !key one; !key three; key two; 10.10.1.0/24<http://10.10.1.0/24>; }; acl three { !key one; !key two; key three; 10.10.2.0/24<http://10.10.2.0/24>; }; view "one" { match-clients { one; }; server 10.0.0.2 { keys one; }; recursion yes; allow-transfer { key one; }; zone "black.com<http://black.com>." { type master; file "/etc/bind/zones/black.com.one.db"; also-notify { 10.0.0.2 key one; }; }; zone "white.com<http://white.com>" { type master; file "/etc/bind/zones/white.com.one.db"; also-notify { 10.0.0.2 key one; }; }; }; view "two" { match-clients { two; }; server 10.0.0.2 { keys two; }; recursion yes; allow-transfer { key two; }; zone "black.com<http://black.com>." { type master; file "/etc/bind/zones/black.com.two.db"; also-notify { 10.0.0.2 key one; }; }; zone "white.com<http://white.com>" { type master; file "/etc/bind/zones/white.com.two.db"; also-notify { 10.0.0.2 key one; }; }; }; SLAVE named.conf: include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; named.conf.options: options { directory "/var/cache/bind"; allow-transfer {"none";}; dnssec-validation no; dnssec-enable yes; auth-nxdomain no; allow-query { any; }; notify explicit; recursion no; version "none"; }; named.conf.local: key one { algorithm HMAC-MD5; secret "uohej/pa1oLBK4Cfhi3zAA=="; }; key two { algorithm HMAC-MD5; secret "HcKSpnKhqg/+KFvOg2uTag=="; }; key three { algorithm HMAC-MD5; secret "1JikGx1kdjq/cTCsi36/JQ=="; }; acl one { !key two; !key three; key one; 10.10.0.0/24<http://10.10.0.0/24>; }; acl two { !key one; !key three; key two; 10.10.1.0/24<http://10.10.1.0/24>; }; acl three { !key one; !key two; key three; 10.10.2.0/24<http://10.10.2.0/24>; }; view "one" { match-clients { one; }; server 10.0.0.1 { keys one; }; recursion yes; zone "black.com<http://black.com>" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/black.com.one.db"; }; zone "white.com<http://white.com>" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/white.com.one.db"; }; }; view "two" { match-clients { two; }; server 10.0.0.1 { keys two; }; recursion yes; zone "black.com<http://black.com>" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/black.com.two.db"; }; zone "white.com<http://white.com>" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/white.com.two.db"; }; }; ___ 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 with Views: zone transfer refused from master to slave
Hi people, I have a master/slave Bind 9.10.3 servers configured with views and TSIG keys on a Debian 9 host. But the transfer from master to slave is refused in the slave side, there is no a descriptive error. In both Views I have delegated the same two zones: black.com and white.com, with different records according to the view. Please if I send my configuration, can you help me to detect the fail in the zone transfer from master to slave??? Thanks a lot in advance. MASTER named.conf: key "rndc-key" { algorithm hmac-md5; secret "+PGWO1r5rrT8hcA47Anu0w=="; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc-key; }; }; include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; named.conf.options: options { directory "/var/cache/bind"; also-notify { 10.0.0.2; }; dnssec-validation no; dnssec-enable yes; auth-nxdomain no; allow-query { any; }; notify explicit; recursion no; version "none"; }; named.conf.local: key one { algorithm HMAC-MD5; secret "uohej/pa1oLBK4Cfhi3zAA=="; }; key two { algorithm HMAC-MD5; secret "HcKSpnKhqg/+KFvOg2uTag=="; }; key three { algorithm HMAC-MD5; secret "1JikGx1kdjq/cTCsi36/JQ=="; }; acl one { !key two; !key three; key one; 10.10.0.0/24; }; acl two { !key one; !key three; key two; 10.10.1.0/24; }; acl three { !key one; !key two; key three; 10.10.2.0/24; }; view "one" { match-clients { one; }; server 10.0.0.2 { keys one; }; recursion yes; allow-transfer { key one; }; zone "black.com." { type master; file "/etc/bind/zones/black.com.one.db"; also-notify { 10.0.0.2 key one; }; }; zone "white.com" { type master; file "/etc/bind/zones/white.com.one.db"; also-notify { 10.0.0.2 key one; }; }; }; view "two" { match-clients { two; }; server 10.0.0.2 { keys two; }; recursion yes; allow-transfer { key two; }; zone "black.com." { type master; file "/etc/bind/zones/black.com.two.db"; also-notify { 10.0.0.2 key one; }; }; zone "white.com" { type master; file "/etc/bind/zones/white.com.two.db"; also-notify { 10.0.0.2 key one; }; }; }; SLAVE named.conf: include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; named.conf.options: options { directory "/var/cache/bind"; allow-transfer {"none";}; dnssec-validation no; dnssec-enable yes; auth-nxdomain no; allow-query { any; }; notify explicit; recursion no; version "none"; }; named.conf.local: key one { algorithm HMAC-MD5; secret "uohej/pa1oLBK4Cfhi3zAA=="; }; key two { algorithm HMAC-MD5; secret "HcKSpnKhqg/+KFvOg2uTag=="; }; key three { algorithm HMAC-MD5; secret "1JikGx1kdjq/cTCsi36/JQ=="; }; acl one { !key two; !key three; key one; 10.10.0.0/24; }; acl two { !key one; !key three; key two; 10.10.1.0/24; }; acl three { !key one; !key two; key three; 10.10.2.0/24; }; view "one" { match-clients { one; }; server 10.0.0.1 { keys one; }; recursion yes; zone "black.com" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/black.com.one.db"; }; zone "white.com" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/white.com.one.db"; }; }; view "two" { match-clients { two; }; server 10.0.0.1 { keys two; }; recursion yes; zone "black.com" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/black.com.two.db"; }; zone "white.com" { type slave; masters { 10.0.0.1 key one; }; file "/etc/bind/zones/white.com.two.db"; }; }; ___ 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
Views, Match-Destination, Alternate Ports
Hi, Whilst I've confirmed that notifies can be sent to alternate ports (using masters definitions), I can't seem to mangle BIND to use an alternate port in a view's match-destination configuration item (as it takes an ACL and they don't take ports from what I can read/test). Am I missing something here? Is it not possible to define multiple views with different destination ports? Stuart ___ 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: Common zone file, on multiple views
On 11/12/2018 04:57 AM, Sabri MJAHED (VINC) wrote: Hi all, Hi, I want to have the same zone on multiple views, but i didn't find any solution that ease the use of this. I would think that the zone's "in-view" statement would do what you want. I don't want to make 3 file of zone conf with multiple in-view statements. But it sounds like your problem is that you dislike the overhead of managing the multiple "in-view" statements. Here is the server-fault post with more information : https://serverfault.com/questions/939287/bind-common-zone-on-views-possibilities I might be misunderstanding you, but it seems like the following might work: named.conf --8<-- view "common-zones" { zone "example.com" {…}; zone "example.net" {…}; zone "example.org" {…}; }; view "mordor" { include common-zones.conf; zone "mordor.example" {…}; } view "gondor" { include common-zones.conf; zone "gondor.example" {…}; } view "khand" { include common-zones.conf; zone "khand.example" {…}; } -->8-- common-zones.conf --8<-- zone "example.com" { in-view "common-zones"; }; zone "example.net" { in-view "common-zones"; }; zone "example.org" { in-view "common-zones"; }; -->8-- Note: This is untested and conceptual. The idea being that you define the zones in the "common-zones" view, and then in-view them in the common-zones.conf file. That way any view that includes the common-zones.conf file will include all the in-view(ed) zone definitions. Does this do what you want? I think it keeps you from needing to modify all the zones that include common-zones.conf when you add a zone to the common zones. Which I think is your goal. Thanks a lot. Here's hoping this helps. Good luck and you're welcome. -- 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: Common zone file, on multiple views
Sabri MJAHED (VINC) wrote: > > I dont have the -l option on the named-checkconf command. > > My version of bind is 9.11 Oh, it seems you need 9.12. Your other option is to parse a zone list out of your other config files with a bit of perl, which is what I did previously. Tony. -- f.anthony.n.finchhttp://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression ___ 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: Common zone file, on multiple views
Hi Tony, I dont have the -l option on the named-checkconf command. My version of bind is 9.11 Sabri. On 12/11/2018 13:09, Tony Finch wrote: Sabri MJAHED (VINC) wrote: I want to have the same zone on multiple views, but i didn't find any solution that ease the use of this. I have scripts that generate in-view configurations. In order to make these scripts easier to write, I contributed the `named-checkconf -l` feature which lists the configured zones. e.g. named-checkconf -l | sed ' / IN common slave/!d s// { in-view common; };/ s/^/zone / ' > /etc/bind/in-view.conf Tony. ___ 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: TSIG error with BIND9 Views
Hello Roberto. I have built something similar and used a unique TSIG key for each view. This was required in my case as I use the key to select the View. Dan LeBlanc From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Roberto Carna Sent: November-12-18 12:05 PM To: ML BIND Users Subject: TSIG error with BIND9 Views Hi people, I've implemented a BIND9 service wit two views, and only one key for TSIG. The primary and secondary server start OK, but the transfer doesn't work because in the bind.log from secondary server I can see "TSIG error". Do I have to use one Key for the first view and a different Key for the second view for TSIG transfer ? Or can I use just on Key ? Thanks a lot !!! ___ 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
TSIG error with BIND9 Views
Hi people, I've implemented a BIND9 service wit two views, and only one key for TSIG. The primary and secondary server start OK, but the transfer doesn't work because in the bind.log from secondary server I can see "TSIG error". Do I have to use one Key for the first view and a different Key for the second view for TSIG transfer ? Or can I use just on Key ? Thanks a lot !!! ___ 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: Common zone file, on multiple views
Sabri MJAHED (VINC) wrote: > I want to have the same zone on multiple views, but i didn't find any solution > that ease the use of this. I have scripts that generate in-view configurations. In order to make these scripts easier to write, I contributed the `named-checkconf -l` feature which lists the configured zones. e.g. named-checkconf -l | sed ' / IN common slave/!d s// { in-view common; };/ s/^/zone / ' > /etc/bind/in-view.conf Tony. -- f.anthony.n.finchhttp://dotat.at/ oppose all forms of entrenched privilege and inequality ___ 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
Common zone file, on multiple views
Hi all, I've been working with bind for a bit of time, but here is a new problem. I want to have the same zone on multiple views, but i didn't find any solution that ease the use of this. I don't want to make 3 file of zone conf with multiple in-view statements. Here is the server-fault post with more information : https://serverfault.com/questions/939287/bind-common-zone-on-views-possibilities Thanks a lot. Sabri ___ 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] zone transfer issue with multiple views
Okay, I followed exactly like this - https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html And it just worked. So I can do fine-tune now. Thanks guys. Eoin From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Eoin Kim Sent: Saturday, 9 December 2017 12:00 PM To: Matthew Pounsett Cc: bind-users@lists.isc.org Subject: Re: [Question] zone transfer issue with multiple views Thanks guys. Let me play a bit and see how it goes. Cheers. Eoin From: Matthew Pounsett mailto:m...@conundrum.com>> Sent: Saturday, 9 December 2017 9:29 AM To: Eoin Kim Cc: Lightner, Jeffrey; bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: Re: [Question] zone transfer issue with multiple views On 8 December 2017 at 17:37, Eoin Kim mailto:eoin@rcst.com.au>> wrote: Hi, Thanks for your help. But is it possible to do it without additional IP address? I thought that I am not really bad with BIND but as soon as I started using views, I'm going nowhere [😊] In order for the slave's View A to transfer from the master's View A, and the slave's View B to transfer from the master's view B, there has to be some way for the master to differentiate the two views on the slave and answer their queries from the correct view. Source IP address is the typical way to do that. You could probably select on source port instead, by setting the slave's transfer-source to a particular port for each view. I've never set this up myself, but I just checked the ARM and it looks like you can use any legal address_match_list in the view's match-clients list, so you could also select on TSIG key used, if you assign per-view TSIG keys. ___ 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] zone transfer issue with multiple views
Thanks guys. Let me play a bit and see how it goes. Cheers. Eoin From: Matthew Pounsett Sent: Saturday, 9 December 2017 9:29 AM To: Eoin Kim Cc: Lightner, Jeffrey; bind-users@lists.isc.org Subject: Re: [Question] zone transfer issue with multiple views On 8 December 2017 at 17:37, Eoin Kim mailto:eoin@rcst.com.au>> wrote: Hi, Thanks for your help. But is it possible to do it without additional IP address? I thought that I am not really bad with BIND but as soon as I started using views, I'm going nowhere [😊] In order for the slave's View A to transfer from the master's View A, and the slave's View B to transfer from the master's view B, there has to be some way for the master to differentiate the two views on the slave and answer their queries from the correct view. Source IP address is the typical way to do that. You could probably select on source port instead, by setting the slave's transfer-source to a particular port for each view. I've never set this up myself, but I just checked the ARM and it looks like you can use any legal address_match_list in the view's match-clients list, so you could also select on TSIG key used, if you assign per-view TSIG keys. ___ 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] zone transfer issue with multiple views
On 8 December 2017 at 17:37, Eoin Kim wrote: > Hi, > > > Thanks for your help. But is it possible to do it without additional IP > address? I thought that I am not really bad with BIND but as soon as I > started using views, I'm going nowhere [image: 😊] > > > In order for the slave's View A to transfer from the master's View A, and the slave's View B to transfer from the master's view B, there has to be some way for the master to differentiate the two views on the slave and answer their queries from the correct view. Source IP address is the typical way to do that. You could probably select on source port instead, by setting the slave's transfer-source to a particular port for each view. I've never set this up myself, but I just checked the ARM and it looks like you can use any legal address_match_list in the view's match-clients list, so you could also select on TSIG key used, if you assign per-view TSIG keys. ___ 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] zone transfer issue with multiple views
Hi, Thanks for your help. But is it possible to do it without additional IP address? I thought that I am not really bad with BIND but as soon as I started using views, I'm going nowhere [😊] I found related links: * https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html (I believe my scenario would be example 3 or 4) * https://kb.isc.org/article/AA-00723/0 (Because I really want to use TSIG) Do I have to use a tarball from ISC to do this? Debian's BIND has a version of 9.9.5 so version-wise, it looks alright to me. Thanks again. Eoin From: Lightner, Jeffrey Sent: Friday, 8 December 2017 11:38 PM To: Lightner, Jeffrey; Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views Sorry that 10.0.9.9 should be 10.9.9.9 – i.e. notify-source and transfer-source are the same IP within the same view. From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Lightner, Jeffrey Sent: Friday, December 08, 2017 8:34 AM To: Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; …then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; …then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master – you’d have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic – eth1 is used for internal including zone transfers) ___ 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] zone transfer issue with multiple views
Sorry that 10.0.9.9 should be 10.9.9.9 - i.e. notify-source and transfer-source are the same IP within the same view. From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Lightner, Jeffrey Sent: Friday, December 08, 2017 8:34 AM To: Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; ...then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; ...then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master - you'd have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic - eth1 is used for internal including zone transfers) ___ 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] zone transfer issue with multiple views
When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; ...then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; ...then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master - you'd have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic - eth1 is used for internal including zone transfers) From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Eoin Kim Sent: Thursday, December 07, 2017 8:05 PM To: bind-users@lists.isc.org Subject: [Question] zone transfer issue with multiple views Hi all, I wonder if anyone can help me find the cause of the problem I am currently having. I am testing BIND with two views - internal, external. Everything seems okay except for one thing - zone transfer doesn't look happening for reverse zone for external view. On my slave server, I can see the following log message: 08-Dec-2017 10:55:59.247 general: info: zone 0.20.172.in-addr.arpa/IN/external: refresh: unexpected rcode (NXDOMAIN) from master 192.168.0.7#53 (source 0.0.0.0#0) Servers are using TSIG for zone transfer. It looks like zone transfer itself working for all other zones except for reverse zone for external view. Could I please get help if possible? I am using Debian Jessie and BIND was installed from its repository. I am willing to post BIND configurations if needed. Thanks a lot. Eoin Kim Systems Administrator RCS Telecommunications Level 1 - The Annexe 133 Mary Street Brisbane, QLD, 4000 Office: 07 3228 0843 Mobile: 0419 726 231 [RCST logo drop shadow] ___ 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
[Question] zone transfer issue with multiple views
Hi all, I wonder if anyone can help me find the cause of the problem I am currently having. I am testing BIND with two views - internal, external. Everything seems okay except for one thing - zone transfer doesn't look happening for reverse zone for external view. On my slave server, I can see the following log message: 08-Dec-2017 10:55:59.247 general: info: zone 0.20.172.in-addr.arpa/IN/external: refresh: unexpected rcode (NXDOMAIN) from master 192.168.0.7#53 (source 0.0.0.0#0) Servers are using TSIG for zone transfer. It looks like zone transfer itself working for all other zones except for reverse zone for external view. Could I please get help if possible? I am using Debian Jessie and BIND was installed from its repository. I am willing to post BIND configurations if needed. Thanks a lot. Eoin Kim Systems Administrator RCS Telecommunications Level 1 - The Annexe 133 Mary Street Brisbane, QLD, 4000 Office: 07 3228 0843 Mobile: 0419 726 231 [RCST logo drop shadow] ___ 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: head scratcher: nsupdate, Bind views, and TLSA record updates
I think it's sorted, thanks all. -Kevin From: "Tony Finch" To: bind-us...@isc.org Sent: Wednesday, November 1, 2017 2:50:32 AM Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates Mark Andrews wrote: > > More correctly _tcp.mail.thesandiegos.com is delegated to > ns1._tcp.mail.thesandiegos.com (75.149.33.153) but the machine is > not configured to serve that zone. This also explains the puzzling check-names problem earlier - ns1._tcp.mail.thesandiegos.com is a host name (because it is the target of an NS record) but underscores are not allowed in hostnames. This restriction does not apply to TLSA records. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Rockall, Malin: West or southwest, veering north or northwest, 4 or 5, occasionally 6 at first, becoming variable 3 or 4 later. Slight or moderate, occasionally rough in north Rockall. Occasional rain at first. 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 ___ 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: head scratcher: nsupdate, Bind views, and TLSA record updates
Mark Andrews wrote: > > More correctly _tcp.mail.thesandiegos.com is delegated to > ns1._tcp.mail.thesandiegos.com (75.149.33.153) but the machine is > not configured to serve that zone. This also explains the puzzling check-names problem earlier - ns1._tcp.mail.thesandiegos.com is a host name (because it is the target of an NS record) but underscores are not allowed in hostnames. This restriction does not apply to TLSA records. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Rockall, Malin: West or southwest, veering north or northwest, 4 or 5, occasionally 6 at first, becoming variable 3 or 4 later. Slight or moderate, occasionally rough in north Rockall. Occasional rain at first. 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: head scratcher: nsupdate, Bind views, and TLSA record updates
In message <1509508757.25100.19.ca...@ns.five-ten-sg.com>, Carl Byington writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Tue, 2017-10-31 at 17:16 -0700, Kevin via bind-users wrote: > > $ dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 +dnssec > > +short > > > > > I'm really at a loss as to what's going on inside of Bind. > > dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 > > ;; AUTHORITY SECTION: > _tcp.mail.thesandiegos.com. 3600 IN NS ns1._tcp.mail.thesandiegos.com. > > ;; ADDITIONAL SECTION: > ns1._tcp.mail.thesandiegos.com. 3600 IN A 75.149.33.153 > > > It looks like you have another intermediate zone, but it might not be > delegated properly. More correctly _tcp.mail.thesandiegos.com is delegated to ns1._tcp.mail.thesandiegos.com (75.149.33.153) but the machine is not configured to serve that zone. Kevin, Unless you have good reason to have a delegation for _tcp.mail.thesandiegos.com I would remove it. If you do have a reason to have it then you need to add the zone and add a secure delegation to it. Remember nsupdate can add records for names that are below a zone cut. This is necessary to add glue records. These records are hidden until the zone cut is removed. This is why 123.testtlsa.mail.thesandiegos.com is visible to the world (no zone cut) but _25._tcp.mail.thesandiegos.com isn't (zone cut at _tcp.mail.thesandiegos.com). server 1.2.3.4 zone thesandiegos.com key updatekey xyz123... add 123.testtlsa.mail.thesandiegos.com. 3600 IN TLSA 3 1 1 abc123... add _25._tcp.mail.thesandiegos.com. 3600 IN TLSA 3 1 1 abc123... local 127.0.0.1 show send Mark > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAln5RnoACgkQL6j7milTFsGkmACfdJpGYx5XXSBE9Ibxp7YunJMC > 1Q0An1jrE9g5nxurHZwt4f4DIp5d9a9V > =OjOR > -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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: head scratcher: nsupdate, Bind views, and TLSA record updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2017-10-31 at 17:16 -0700, Kevin via bind-users wrote: > $ dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 +dnssec > +short > > I'm really at a loss as to what's going on inside of Bind. dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 ;; AUTHORITY SECTION: _tcp.mail.thesandiegos.com. 3600 IN NS ns1._tcp.mail.thesandiegos.com. ;; ADDITIONAL SECTION: ns1._tcp.mail.thesandiegos.com. 3600 IN A 75.149.33.153 It looks like you have another intermediate zone, but it might not be delegated properly. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAln5RnoACgkQL6j7milTFsGkmACfdJpGYx5XXSBE9Ibxp7YunJMC 1Q0An1jrE9g5nxurHZwt4f4DIp5d9a9V =OjOR -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: head scratcher: nsupdate, Bind views, and TLSA record updates
- Original Message - > From: "Warren Kumari" > To: "Kevin" > Cc: "bind-users" > Sent: Tuesday, October 31, 2017 12:47:06 PM > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > So, can you confirm that you are not getting SERVFAIL? > > You really haven't provided enough information (like the actual > domains!) for people to be able to help you. > W Google's DNS servers are returning SERVFAIL, but think this is incorrect. Querying from other off-network locations shows NOERROR. To de-obfuscate replace example.com with thesandiegos.com. To further illustrate the issue, when I run the following nsupdate: server 1.2.3.4 zone thesandiegos.com key updatekey xyz123... add 123.testtlsa.mail.thesandiegos.com. 3600 IN TLSA 3 1 1 abc123... add _25._tcp.mail.thesandiegos.com. 3600 IN TLSA 3 1 1 abc123... local 127.0.0.1 show send The TLSA record 123.testtlsa.mail.thesandiegos.com resolves fine from off-network locations. $ dig TLSA 123.testtlsa.mail.thesandiegos.com @75.149.33.153 +dnssec +short 3 1 1 E273FDF3D76928F59A11BBD2FB147114A4EE65D3300EAC3945E6B8A8 44079D5F TLSA 5 5 3600 20171201000743 20171031230743 20103 thesandiegos.com. Leww2La3lbRwChFiTHy6aps6s2tPv5/5490j8owKo1/edq/dGEp4dLSM j6oeEgyKpemm3CGdNIpTU3iAEHbusgYAe2vB/lJUkH6ZRfP8gvu517Yi HRD0tlnpGC2lZav0xf7YL+S+G5w1HCyN6RoZHFswpMP+FVjPZKyIGsUU ooU= The TLSA record _25._tcp.mail.thesandiegos.com does not. $ dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 +dnssec +short I'm really at a loss as to what's going on inside of Bind. -Kevin > > On Tue, Oct 31, 2017 at 3:39 PM, Kevin via bind-users > wrote: >> >> >> - Original Message - >>> From: "Kevin" >>> To: "Kevin" >>> Cc: "Warren Kumari" , "bind-users" >>> >>> Sent: Tuesday, October 31, 2017 12:33:56 PM >>> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates >> >>> - Original Message - >>> > From: "Kevin" >>> > To: "Warren Kumari" >>>> Cc: "Kevin" , "bind-users" >>> > >>> > Sent: Tuesday, October 31, 2017 12:18:41 PM >>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates >> >>> > From: "Warren Kumari" >>> > To: "Kevin" >>> > Cc: "bind-users" >>> > Sent: Tuesday, October 31, 2017 11:28:58 AM >>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates >> >>> > On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users >>> > wrote: >>> >> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a >>> >> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash >>> >> script that executes the following nsupdate batch commands which are >>> >> directed to a Bind "view" that is accessible from the wider internet: >> >>> >> server 1.2.3.4 >>> >> zone example.com >>> >> key updatekey xyz123... >>> >> update delete _25._tcp.mail.example.com. TLSA >>> >> local 127.0.0.1 >>> >> show >>> >> send >> >>> >> And then: >>> >> server 1.2.3.4 >>> >> zone example.com >>> >> key updatekey xyz123... >>> >> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... >>> >> local 127.0.0.1 >>> >> show >>> >> send >> >>> >> I get the following output, all looks good: >> >>> >> + Updating DNS 1.2.3.4: for ... ok. >>> >> + Updating DNS 1.2.3.4: for ... ok. >> >>> >> I see the following in /var/log/messages, all looks good (updating the >>> >> view >>> >> named "remote", responsible for answering queries from off-network >>> >> sources): >>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: >>> >> view >>> >> remote: signer "updatekey" approved >>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: >>> >> view >>> >> remote: updating zone 'example.com/IN': deleting rrset at >>> >> '_25._tcp.mail.example.com' TLSA >>> >> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending >>> >> notifies (serial 165) &g
Re: head scratcher: nsupdate, Bind views, and TLSA record updates
So, can you confirm that you are not getting SERVFAIL? You really haven't provided enough information (like the actual domains!) for people to be able to help you. W On Tue, Oct 31, 2017 at 3:39 PM, Kevin via bind-users wrote: > > > - Original Message - >> From: "Kevin" >> To: "Kevin" >> Cc: "Warren Kumari" , "bind-users" >> >> Sent: Tuesday, October 31, 2017 12:33:56 PM >> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > >> - Original Message - >> > From: "Kevin" >> > To: "Warren Kumari" >>> Cc: "Kevin" , "bind-users" >> > >> > Sent: Tuesday, October 31, 2017 12:18:41 PM >> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > >> > From: "Warren Kumari" >> > To: "Kevin" >> > Cc: "bind-users" >> > Sent: Tuesday, October 31, 2017 11:28:58 AM >> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > >> > On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users >> > wrote: >> >> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a >> >> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash >> >> script that executes the following nsupdate batch commands which are >> >> directed to a Bind "view" that is accessible from the wider internet: > >> >> server 1.2.3.4 >> >> zone example.com >> >> key updatekey xyz123... >> >> update delete _25._tcp.mail.example.com. TLSA >> >> local 127.0.0.1 >> >> show >> >> send > >> >> And then: >> >> server 1.2.3.4 >> >> zone example.com >> >> key updatekey xyz123... >> >> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... >> >> local 127.0.0.1 >> >> show >> >> send > >> >> I get the following output, all looks good: > >> >> + Updating DNS 1.2.3.4: for ... ok. >> >> + Updating DNS 1.2.3.4: for ... ok. > >> >> I see the following in /var/log/messages, all looks good (updating the >> >> view >> >> named "remote", responsible for answering queries from off-network >> >> sources): >> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: >> >> view >> >> remote: signer "updatekey" approved >> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: >> >> view >> >> remote: updating zone 'example.com/IN': deleting rrset at >> >> '_25._tcp.mail.example.com' TLSA >> >> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending >> >> notifies (serial 165) >> >> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: >> >> received notify for zone 'example.com' >> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: >> >> view >> >> remote: signer "updatekey" approved >> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: >> >> view >> >> remote: updating zone 'example.com/IN': adding an RR at >> >> '_25._tcp.mail.example.com' TLSA > >> >> But then when I try to do a query from remote, no TLSA record exists. > >> >> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec > >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA >> >> _25._tcp.mail.example.com +dnssec >> >> ; (1 server found) >> >> ;; global options: +cmd >> >> ;; Got answer: >> >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 >> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > >> >> ;; OPT PSEUDOSECTION: >> >> ; EDNS: version: 0, flags: do; udp: 512 >> >> ;; QUESTION SECTION: >> >> ;_25._tcp.mail.example.com. IN TLSA > >> >> ;; Query time: 74 msec >> >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> >> ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 >> >> ;; MSG SIZE rcvd: 59 > >> >> Oct 31 10:33:12 test named[106]: query logging is now on >> >> Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 >> >> (_25._tc
Re: head scratcher: nsupdate, Bind views, and TLSA record updates
- Original Message - > From: "Kevin" > To: "Kevin" > Cc: "Warren Kumari" , "bind-users" > > Sent: Tuesday, October 31, 2017 12:33:56 PM > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > - Original Message - > > From: "Kevin" > > To: "Warren Kumari" >> Cc: "Kevin" , "bind-users" > > > > Sent: Tuesday, October 31, 2017 12:18:41 PM > > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > > From: "Warren Kumari" > > To: "Kevin" > > Cc: "bind-users" > > Sent: Tuesday, October 31, 2017 11:28:58 AM > > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > > On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users > > wrote: > >> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a > >> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash > >> script that executes the following nsupdate batch commands which are > >> directed to a Bind "view" that is accessible from the wider internet: > >> server 1.2.3.4 > >> zone example.com > >> key updatekey xyz123... > >> update delete _25._tcp.mail.example.com. TLSA > >> local 127.0.0.1 > >> show > >> send > >> And then: > >> server 1.2.3.4 > >> zone example.com > >> key updatekey xyz123... > >> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... > >> local 127.0.0.1 > >> show > >> send > >> I get the following output, all looks good: > >> + Updating DNS 1.2.3.4: for ... ok. > >> + Updating DNS 1.2.3.4: for ... ok. > >> I see the following in /var/log/messages, all looks good (updating the view > >> named "remote", responsible for answering queries from off-network > >> sources): > >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > >> remote: signer "updatekey" approved > >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > >> remote: updating zone 'example.com/IN': deleting rrset at > >> '_25._tcp.mail.example.com' TLSA > >> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending > >> notifies (serial 165) > >> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: > >> received notify for zone 'example.com' > >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > >> remote: signer "updatekey" approved > >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > >> remote: updating zone 'example.com/IN': adding an RR at > >> '_25._tcp.mail.example.com' TLSA > >> But then when I try to do a query from remote, no TLSA record exists. > >> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec > >> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA > >> _25._tcp.mail.example.com +dnssec > >> ; (1 server found) > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > >> ;; OPT PSEUDOSECTION: > >> ; EDNS: version: 0, flags: do; udp: 512 > >> ;; QUESTION SECTION: > >> ;_25._tcp.mail.example.com. IN TLSA > >> ;; Query time: 74 msec > >> ;; SERVER: 8.8.8.8#53(8.8.8.8) > >> ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 > >> ;; MSG SIZE rcvd: 59 > >> Oct 31 10:33:12 test named[106]: query logging is now on > >> Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 > >> (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com > >> IN TLSA -ED (1.2.3.4) > >> Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184 > >> (74.165.37.177.in-addr.arpa): view internal: query: > >> 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4) > >> Oct 31 10:33:39 test named[106]: received control channel command > >> 'querylog' > >> I'm at a loss as to what's going on, any ideas? > > You've elided enough stuff that debugging/helping you is really hard, > > but at least one of the issues is that you are getting back SERVFAIL. > > This is almost defeintely a DNSSEC issue -- I'd sugge
Re: head scratcher: nsupdate, Bind views, and TLSA record updates
- Original Message - > From: "Kevin" > To: "Warren Kumari" > Cc: "Kevin" , "bind-users" > > Sent: Tuesday, October 31, 2017 12:18:41 PM > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > From: "Warren Kumari" > To: "Kevin" > Cc: "bind-users" > Sent: Tuesday, October 31, 2017 11:28:58 AM > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates > > On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users > wrote: >> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a >> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash >> script that executes the following nsupdate batch commands which are >> directed to a Bind "view" that is accessible from the wider internet: >> >> server 1.2.3.4 >> zone example.com >> key updatekey xyz123... >> update delete _25._tcp.mail.example.com. TLSA >> local 127.0.0.1 >> show >> send >> >> And then: >> server 1.2.3.4 >> zone example.com >> key updatekey xyz123... >> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... >> local 127.0.0.1 >> show >> send >> >> I get the following output, all looks good: >> >> + Updating DNS 1.2.3.4: for ... ok. >> + Updating DNS 1.2.3.4: for ... ok. >> >> I see the following in /var/log/messages, all looks good (updating the view >> named "remote", responsible for answering queries from off-network sources): >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view >> remote: signer "updatekey" approved >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view >> remote: updating zone 'example.com/IN': deleting rrset at >> '_25._tcp.mail.example.com' TLSA >> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending >> notifies (serial 165) >> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: >> received notify for zone 'example.com' >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view >> remote: signer "updatekey" approved >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view >> remote: updating zone 'example.com/IN': adding an RR at >> '_25._tcp.mail.example.com' TLSA >> >> But then when I try to do a query from remote, no TLSA record exists. >> >> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA >> _25._tcp.mail.example.com +dnssec >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 512 >> ;; QUESTION SECTION: >> ;_25._tcp.mail.example.com. IN TLSA >> >> ;; Query time: 74 msec >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 >> ;; MSG SIZE rcvd: 59 >> >> Oct 31 10:33:12 test named[106]: query logging is now on >> Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 >> (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com >> IN TLSA -ED (1.2.3.4) >> Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184 >> (74.165.37.177.in-addr.arpa): view internal: query: >> 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4) >> Oct 31 10:33:39 test named[106]: received control channel command 'querylog' >> >> I'm at a loss as to what's going on, any ideas? > > You've elided enough stuff that debugging/helping you is really hard, > but at least one of the issues is that you are getting back SERVFAIL. > This is almost defeintely a DNSSEC issue -- I'd suggest looking at > DNSVIZ to fogure out why... > > W > > okay...done. > > After further debugging, it looks like nsupdate (or Bind) doesn't like > underscores (that arrive via nsupdate). If I create a TLSA record using the > same mechanism that doesn't contain underscore characters, all is right with > the world and remote queries work as expected. > > However, given that TLSA records use a common record structure that requires > underscores, this is a problem. > > Am I missing some obscure named.conf setting that needs to be relaxed to allow > underscores in dynamically updated records? > > -Kevin >> I looked and already had "check-names {master|slave|response} ignore;" set at the view level. I next tried setting these options at the global level and there is no change in behavior. -Kevin ___ 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: head scratcher: nsupdate, Bind views, and TLSA record updates
From: "Warren Kumari" To: "Kevin" Cc: "bind-users" Sent: Tuesday, October 31, 2017 11:28:58 AM Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users wrote: > I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a > scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash > script that executes the following nsupdate batch commands which are > directed to a Bind "view" that is accessible from the wider internet: > > server 1.2.3.4 > zone example.com > key updatekey xyz123... > update delete _25._tcp.mail.example.com. TLSA > local 127.0.0.1 > show > send > > And then: > server 1.2.3.4 > zone example.com > key updatekey xyz123... > update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... > local 127.0.0.1 > show > send > > I get the following output, all looks good: > > + Updating DNS 1.2.3.4: for ... ok. > + Updating DNS 1.2.3.4: for ... ok. > > I see the following in /var/log/messages, all looks good (updating the view > named "remote", responsible for answering queries from off-network sources): > Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > remote: signer "updatekey" approved > Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > remote: updating zone 'example.com/IN': deleting rrset at > '_25._tcp.mail.example.com' TLSA > Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending > notifies (serial 165) > Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: > received notify for zone 'example.com' > Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > remote: signer "updatekey" approved > Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > remote: updating zone 'example.com/IN': adding an RR at > '_25._tcp.mail.example.com' TLSA > > But then when I try to do a query from remote, no TLSA record exists. > > $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec > > ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA > _25._tcp.mail.example.com +dnssec > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;_25._tcp.mail.example.com. IN TLSA > > ;; Query time: 74 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 > ;; MSG SIZE rcvd: 59 > > Oct 31 10:33:12 test named[106]: query logging is now on > Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 > (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com > IN TLSA -ED (1.2.3.4) > Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184 > (74.165.37.177.in-addr.arpa): view internal: query: > 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4) > Oct 31 10:33:39 test named[106]: received control channel command 'querylog' > > I'm at a loss as to what's going on, any ideas? You've elided enough stuff that debugging/helping you is really hard, but at least one of the issues is that you are getting back SERVFAIL. This is almost defeintely a DNSSEC issue -- I'd suggest looking at DNSVIZ to fogure out why... W okay...done. After further debugging, it looks like nsupdate (or Bind) doesn't like underscores (that arrive via nsupdate). If I create a TLSA record using the same mechanism that doesn't contain underscore characters, all is right with the world and remote queries work as expected. However, given that TLSA records use a common record structure that requires underscores, this is a problem. Am I missing some obscure named.conf setting that needs to be relaxed to allow underscores in dynamically updated records? -Kevin > > -Kevin > > > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf - Or
Re: head scratcher: nsupdate, Bind views, and TLSA record updates
On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users wrote: > I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a > scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash > script that executes the following nsupdate batch commands which are > directed to a Bind "view" that is accessible from the wider internet: > > server 1.2.3.4 > zone example.com > key updatekey xyz123... > update delete _25._tcp.mail.example.com. TLSA > local 127.0.0.1 > show > send > > And then: > server 1.2.3.4 > zone example.com > key updatekey xyz123... > update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... > local 127.0.0.1 > show > send > > I get the following output, all looks good: > > + Updating DNS 1.2.3.4: for ... ok. > + Updating DNS 1.2.3.4: for ... ok. > > I see the following in /var/log/messages, all looks good (updating the view > named "remote", responsible for answering queries from off-network sources): > Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > remote: signer "updatekey" approved > Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view > remote: updating zone 'example.com/IN': deleting rrset at > '_25._tcp.mail.example.com' TLSA > Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending > notifies (serial 165) > Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: > received notify for zone 'example.com' > Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > remote: signer "updatekey" approved > Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view > remote: updating zone 'example.com/IN': adding an RR at > '_25._tcp.mail.example.com' TLSA > > But then when I try to do a query from remote, no TLSA record exists. > > $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec > > ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA > _25._tcp.mail.example.com +dnssec > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;_25._tcp.mail.example.com.INTLSA > > ;; Query time: 74 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 > ;; MSG SIZE rcvd: 59 > > Oct 31 10:33:12 test named[106]: query logging is now on > Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 > (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com > IN TLSA -ED (1.2.3.4) > Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184 > (74.165.37.177.in-addr.arpa): view internal: query: > 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4) > Oct 31 10:33:39 test named[106]: received control channel command 'querylog' > > I'm at a loss as to what's going on, any ideas? You've elided enough stuff that debugging/helping you is really hard, but at least one of the issues is that you are getting back SERVFAIL. This is almost defeintely a DNSSEC issue -- I'd suggest looking at DNSVIZ to fogure out why... W > > -Kevin > > > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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
head scratcher: nsupdate, Bind views, and TLSA record updates
I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash script that executes the following nsupdate batch commands which are directed to a Bind "view" that is accessible from the wider internet: server 1.2.3.4 zone example.com key updatekey xyz123... update delete _25._tcp.mail.example.com. TLSA local 127.0.0.1 show send And then: server 1.2.3.4 zone example.com key updatekey xyz123... update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123... local 127.0.0.1 show send I get the following output, all looks good: + Updating DNS 1.2.3.4: for ... ok. + Updating DNS 1.2.3.4: for ... ok. I see the following in /var/log/messages, all looks good (updating the view named "remote", responsible for answering queries from off-network sources): Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view remote: signer "updatekey" approved Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view remote: updating zone 'example.com/IN': deleting rrset at '_25._tcp.mail.example.com' TLSA Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending notifies (serial 165) Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal: received notify for zone 'example.com' Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view remote: signer "updatekey" approved Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view remote: updating zone 'example.com/IN': adding an RR at '_25._tcp.mail.example.com' TLSA But then when I try to do a query from remote, no TLSA record exists. $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;_25._tcp.mail.example.com. IN TLSA ;; Query time: 74 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Oct 31 10:37:02 PDT 2017 ;; MSG SIZE rcvd: 59 Oct 31 10:33:12 test named[106]: query logging is now on Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732 (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com IN TLSA -ED (1.2.3.4) Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184 (74.165.37.177.in-addr.arpa): view internal: query: 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4) Oct 31 10:33:39 test named[106]: received control channel command 'querylog' I'm at a loss as to what's going on, any ideas? -Kevin ___ 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: Experiences with RPZ in multiple views
On Tue, Jul 4, 2017 at 4:10 AM, Matthias Seitz wrote: > Hi, > > after a couple of test runs it looks like that multiple RPZs in multiple > views works fine, example code snippet bellow (for better understanding) > > view "view1" { > ... > > response-policy { > RPZ Feed 1 > RPZ Feed 2 > RPZ Feed 3 > }; }; > > view "view2" { > ... > > response-policy { > RPZ Feed 1 > RPZ Feed 4 > RPZ Feed 5 > }; }; > > Locally the RPZ feeds needs different file name, that it will work. See > also the bind-users post from Tom "BIND-RPZ > and Views" > Does anybody runs RPZ in multiple views in *productive environment* and > do you have any feedback regarding stability, feedback if this runs > smoothly and any other hints? > > Cheers, > Matthias > We use RPZ in two views. In one view the RPZ zones are active (policy given), and in the other view they are logging-only (policy disabled). Departments opt-in to RPZ and we add their subnets to the first view. The second view gives us logs and we can tell departments what would be redirected if they opt-in. -- Bob Harold ___ 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
Experiences with RPZ in multiple views
Hi, after a couple of test runs it looks like that multiple RPZs in multiple views works fine, example code snippet bellow (for better understanding) view "view1" { ... response-policy { RPZ Feed 1 RPZ Feed 2 RPZ Feed 3 }; }; view "view2" { ... response-policy { RPZ Feed 1 RPZ Feed 4 RPZ Feed 5 }; }; Locally the RPZ feeds needs different file name, that it will work. See also the bind-users post from Tom "BIND-RPZ and Views" Does anybody runs RPZ in multiple views in *productive environment* and do you have any feedback regarding stability, feedback if this runs smoothly and any other hints? Cheers, Matthias ___ 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: inline-signing a zone that exists in two views
On Fri, May 19, 2017 at 8:56 AM, Matus UHLAR - fantomas wrote: > Gordon Messmer wrote: >>> > Is it considered best-practice (or just normal) for authoritative >>> > servers to just not use the local server for resolution? >>> >> > On Wed, May 10, 2017 at 5:56 AM, Tony Finch wrote: >> >>> Mine don't :-) >>> >> > On 18.05.17 16:38, Bob Harold wrote: > >> My authoritative servers are non-recursive. They use the same DNS >> resolvers that any other server uses, and not themselves. >> > > this configuration will make your recursive servers provide correct data > when your customers move their domains out without telling you so (which > happend quite often)... > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Very true, and I use that fact when I know a zone is in transition. But most of the time I have stealth slave copies (meaning not listed in NS records) on my resolvers. That is more complicated, and has the problem you mention, which happens often. But it has some advantages: Updates reaching my users more quickly, no waiting for cache timeout on the resolvers (there are still other caches, but it helps) Cache poisoning attacks don't work against my zones on my resolvers, since they are authoritative and not cached. I hope sometime to automate monitoring for zones moving without warning me in advance. -- Bob Harold ___ 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: inline-signing a zone that exists in two views
Gordon Messmer wrote: > Is it considered best-practice (or just normal) for authoritative > servers to just not use the local server for resolution? On Wed, May 10, 2017 at 5:56 AM, Tony Finch wrote: Mine don't :-) On 18.05.17 16:38, Bob Harold wrote: My authoritative servers are non-recursive. They use the same DNS resolvers that any other server uses, and not themselves. this configuration will make your recursive servers provide correct data when your customers move their domains out without telling you so (which happend quite often)... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody ___ 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: inline-signing a zone that exists in two views
On Wed, May 10, 2017 at 5:56 AM, Tony Finch wrote: > Gordon Messmer wrote: > ... > > > Is it considered best-practice (or just normal) for authoritative > > servers to just not use the local server for resolution? > > Mine don't :-) > > Tony. > > My authoritative servers are non-recursive. They use the same DNS resolvers that any other server uses, and not themselves. -- Bob Harold ___ 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: inline-signing a zone that exists in two views
Gordon Messmer wrote: > > I'm happy that it's working, but it seems like it was fairly difficult to get > right. Am I doing an unusual thing? Yes, it is fiddly, and a relatively common problem - which is why in-view was introduced! > Is it considered best-practice (or just normal) for authoritative > servers to just not use the local server for resolution? Mine don't :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Easterly 7 to severe gale 9, increasing storm 10 for a time in far northwest. Slight or moderate, becoming rough or very rough, occasionally high later in far west. Occasional rain. Moderate, 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
Re: inline-signing a zone that exists in two views
On 05/09/2017 03:15 AM, Tony Finch wrote: The classic solution is to make one view a slave of the other. Configure the slave zone with `masters { localhost key my-tsig; };` and configure the master view with `match-clients { key my-tsig; };`. OK, I think I've got this nailed down. I had to move the "public" view so that it was listed first in named.conf. That view previously had no match-client setting, but now is set to "match-clients { key tsig-key; !localhost; 0.0.0.0/0; };" so that it allows access with the key but does not match localhost otherwise (which would result in refusing recursion) but does include the rest of the IPv4 space. The zone in the "local" view is now a slave with "masters { 127.0.0.1 key tsig-key; };" Seems to work. Localhost can look up records in the zone as well as external records. External hosts can get records from the zone, but can't make recursive requests. I'm happy that it's working, but it seems like it was fairly difficult to get right. Am I doing an unusual thing? Is it considered best-practice (or just normal) for authoritative servers to just not use the local server for resolution? Thanks for your help! ___ 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: inline-signing a zone that exists in two views
Gordon Messmer wrote: > On 05/08/2017 03:26 AM, Tony Finch wrote: > > You can't have zones in different views (which sre by implication > > different zones, or different versions of the same zone) pointing to the > > same files on disk, because updates to one version will corrupt the other > > version. > > Even if one of them is treated as read-only? That won't work either because a static master zone won't read the journal so it will be perpetually out of sync with the other version. > > Make the second zone a clone of the first using the in-view option > > instead. > > That looks like the right thing to do, but appears to be available only on > bind 9.10+, and I'm supporting Red Hat servers with 9.9. Are there any > solutions here, or do I need to roll my own packages until Red Hat catches up? The classic solution is to make one view a slave of the other. Configure the slave zone with `masters { localhost key my-tsig; };` and configure the master view with `match-clients { key my-tsig; };`. Another alternative (if one view is recursive) is to use a static-stub zone. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Sole: East 5 or 6. Moderate, occasionally rough in south. Fair. 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: inline-signing a zone that exists in two views
On 05/08/2017 03:26 AM, Tony Finch wrote: Gordon Messmer wrote: I have a zone that I'd like to serve in two different views, with dnssec in both views. You can't have zones in different views (which sre by implication different zones, or different versions of the same zone) pointing to the same files on disk, because updates to one version will corrupt the other version. Even if one of them is treated as read-only? Make the second zone a clone of the first using the in-view option instead. That looks like the right thing to do, but appears to be available only on bind 9.10+, and I'm supporting Red Hat servers with 9.9. Are there any solutions here, or do I need to roll my own packages until Red Hat catches up? Thanks for your help. I really appreciate it. ___ 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: inline-signing a zone that exists in two views
Gordon Messmer wrote: > I have a zone that I'd like to serve in two different views, with dnssec in > both views. You can't have zones in different views (which sre by implication different zones, or different versions of the same zone) pointing to the same files on disk, because updates to one version will corrupt the other version. Make the second zone a clone of the first using the in-view option instead. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Humber, Thames, Dover: North 5 or 6, decreasing 4 at times later. Moderate, occasionally rough. Mainly fair. Mainly 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
inline-signing a zone that exists in two views
I have a zone that I'd like to serve in two different views, with dnssec in both views. However, this leads to a pair of error messages: named[858]: malformed transaction: dynamic/db.dragonsdawn.net.signed.jnl last serial 2017011485 != transaction first serial 2017011477 named[858]: zone dragonsdawn.net/IN/local_resolver (signed): zone_resigninc:dns_journal_write_transaction -> unexpected error Is it possible to serve a second view, using the keys that are maintained in the primary view? This might be mostly for curiosity's sake, since the value of signed responses is reasonably low for "local" clients. view local_resolver { ... zone "dragonsdawn.net" IN { type master; file "dynamic/db.dragonsdawn.net"; update-policy local; key-directory "keys/dragonsdawn.net"; inline-signing yes; auto-dnssec allow; }; }; view public { recursion no; ... zone "dragonsdawn.net" IN { type master; file "dynamic/db.dragonsdawn.net"; update-policy local; key-directory "keys/dragonsdawn.net"; inline-signing yes; auto-dnssec maintain; }; }; ___ 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: views
On 04/19/2017 10:58 AM, Victoria Risk wrote: We have implemented ECS for recursive queries in 9.10.5-S, the subscriber preview edition of BIND, which will be released today. For now, ECS recursion is available only to users with a support contract with ISC. Development of this feature was a significant effort, sponsored by an OEM user of BIND. As part of the agreement with the sponsor, we agreed to embargo the feature from the open source until 2018. Despite possibly selfishly not liking having to wait, I do completely understand and support what was done. Thank you. I look forward to the EDNS0 Client Subnet feature coming to open source in 2018. :-) -- 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: views
> On Apr 19, 2017, at 8:47 AM, Nico CARTRON wrote: > >> Nor did I see >> details on how to have BIND send ECS with queries when it's a recursive >> server. > > As far as I know, ECS for Recursive queries is not yet implemented by ISC, or > at least it is not publicly available. We have implemented ECS for recursive queries in 9.10.5-S, the subscriber preview edition of BIND, which will be released today. For now, ECS recursion is available only to users with a support contract with ISC. Development of this feature was a significant effort, sponsored by an OEM user of BIND. As part of the agreement with the sponsor, we agreed to embargo the feature from the open source until 2018. Victoria Risk Internet Systems Consortium vi...@isc.org 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: views
On 04/19/2017 09:49 AM, Nico CARTRON wrote: Of course I meant +subnet / +nosubnet ;-) Thank you for the pointers Nico & Tony. I'm sure I'll find a way to get myself into trouble with what you've provided. -- 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: views
On 19-Apr-2017 16:47 BST, wrote: > On 19-Apr-2017 15:59 BST, wrote: > [...] > > I'd also like to see if it's possible to have dig send ECS info. > > +edns / +noedns , but you'll need a recent dig version. Of course I meant +subnet / +nosubnet -- Nico ___ 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: views
Hi Grant, On 19-Apr-2017 15:59 BST, wrote: > On 04/19/2017 03:37 AM, Tony Finch wrote: > > This is what the EDNS client subnet option is about. You can use it in > > BIND by adding "ecs" clauses to your address match lists for views or > > acls. However it isn't documented in the ARM and it has significant > > problems. See > > https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html > > and especially > > https://kb.isc.org/article/AA-01480/0/BIND-9.11.1rc3-Release-Notes.html > > The only occurrences I found for "ecs" on the two release notes didn't > include more details about how to configure views to use it. As pointed out by Tony, it is not document in the ARM, so you need to dig a little bit :) Googling a little, you'll find things such as: acl ecs-area01 { ecs 192.168.164.0/24; } acl no-ecs-area01 { 192.168.164.0/24; }; and then you can use these ACLs as part of your DNS views. > Nor did I see > details on how to have BIND send ECS with queries when it's a recursive > server. As far as I know, ECS for Recursive queries is not yet implemented by ISC, or at least it is not publicly available. > I'd also like to see if it's possible to have dig send ECS info. +edns / +noedns , but you'll need a recent dig version. Cheers, -- Nico ___ 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: views
Grant Taylor via bind-users wrote: > > The only occurrences I found for "ecs" on the two release notes didn't > include more details about how to configure views to use it. Yes, it's a bit mysterious. > Nor did I see details on how to have BIND send ECS with queries when > it's a recursive server. The 9.11.0 release notes say "supported for authoritative servers" which is meant to imply that named can't send ECS queries. (ECS has difficult implications for DNS caches.) > I'd also like to see if it's possible to have dig send ECS info. See the +subnet option in `dig -h` and the man page https://ftp.isc.org/isc/bind9/9.11.0/doc/arm/man.dig.html Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Variable 3 or 4. Smooth or slight, occasionally moderate later in southwest Fastnet. Fair. 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: views
On 04/19/2017 03:37 AM, Tony Finch wrote: This is what the EDNS client subnet option is about. You can use it in BIND by adding "ecs" clauses to your address match lists for views or acls. However it isn't documented in the ARM and it has significant problems. See https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html and especially https://kb.isc.org/article/AA-01480/0/BIND-9.11.1rc3-Release-Notes.html The only occurrences I found for "ecs" on the two release notes didn't include more details about how to configure views to use it. Nor did I see details on how to have BIND send ECS with queries when it's a recursive server. I'd also like to see if it's possible to have dig send ECS info. -- 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: views
I understand the concept, but I'm not sure I fully understand how to configure it. I've updated my bind to 9.11 P05 compiled with "--with-ecdsa", and as far as I can read EDNS is enabled for authoritative bind installations automatically. But I'm still getting wrong answers from my installation. Here are my configurations: named.conf: options { listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-recursion { internal; }; allow-query { any; }; allow-query-cache { none; }; }; acl internal { service_server_subnet/24; service_server_wan_ip; }; view "internal" { match-clients { internal; }; zone "example.net" IN { type master; file "/etc/named/example.net.internal"; }; }; view "external" { match-clients { any; }; zone "example.net" IN { type master; file "/etc/named/example.net.external"; }; }; example.net.external: $TTL 3600 example.net. IN SOA ns1.example.net. example.net. ( 2001062501 21600 3600 604800 3600 ) example.net. IN NS ns1.example.net. example.net. IN NS ns2.example.net. example.net. IN MX 10 mx.zoho.com. example.net. IN MX 20 mx2.zoho.com. ns1.example.net. IN A bind_wan_ip ns2.example.net. IN A bind_wan_ip example.net. IN A service_server_wan_ip www.example.net. IN CNAME example.net. mail.example.net. IN A service_server_wan_ip mail.example.net. IN MX 10 mail.example.net. mail.example.net. IN SPF "v=spf1 +a +mx +include:mail.example.net -all" service.example.net. IN A service_server_wan_ip example.net.internal: $TTL 3600 example.net. IN SOA ns1.example.net. example.net. ( 2001062501 21600 3600 604800 3600 ) example.net. IN NS ns1.example.net. example.net. IN NS ns2.example.net. example.net. IN MX 10 mx.zoho.com. example.net. IN MX 20 mx2.zoho.com. ns1.example.net. IN A bind_wan_ip ns2.example.net. IN A bind_wan_ip example.net. IN A service_server_lan_ip www.example.net. IN CNAME example.net. mail.example.net. IN A service_server_lan_ip mail.example.net. IN MX 10 mail.example.net. mail.example.net. IN SPF "v=spf1 +a +mx +include:mail.example.net -all" service.example.net. IN A service_server_wan_ip When I dig my subdomain however I get this replies: # dig +noall +answer service.example.net @ns1.example.net service.example.net.3600INAservice_server_lan_ip # dig +noall +answer service.example.net @8.8.8.8 service.example.net.3599INAservice_server_wan_ip Can you spot anything wrong with it? Thanks On 19 April 2017 at 09:37, Tony Finch wrote: > Alberto Rinaudo wrote: > > > I have a bind installation on a aws server and I'm trying to set up views > > to give different responses based on the source location. > > > > It works fine when this dns server is the first dns used by a client, I > > guess because the source address used to discriminate between views is > the > > last hop. > > > > If the query goes first to google dns instead I end up in the wrong view. > > > > So here's the question: is it possible to use the original source address > > to chose the view? > > This is what the EDNS client subnet option is about. You can use it in > BIND by adding "ecs" clauses to your address match lists for views or > acls. However it isn't documented in the ARM and it has significant > problems. See > https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html > and especially > https://kb.isc.org/article/AA-01480/0/BIND-9.11.1rc3-Release-Notes.html > > EDNS client subnet specification: > https://tools.ietf.org/html/rfc7871 > > Google Public DNS support for ECS on authoritative servers: > https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Viking, North Utsire: Southwesterly 5 or 6, decreasing 4 at times. Slight > or > moderate. Rain at times. 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
Re: views
Alberto Rinaudo wrote: > I have a bind installation on a aws server and I'm trying to set up views > to give different responses based on the source location. > > It works fine when this dns server is the first dns used by a client, I > guess because the source address used to discriminate between views is the > last hop. > > If the query goes first to google dns instead I end up in the wrong view. > > So here's the question: is it possible to use the original source address > to chose the view? This is what the EDNS client subnet option is about. You can use it in BIND by adding "ecs" clauses to your address match lists for views or acls. However it isn't documented in the ARM and it has significant problems. See https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html and especially https://kb.isc.org/article/AA-01480/0/BIND-9.11.1rc3-Release-Notes.html EDNS client subnet specification: https://tools.ietf.org/html/rfc7871 Google Public DNS support for ECS on authoritative servers: https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Viking, North Utsire: Southwesterly 5 or 6, decreasing 4 at times. Slight or moderate. Rain at times. 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