How to use different views on DNS-over-HTTPS vs normal DNS on port 53

[r1wcp42w--- via bind-users]

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?

[Ubence Quevedo]

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 be put on the lab.domain.com system so that when they are
>> rep

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules via bind-users]

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 logs for what got transferred.
>>
>> I don't und

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Grant Taylor via bind-users]

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?

[Ubence Quevedo]

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
> etc...
>
> zone "net5.domain.com" {
> # 10.

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules via bind-users]

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" {
> type master;
> forwarders {};
>  

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Sten Carlsen]

> 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 
> started only retur

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Ubence Quevedo]

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, in a
> previous job,

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Matus UHLAR - fantomas]

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?

[Greg Choules via bind-users]

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.
>
>
> My question is, is there any way to "p

Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Ubence Quevedo]

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

[Nick Tait via bind-users]

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

[Matthijs Mekking]

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

[Carsten Strotmann via bind-users]

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

[Greg Choules via bind-users]

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

[E R]

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

[Josef Vybíhal]

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;
> >  key-directory 

Re: DNSSEC signing common zone in views

[Matthijs Mekking]

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

[Josef Vybíhal]

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

[Tony Finch]

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

[Jiri Hromadka]

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

[Dean Gibson (DNS Administrator)]

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

[Mark Andrews]

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

[Dean Gibson (DNS Administrator)]

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

[Matthijs Mekking]

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

[Graham Clinch]

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

[Grant Taylor via bind-users]

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

[Bob Harold]

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

[Tony Finch]

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

[Brian J. Murrell]

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

[Roberto Carna]

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

[Matus UHLAR - fantomas]

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

[Roberto Carna]

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

[Roberto Carna]

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

[Tony Finch]

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]

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

[Sten Carlsen]

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

[Grant Taylor via bind-users]

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

[Lightner, Jeffrey]

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

[Roberto Carna]

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

[Browne, Stuart via bind-users]

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

[Grant Taylor via bind-users]

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

[Tony Finch]

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

[Sabri MJAHED (VINC)]

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

[LeBlanc, Daniel James]

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

[Roberto Carna]

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

[Tony Finch]

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

[Sabri MJAHED (VINC)]

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

[Eoin Kim]

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 <m...@conundrum.com>
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 <m...@conundrum.com<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 
<eoin@rcst.com.au<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

[Eoin Kim]

Thanks guys. Let me play a bit and see how it goes. Cheers.


Eoin



From: Matthew Pounsett <m...@conundrum.com>
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 
<eoin@rcst.com.au<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

[Matthew Pounsett]

On 8 December 2017 at 17:37, Eoin Kim <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 [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

[Eoin Kim]

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 <jlight...@dsservices.com>
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

[Lightner, Jeffrey]

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

[Eoin Kim]

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

[Kevin via bind-users]

I think it's sorted, thanks all. 

-Kevin 



From: "Tony Finch" <d...@dotat.at> 
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 <ma...@isc.org> 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 <d...@dotat.at> 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

[Tony Finch]

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

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Mark Andrews]

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

[Carl Byington]

-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

[Kevin via bind-users]

- Original Message -
> From: "Warren Kumari" <war...@kumari.net>
> To: "Kevin" <bind-users...@thesandiegos.com>
> Cc: "bind-users" <bind-users@lists.isc.org>
> 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
> <bind-users@lists.isc.org> wrote:
>> 
>> 
>> - Original Message -
>>> From: "Kevin" <bind-users...@thesandiegos.com>
>>> To: "Kevin" <bind-users...@thesandiegos.com>
>>> Cc: "Warren Kumari" <war...@kumari.net>, "bind-users" 
>>> <bind-users@lists.isc.org>
>>> Sent: Tuesday, October 31, 2017 12:33:56 PM
>>> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>> 
>>> - Original Message -
>>> > From: "Kevin" <bind-users...@thesandiegos.com>
>>> > To: "Warren Kumari" <war...@kumari.net>
>>>> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users"
>>> > <bind-users@lists.isc.org>
>>> > Sent: Tuesday, October 31, 2017 12:18:41 PM
>>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>> 
>>> > From: "Warren Kumari" <war...@kumari.net>
>>> > To: "Kevin" <bind-users...@thesandiegos.com>
>>> > Cc: "bind-users" <bind-users@lists.isc.org>
>>> > 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
>>> > <bind-users@lists.isc.org> 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
>>

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Warren Kumari]

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
<bind-users@lists.isc.org> wrote:
>
>
> - Original Message -
>> From: "Kevin" <bind-users...@thesandiegos.com>
>> To: "Kevin" <bind-users...@thesandiegos.com>
>> Cc: "Warren Kumari" <war...@kumari.net>, "bind-users" 
>> <bind-users@lists.isc.org>
>> Sent: Tuesday, October 31, 2017 12:33:56 PM
>> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> - Original Message -
>> > From: "Kevin" <bind-users...@thesandiegos.com>
>> > To: "Warren Kumari" <war...@kumari.net>
>>> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users"
>> > <bind-users@lists.isc.org>
>> > Sent: Tuesday, October 31, 2017 12:18:41 PM
>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> > From: "Warren Kumari" <war...@kumari.net>
>> > To: "Kevin" <bind-users...@thesandiegos.com>
>> > Cc: "bind-users" <bind-users@lists.isc.org>
>> > 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
>> > <bind-users@lists.isc.org> 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
>
>> >> ;; Q

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Kevin via bind-users]

- Original Message -
> From: "Kevin" <bind-users...@thesandiegos.com>
> To: "Kevin" <bind-users...@thesandiegos.com>
> Cc: "Warren Kumari" <war...@kumari.net>, "bind-users" 
> <bind-users@lists.isc.org>
> Sent: Tuesday, October 31, 2017 12:33:56 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates

> - Original Message -
> > From: "Kevin" <bind-users...@thesandiegos.com>
> > To: "Warren Kumari" <war...@kumari.net>
>> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users"
> > <bind-users@lists.isc.org>
> > Sent: Tuesday, October 31, 2017 12:18:41 PM
> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates

> > From: "Warren Kumari" <war...@kumari.net>
> > To: "Kevin" <bind-users...@thesandiegos.com>
> > Cc: "bind-users" <bind-users@lists.isc.org>
> > 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
> > <bind-users@lists.isc.org> 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 
> >> 'que

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Kevin via bind-users]

- Original Message -
> From: "Kevin" <bind-users...@thesandiegos.com>
> To: "Warren Kumari" <war...@kumari.net>
> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users" 
> <bind-users@lists.isc.org>
> Sent: Tuesday, October 31, 2017 12:18:41 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates

> From: "Warren Kumari" <war...@kumari.net>
> To: "Kevin" <bind-users...@thesandiegos.com>
> Cc: "bind-users" <bind-users@lists.isc.org>
> 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
> <bind-users@lists.isc.org> 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

[Kevin via bind-users]

From: "Warren Kumari" <war...@kumari.net> 
To: "Kevin" <bind-users...@thesandiegos.com> 
Cc: "bind-users" <bind-users@lists.isc.org> 
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 
<bind-users@lists.isc.org> 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

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Warren Kumari]

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

[Kevin via bind-users]

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

[Bob Harold]

On Tue, Jul 4, 2017 at 4:10 AM, Matthias Seitz <matthias.se...@switch.ch>
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 <tomtux...@gmail.com> "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

[Matthias Seitz]

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 <tomtux...@gmail.com> "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

[Bob Harold]

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

[Matus UHLAR - fantomas]

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

[Bob Harold]

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

[Tony Finch]

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.finch    http://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

[Gordon Messmer]

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

[Tony Finch]

Gordon Messmer <gordon.mess...@gmail.com> 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.finch  <d...@dotat.at>  http://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

[Gordon Messmer]

On 05/08/2017 03:26 AM, Tony Finch wrote:

Gordon Messmer <gordon.mess...@gmail.com> 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

[Tony Finch]

Gordon Messmer <gordon.mess...@gmail.com> 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.finch  <d...@dotat.at>  http://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

[Gordon Messmer]

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

[Grant Taylor via bind-users]

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

[Victoria Risk]

> 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

[Grant Taylor via bind-users]

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

[Nico CARTRON]

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

[Nico CARTRON]

Hi Grant,

On 19-Apr-2017 15:59 BST, <bind-users@lists.isc.org> 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

[Tony Finch]

Grant Taylor via bind-users <bind-users@lists.isc.org> 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.finch  <d...@dotat.at>  http://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

[Grant Taylor via bind-users]

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

[Alberto Rinaudo]

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 <d...@dotat.at> wrote:

> Alberto Rinaudo <alberto.rina...@gmail.com> 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.finch  <d...@dotat.at>  http://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

[Tony Finch]

Alberto Rinaudo <alberto.rina...@gmail.com> 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.finch  <d...@dotat.at>  http://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

views

[Alberto Rinaudo]

Hello,
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?
Am I looking at the right option or should I use something different than
views?
Thanks
___
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: Master/Slave communication not working if I use HMAC-SHA* algorithms when views are implemented

[Mukund Sivaraman]

Hi Nagesh

On Fri, Oct 14, 2016 at 11:00:24AM +0530, Nagesh Thati wrote:
> Hi,
>
> Can anybody implemented master/slave communication with views and algorithm
> HMAC-SHA* algorithms. I tried with all the HMAC-SHA* algorithms it didn't
> work for me, only HMAC-MD5 algorithm worked for communication. If anybody
> has any idea please help me.
> Thanks.

TCPWave seems to:

(1) Integrate BIND in product/service and benefit commercially from it

(2) Doesn't support upstream BIND's development by purchasing a support
subscription, even though TCPWave seems reliant on BIND being developed
actively

(3) Paints BIND poorly on its webpages, even though your product/service
uses BIND: http://www.tcpwave.com/tcpwave-managed-dns/

(4) Comes to us for help when it is not able to figure out something

The last time this happened, we were reported a memory leak bug in ISC
BIND by TCPWave that we were pushed by TCPWave to prioritize because you
couldn't keep up a server for more than a day. After we spent
considerable engineering time and helped you find the cause, the
reporter admitted that the bug was due to changes that you had made to
BIND. Our engineering team's time was wasted by it.

Ask your management to contact ISC's sales team to buy a support
subscription as it would be better for both organizations:

https://www.isc.org/bind-subscription-2/

(The work we do costs money too. We are programmers, support and QA
engineers who need salaries too.)

Mukund


signature.asc
Description: 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: Master/Slave communication not working if I use HMAC-SHA* algorithms when views are implemented

[Bob Harold]

On Fri, Oct 14, 2016 at 1:30 AM, Nagesh Thati <nagesh.th...@tcpwave.com>
wrote:

> Hi,
>
> Can anybody implemented master/slave communication with views and
> algorithm HMAC-SHA* algorithms. I tried with all the HMAC-SHA* algorithms
> it didn't work for me, only HMAC-MD5 algorithm worked for communication. If
> anybody has any idea please help me.
> Thanks.
>
>
> --
> Thanks,
> Nagesh Thati
>
> That appears to depend on the version of BIND:

The BIND manual for 9.8 says that only HMAC-MD5 can be used for TSIG.

The BIND manual for 9.9 lists HMAC-MD5 and lots of HMAC-SHA* versions.

See "dnssec-keygen" in the appendix.

-- 
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

Master/Slave communication not working if I use HMAC-SHA* algorithms when views are implemented

[Nagesh Thati]

Hi,

Can anybody implemented master/slave communication with views and 
algorithm HMAC-SHA* algorithms. I tried with all the HMAC-SHA* 
algorithms it didn't work for me, only HMAC-MD5 algorithm worked for 
communication. If anybody has any idea please help me.

Thanks.


--
Thanks,
Nagesh Thati

___
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-RPZ and Views

[Tony Finch]

Tom <tomtux...@gmail.com> wrote:
>
> What is the supported/preferred way for implementing slave-rpz's in views?
> I want to achieve, that view1 has a different policy-configuration (passthru,
> given, nxdomain..) than the ones configured in view2 using the same
> slave-rpz-files. If not obligatory, I would not synchronize/transfer the
> slave-zone again...just for the view2.

I believe the only way to do this is to have duplicate copies of RPZ zones
which are used in multiple views.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Humber: Variable 3 or 4. Smooth or slight. Occasional rain. 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

Re: BIND-RPZ and Views

[Tom]

Hi

What is the supported/preferred way for implementing slave-rpz's in views?
I want to achieve, that view1 has a different policy-configuration 
(passthru, given, nxdomain..) than the ones configured in view2 using 
the same slave-rpz-files. If not obligatory, I would not 
synchronize/transfer the slave-zone again...just for the view2.


Thank you.
Tom


On 09/16/2016 12:22 PM, Tony Finch wrote:

Anand Buddhdev <ana...@ripe.net> wrote:


In newer versions of BIND, you cannot share a writable file in different
views. This is a bad configurtion, and newer versions of BIND reject it.
Just use different file names.


To clarify, you couldn't in older versions of BIND either! It would cause
weird data corruption problems.

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: BIND-RPZ and Views

[Tony Finch]

Anand Buddhdev <ana...@ripe.net> wrote:
>
> In newer versions of BIND, you cannot share a writable file in different
> views. This is a bad configurtion, and newer versions of BIND reject it.
> Just use different file names.

To clarify, you couldn't in older versions of BIND either! It would cause
weird data corruption problems.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Faeroes, Southeast Iceland: Southerly or southwesterly 4 or 5, increasing 6 or
7 later, perhaps gale 8 in Southeast Iceland. Moderate or rough, occasionally
very rough later. Showers, rain later. Moderate or good, occasionally poor
later.
___
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-RPZ and Views

[Anand Buddhdev]

On 16/09/16 09:06, Tom wrote:

Hi Tom,

> Using BIND 9.10.4-P2: I've a question about configuring DNS-RPZ and views:
> I configured view1 and view2. After configuring all rpz-zones in both
> views, I had errors like this (slave file in view2 is already in use
> from view1):
> config: error: /etc/named/named.conf:403: writeable file
> 'slave/malware.rpz.spamhaus.org': already in use: /etc/named/named.conf:259

In newer versions of BIND, you cannot share a writable file in different
views. This is a bad configurtion, and newer versions of BIND reject it.
Just use different file names.

Regards,
Anand
___
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-RPZ and Views

[Tom]

Hi

Using BIND 9.10.4-P2: I've a question about configuring DNS-RPZ and views:
I configured view1 and view2. After configuring all rpz-zones in both 
views, I had errors like this (slave file in view2 is already in use 
from view1):
config: error: /etc/named/named.conf:403: writeable file 
'slave/malware.rpz.spamhaus.org': already in use: /etc/named/named.conf:259


Is there a way to support RPZ in views? I want to achieve that 
Customer01 (view01) should have different RPZ-options than Customer02 
(view02) using the same RPZ-Files.


Thank you.
Kind regards,
Tom
___
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: DNS views and zone transfers, cont

[Bob Harold]

On Tue, Sep 13, 2016 at 10:58 AM, project722 <project...@gmail.com> wrote:

> I have moved the new views into production, and all seems to be working
> fine. I have an "internal" view and an "external" view. I have noticed a
> few re-occuring messages in the logs of the master server that I'd like to
> suppress. Here is what I am seeing:
>
> 1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not
> set: disabling RFC 1918 empty zones: 37 Time(s)
>
> 2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)
>
> 3) zone 
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
> (master) removed: 1 Time(s)
>  zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
>  zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)
>
> For # 3 I basically see an entry for each of our reverse mapping zones,
> which are valid and I don't want them "removed" as the message states And I
> think these are related to #1. I believe I can fix #1 with the 
> "empty-zones-enable
> no;" in my external view, but I am not sure what effect it would have on
> the message generation or how it would affect zone behavior in that view.
>
> I have "empty-zones-enable yes;" in my options, and then
"empty-zones-enable no;" in the view that is forwarding.  So either define
it in every view, or define a default in the options.


> For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
> my named.conf. However it is above the options statement and I am now
> wondering if I need this defined in each view now. Also this 
> fe80::216:3eff:fe37:b866
> is not even my actual link local IP so I am not sure where/how that is
> being generated. My actual link local is
> fe80::f21f:afff:fedd:6a26/64
>
>
I have the "server ... bogus ..." statement in each view, so try it there.


> Any help is greatly appreciated.
>
> On Thu, Sep 8, 2016 at 11:33 AM, project722 <project...@gmail.com> wrote:
>
>> I am not seeing that but thanks for the heads up. I will keep an eye on
>> it.
>>
>> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>> I changed the subject slightly, because I had to cut out a lot of the
>>> forwarded message - the list server was complaining about the size of the
>>> messages.
>>>
>>> I just found that my setup was not working completely as I expected.
>>> The view with only a few zones and forwarding to another view automatically
>>> got the "empty zones" created, so any queries in those zones did not get
>>> forwarded.  I am fixing it by adding to that view the line:
>>>empty-zones-enable no;
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>>
>>>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>>>> transfers. First off, what is the reasoning or benefit of allowing
>>>>> localhost to make zone transfers? Secondly, In my new view config since I
>>>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>>>> zone transfers?
>>>>>
>>>>
>>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>>> purposes, if I am on the server and want to look at a whole zone.  But it
>>>> is not required, if you don't use it for transfers.
>>>> Allowing zone transfers should not affect its use for forwarding, as
>>>> far as I can see.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>>
>>>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>>
>>>>>> You should change:
>>>>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>>>>> To:
>>>>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>>>>
>>>>>> The 'not' (!) won't work if it is last, they are checked in order, so
>>>>>> it needs to be first.
>>>>>>
>>>>>> --
>>>>>> Bob Harold
>>>>>>
>>>>>>
>>>&g

Re: DNS views and zone transfers, cont

[project722]

I have moved the new views into production, and all seems to be working
fine. I have an "internal" view and an "external" view. I have noticed a
few re-occuring messages in the logs of the master server that I'd like to
suppress. Here is what I am seeing:

1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones: 37 Time(s)

2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)

3) zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
(master) removed: 1 Time(s)
 zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
 zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)

For # 3 I basically see an entry for each of our reverse mapping zones,
which are valid and I don't want them "removed" as the message states And I
think these are related to #1. I believe I can fix #1 with the
"empty-zones-enable
no;" in my external view, but I am not sure what effect it would have on
the message generation or how it would affect zone behavior in that view.

For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
my named.conf. However it is above the options statement and I am now
wondering if I need this defined in each view now. Also this
fe80::216:3eff:fe37:b866
is not even my actual link local IP so I am not sure where/how that is
being generated. My actual link local is
fe80::f21f:afff:fedd:6a26/64

Any help is greatly appreciated.

On Thu, Sep 8, 2016 at 11:33 AM, project722 <project...@gmail.com> wrote:

> I am not seeing that but thanks for the heads up. I will keep an eye on
> it.
>
> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>> I changed the subject slightly, because I had to cut out a lot of the
>> forwarded message - the list server was complaining about the size of the
>> messages.
>>
>> I just found that my setup was not working completely as I expected.  The
>> view with only a few zones and forwarding to another view automatically got
>> the "empty zones" created, so any queries in those zones did not get
>> forwarded.  I am fixing it by adding to that view the line:
>>empty-zones-enable no;
>>
>> --
>> Bob Harold
>>
>>
>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>>
>>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote:
>>>
>>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>>> transfers. First off, what is the reasoning or benefit of allowing
>>>> localhost to make zone transfers? Secondly, In my new view config since I
>>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>>> zone transfers?
>>>>
>>>
>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>> purposes, if I am on the server and want to look at a whole zone.  But it
>>> is not required, if you don't use it for transfers.
>>> Allowing zone transfers should not affect its use for forwarding, as far
>>> as I can see.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
>>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>
>>>>> You should change:
>>>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>>>> To:
>>>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>>>
>>>>> The 'not' (!) won't work if it is last, they are checked in order, so
>>>>> it needs to be first.
>>>>>
>>>>> --
>>>>> Bob Harold
>>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 3:21 PM, project722 <project...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I think I have found the problem. I did not need dnssec enabled after
>>>>>> all. All this time I thought it was needed for TSIG to work. But
>>>>>> apparently, the forwarding is working, and zone transfers are going to 
>>>>>> the
>>>>>> right view without it enabled.
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 <project...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok I'm with you now. I have reconfigured my servers and I cant get
>>>>>>> the f

Re: DNS views and zone transfers, cont

[project722]

I am not seeing that but thanks for the heads up. I will keep an eye on it.

On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold  wrote:

> I changed the subject slightly, because I had to cut out a lot of the
> forwarded message - the list server was complaining about the size of the
> messages.
>
> I just found that my setup was not working completely as I expected.  The
> view with only a few zones and forwarding to another view automatically got
> the "empty zones" created, so any queries in those zones did not get
> forwarded.  I am fixing it by adding to that view the line:
>empty-zones-enable no;
>
> --
> Bob Harold
>
>
> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:
>
>>
>> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>>
>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>> transfers. First off, what is the reasoning or benefit of allowing
>>> localhost to make zone transfers? Secondly, In my new view config since I
>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>> zone transfers?
>>>
>>
>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>> purposes, if I am on the server and want to look at a whole zone.  But it
>> is not required, if you don't use it for transfers.
>> Allowing zone transfers should not affect its use for forwarding, as far
>> as I can see.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>>>
 You should change:
   match-clients { internal; key tsigkey; !key tsigkeyext;
 To:
   match-clients { !key tsigkeyext; internal; key tsigkey;

 The 'not' (!) won't work if it is last, they are checked in order, so
 it needs to be first.

 --
 Bob Harold


 On Wed, Sep 7, 2016 at 3:21 PM, project722 
 wrote:

> I think I have found the problem. I did not need dnssec enabled after
> all. All this time I thought it was needed for TSIG to work. But
> apparently, the forwarding is working, and zone transfers are going to the
> right view without it enabled.
>
> On Wed, Sep 7, 2016 at 1:15 PM, project722 
> wrote:
>
>> Ok I'm with you now. I have reconfigured my servers and I cant get
>> the forwarding to work. Since 127.0.0.1 is forwarding request, I made 
>> sure
>> in the options stanza to set it to a listen IP. I have tried several
>> different variations of this method and all end up with SERVFAIL's using
>> dig from a client that gets the "internal" view. Here is my config.
>>
>> acl internal {
>> 192.168.254.0/23; // corpnet
>> };
>>
>> acl external {
>> 192.168.155.0/24;
>> 192.168.160.0/24;
>> };
>>
>> options {
>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master
>> DNS Servers IP
>> directory   "/var/named";
>> dump-file   "/var/named/data/cache_dump.db";
>> statistics-file "/var/named/data/named.stats";
>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>> allow-query{ internal; external; };
>> dnssec-enable yes;
>> dnssec-validation auto;
>> dnssec-lookaside auto;
>> zone-statistics yes;
>>
>> /* Path to ISC DLV key */
>> bindkeys-file "/etc/named.iscdlv.key";
>>
>> managed-keys-directory "/var/named/dynamic";
>>
>> };
>>
>> key "tsigkey" {
>>  algorithm HMAC-SHA512;
>> secret "x";
>> };
>>
>> key "tsigkeyext" {
>> algorithm HMAC-SHA512;
>> secret "xx";
>> };
>>
>> // Start internal view
>>
>> view "corpnet" {
>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>> };
>>
>>   //IP of slave server
>>   server 192.168.155.77 {
>>   keys { tsigkey; };
>> };
>>
>>   also-notify {
>>   192.168.155.77;
>> };
>>
>>   zone "example.com" IN {   //this zone has one zone file per
>> view
>>   type master;
>>   file "/var/named/db.examplein.com";
>>   allow-query { internal; };
>>   allow-transfer { key tsigkey; };
>> };
>>
>>   forwarders {
>>   // forward to external view
>>   127.0.0.1;
>> };
>>
>>   forward only;
>>
>>   include "/etc/named.rfc1912.zones";
>>   include "/etc/named.root.key";
>> };
>>
>> // Start external view
>>
>> view "external" {
>>   match-clients { any; 127.0.0.1; };
>>
>>   //IP of slave server
>>   server 192.168.155.77 {
>>   

Re: DNS views and zone transfers, cont

[Bob Harold]

I changed the subject slightly, because I had to cut out a lot of the
forwarded message - the list server was complaining about the size of the
messages.

I just found that my setup was not working completely as I expected.  The
view with only a few zones and forwarding to another view automatically got
the "empty zones" created, so any queries in those zones did not get
forwarded.  I am fixing it by adding to that view the line:
   empty-zones-enable no;

-- 
Bob Harold


On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold  wrote:

>
> On Thu, Sep 8, 2016 at 9:13 AM, project722  wrote:
>
>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>> transfers. First off, what is the reasoning or benefit of allowing
>> localhost to make zone transfers? Secondly, In my new view config since I
>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>> problem or a conflict if I was to leave the localhost IP in the ACL for
>> zone transfers?
>>
>
> I would allow 127.0.0.1 to do zone transfers for troubleshooting purposes,
> if I am on the server and want to look at a whole zone.  But it is not
> required, if you don't use it for transfers.
> Allowing zone transfers should not affect its use for forwarding, as far
> as I can see.
>
> --
> Bob Harold
>
>
>
>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold  wrote:
>>
>>> You should change:
>>>   match-clients { internal; key tsigkey; !key tsigkeyext;
>>> To:
>>>   match-clients { !key tsigkeyext; internal; key tsigkey;
>>>
>>> The 'not' (!) won't work if it is last, they are checked in order, so it
>>> needs to be first.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Wed, Sep 7, 2016 at 3:21 PM, project722  wrote:
>>>
 I think I have found the problem. I did not need dnssec enabled after
 all. All this time I thought it was needed for TSIG to work. But
 apparently, the forwarding is working, and zone transfers are going to the
 right view without it enabled.

 On Wed, Sep 7, 2016 at 1:15 PM, project722 
 wrote:

> Ok I'm with you now. I have reconfigured my servers and I cant get the
> forwarding to work. Since 127.0.0.1 is forwarding request, I made sure in
> the options stanza to set it to a listen IP. I have tried several 
> different
> variations of this method and all end up with SERVFAIL's using dig from a
> client that gets the "internal" view. Here is my config.
>
> acl internal {
> 192.168.254.0/23; // corpnet
> };
>
> acl external {
> 192.168.155.0/24;
> 192.168.160.0/24;
> };
>
> options {
> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master DNS
> Servers IP
> directory   "/var/named";
> dump-file   "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named.stats";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query{ internal; external; };
> dnssec-enable yes;
> dnssec-validation auto;
> dnssec-lookaside auto;
> zone-statistics yes;
>
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
>
> managed-keys-directory "/var/named/dynamic";
>
> };
>
> key "tsigkey" {
>  algorithm HMAC-SHA512;
> secret "x";
> };
>
> key "tsigkeyext" {
> algorithm HMAC-SHA512;
> secret "xx";
> };
>
> // Start internal view
>
> view "corpnet" {
>   match-clients { internal; key tsigkey; !key tsigkeyext;
> };
>
>   //IP of slave server
>   server 192.168.155.77 {
>   keys { tsigkey; };
> };
>
>   also-notify {
>   192.168.155.77;
> };
>
>   zone "example.com" IN {   //this zone has one zone file per view
>   type master;
>   file "/var/named/db.examplein.com";
>   allow-query { internal; };
>   allow-transfer { key tsigkey; };
> };
>
>   forwarders {
>   // forward to external view
>   127.0.0.1;
> };
>
>   forward only;
>
>   include "/etc/named.rfc1912.zones";
>   include "/etc/named.root.key";
> };
>
> // Start external view
>
> view "external" {
>   match-clients { any; 127.0.0.1; };
>
>   //IP of slave server
>   server 192.168.155.77 {
>   keys { tsigkeyext; };
> };
>
>also-notify {
>   192.168.155.77;
> };
>
> zone "." IN {
> type hint;
> file "named.ca";
> };
>
> zone"testdns.net" IN {
> type master;
> file "db.testdns.net-ext";
> 

Re: DNS views and zone transfers

[Bob Harold]

On Wed, Sep 7, 2016 at 12:49 PM, project722 <project...@gmail.com> wrote:

> Bob, I have few questions regarding your sample config. First off it is
> slightly different than mine, which does work BTW at least in a lab
> environment. In your internal view what is the purpose of having this line:
>
>  // this list must not match 127.0.0.1
> !key "external";   // use this key to test the external
> view
> 10.0.0.0/8;
>
> Why use 127.0.0.1 and what is the 10.0.0.0/8 block for? I also noticed
> you did not include the external key indie the external view. Why is that?
>

The "internal" and "external" keys are so that I can test both views from
anywhere with:

dig something -k key.internal
dig something -k key.external

The keys are also used if you need to do notify's or zone transfers and get
them to the right view.

127.0.0.1 is used to talk from one view to the other, so it needs to match
the external view in this case

10.0.0.0/8 are the "internal" addresses in this example.

The external view could have included the external key, but 'any' covers
that.  If your match is not "any', then you would want to include the
external key and 127.0.0.1.



> On Wed, Sep 7, 2016 at 10:48 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>>
>> On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
>>
>>> Thanks Bob, I will look into this. Do you know if the forwarders feature
>>> is supported in Bind 9.8.2?
>>>
>>>
>> Yes, forwarders is an old and stable feature.
>>
>> ("in-view" is new and experimental)
>>
>> --
>> Bob Harold
>>
>>
>>> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>>
>>>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm interested in the "view forwarding" method. I'm only setting up
>>>>> views to resolve a split DNS issue with one domain. I'd like to have that
>>>>> one zone/domain in my internal view and then if the source IP requests 
>>>>> info
>>>>> for any other zone forward that to my external view. To me this sounds 
>>>>> like
>>>>> a whole lot less work. Do you have any specifics on how I would go about
>>>>> setting that up or can you point me in the direction where I can get info
>>>>> on setting that up? Ideally, I'd want my "internal" clients to still find
>>>>> example.com even if the internal view only had example.org in it.
>>>>> Something like this but how do I incorporate the forwarding?
>>>>>
>>>>> view internal {
>>>>>
>>>>>match clients - internal;
>>>>>
>>>>> zone - example.org
>>>>>
>>>>> };
>>>>>
>>>>> view external {
>>>>>
>>>>> match clients - external {
>>>>>
>>>>> zone example.org {
>>>>> };
>>>>>
>>>>> zone example.com {
>>>>> };
>>>>>
>>>>> };
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>>>>> master/server pair. Zone transfers are working as expected between the 2
>>>>>>> servers for each view. Before we go live into production with this I 
>>>>>>> need
>>>>>>> some clarification on a couple things. Our prod servers are also 
>>>>>>> allowing
>>>>>>> zone transfers to a few other servers besides the slave server. We have 
>>>>>>> an
>>>>>>> acl setup that looks similar to this:
>>>>>>>
>>>>>>> other_xfer_allowed_ns {
>>>>>>> x.x.x.x; // This is our Secondary DNS server
>>>>>>> 127.0.0.1; // localhost can make zone transfers
>>>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>>>>> x.x.x.x/24; // NAT pool for internal DNS server

Re: DNS views and zone transfers

[project722]

Bob, I have few questions regarding your sample config. First off it is
slightly different than mine, which does work BTW at least in a lab
environment. In your internal view what is the purpose of having this line:

 // this list must not match 127.0.0.1
!key "external";   // use this key to test the external view
10.0.0.0/8;

Why use 127.0.0.1 and what is the 10.0.0.0/8 block for? I also noticed you
did not include the external key indie the external view. Why is that?

On Wed, Sep 7, 2016 at 10:48 AM, Bob Harold <rharo...@umich.edu> wrote:

>
> On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
>
>> Thanks Bob, I will look into this. Do you know if the forwarders feature
>> is supported in Bind 9.8.2?
>>
>>
> Yes, forwarders is an old and stable feature.
>
> ("in-view" is new and experimental)
>
> --
> Bob Harold
>
>
>> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>>
>>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
>>>
>>>> I'm interested in the "view forwarding" method. I'm only setting up
>>>> views to resolve a split DNS issue with one domain. I'd like to have that
>>>> one zone/domain in my internal view and then if the source IP requests info
>>>> for any other zone forward that to my external view. To me this sounds like
>>>> a whole lot less work. Do you have any specifics on how I would go about
>>>> setting that up or can you point me in the direction where I can get info
>>>> on setting that up? Ideally, I'd want my "internal" clients to still find
>>>> example.com even if the internal view only had example.org in it.
>>>> Something like this but how do I incorporate the forwarding?
>>>>
>>>> view internal {
>>>>
>>>>match clients - internal;
>>>>
>>>> zone - example.org
>>>>
>>>> };
>>>>
>>>> view external {
>>>>
>>>> match clients - external {
>>>>
>>>> zone example.org {
>>>> };
>>>>
>>>> zone example.com {
>>>> };
>>>>
>>>> };
>>>>
>>>>
>>>>
>>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>
>>>>>
>>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>>>> master/server pair. Zone transfers are working as expected between the 2
>>>>>> servers for each view. Before we go live into production with this I need
>>>>>> some clarification on a couple things. Our prod servers are also allowing
>>>>>> zone transfers to a few other servers besides the slave server. We have 
>>>>>> an
>>>>>> acl setup that looks similar to this:
>>>>>>
>>>>>> other_xfer_allowed_ns {
>>>>>> x.x.x.x; // This is our Secondary DNS server
>>>>>> 127.0.0.1; // localhost can make zone transfers
>>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>>> }; // end of "other_xfer_allowed" ACL
>>>>>>
>>>>>> And in the "allow transfer" statement we have included that ACL. My
>>>>>> question is:
>>>>>>
>>>>>> Now that we are using TSIG, will I need to get with the admins of all
>>>>>> these other servers and provide them my TSIG key so they can request zone
>>>>>> transfers? I would think somehting like that needs to be done since it 
>>>>>> was
>>>>>> required to be configured on slave server, but I am not sure.
>>>>>>
>>>>>
>>>>> No, if you allowed the IP range in your ACL, they don't need the TSIG
>>>>> key.
>>>>> It might be more secure to hand out TSIG keys and remove the IP ranges
>>>>> from the ACL, so only the TSIG key will al