Re: Stub zones, but secndary?
On Mon, Nov 20, 2023 at 03:30:13PM +1300, Nick Tait via bind-users wrote: ! On 20/11/2023 1:00 pm, Peter wrote: ! > It's tricky. One problem is these are slave zones, they are ! > authoritative and do not work well with DNSSEC. ! ! I'm curious... What issues did you have with these zones and DNSSEC? I would ! have expected that the signed zones should just work? Probably they do just work. But then, when I query a nonexistent domain from a simple root-slave, the answer carries an AA flag. When I query the same nonexistent domain from 8.8.8.8, it carries an AD flag. Also, somewhere in the depths of the ISC docs and tutorials I found a paper that shows how to setup the root-slave for DNSSEC so that it does recurse and validate (and that is from where I started to adapt my config). So likely there is an issue somewhere. cheerio, PMc -- 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: Stub zones, but secndary?
Hi Cathy :-) cat...@isc.org (Cathy Almond) wrote: > Have you looked at mirror zones for root? No... post-1990, what do I know about them ;-) I did read up in the docs; it does not mention access control, which I would like to behave just like "hint" zones (only respond to requests coming from a host in the allow-recursion list.) Internally, this might just be a tag that's applied to a "hint"-declared zone. Elmar. -- 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: Stub zones, but secndary?
Have you looked at mirror zones for root?
Zone type "mirror" = it's appropriate for "." but not for other zones.
(Oh - and don't forget to disable ixfr for this zone when you do that -
it's more efficient for the validation step)
Details in the BIND ARM.
Cathy
On 19/11/2023 21:10, Elmar K. Bins wrote:
Good evening,
my freshly recrafted DNS servers got the latest BIND 9.18 pkg from FreeBSD.
They're all supposed to only respond for a certain set of zones to the outside,
but should be able to be used as a resolver from localhost.
The pkg comes with a default config that slaves "." and its cousins instead
of pushing a static hints file. I like this.
Unfortunately, the config just has them as slave zones, without a "hint"
marking. Anybody can query the box for them. I don't like this.
I've put the appropriate "allow-query { localhost; };" into every friggin'
zone entryto every friggin' zone entry. I REALLY don't like this.
I'm wondering whether there's a more elegant way. Like "secondary-hint" zones.
Have I overlooked something?
Thanks for any pointers,
Elmar.
--
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: Stub zones, but secndary?
On 20/11/2023 1:00 pm, Peter wrote: It's tricky. One problem is these are slave zones, they are authoritative and do not work well with DNSSEC. I'm curious... What issues did you have with these zones and DNSSEC? I would have expected that the signed zones should just work? Nick. -- 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: Stub zones, but secndary?
On Sun, Nov 19, 2023 at 09:10:13PM +, Elmar K. Bins wrote:
! my freshly recrafted DNS servers got the latest BIND 9.18 pkg from FreeBSD.
! They're all supposed to only respond for a certain set of zones to the
outside,
! but should be able to be used as a resolver from localhost.
!
! The pkg comes with a default config that slaves "." and its cousins instead
! of pushing a static hints file. I like this.
Me too. :)
! Unfortunately, the config just has them as slave zones, without a "hint"
! marking. Anybody can query the box for them. I don't like this.
It's tricky. One problem is these are slave zones, they are
authoritative and do not work well with DNSSEC.
So I crafted something that does apparently work...
view "rootslave" {
match-clients { 127.0.0.2/32; };
allow-query-cache { none; };// von ARM example
allow-recursion { none; };
recursion no;
zone "." {
type slave;
masters {
// the usual root servers...
// etc.etc.
view "intraslave" {
match-clients { 127.0.0.3/32; key "slave2."; };
allow-query-cache { none; };// von ARM example
allow-recursion { none; };
recursion no;
zone "example.com" { // internal version of my public domain
// looks a little different than public version
type slave; // comes from hidden primary
// etc.etc.
zone "intranet.example.com" { // my lan domain
type slave;
// etc. etc.
// The outside authoritative stuff - but not yet serving it from here!
view "extraslave" {
match-clients { key "slave2a."; }; // slave2a. is for notify
// from hidden primary
allow-query-cache { none; };// von ARM example
allow-recursion { none; };
recursion no;
zone "example.com" { // These are the zones I'm autoritative for
type slave; // fetched from hidden primary
// this must be placed here, and NOT in this view!
allow-query { any; };
// etc.etc.
// Now wiring it all together:
view "guest" {
// for local machines that can use my internet but are NOT
// allowed into my lan (currently none exist)
match-clients { none; };
// bring the root stuff in
zone "." {
type static-stub;
server-addresses { 127.0.0.2; } ;
};
zone "arpa" {
type static-stub;
server-addresses { 127.0.0.2; } ;
};
// etc.etc.
// include localhost and empty zones
include "/usr/local/etc/namedb/named.localempty.conf";
include "/usr/local/etc/namedb/named.localempty-e.conf";
}
// Serving the Intra-net:
view "intra" {
dnstap { all; };
match-clients { 127.0.0.1/32;
::1/128;
192.168.0.0/16;
fd00::/8;
// etc.etc. - all the locally used IP
};
// bring the root stuff in
zone "." {
in-view "guest";
};
zone "arpa" {
in-view "guest";
};
// etc.etc.
zone "example.com" {// internal view of public domain!
type static-stub;
server-addresses { 127.0.0.3; } ;
};
// lan domain
zone "intranet.example.com" {
type static-stub;
server-addresses { 127.0.0.3; } ;
};
// etc.etc.
// localhost and empty zones
include "/usr/local/etc/namedb/named.localempty.conf";
}
// And finally outbound authoritative, i.e. the stuff for all internet
view "external" {
match-clients { any; } ;
allow-query-cache { none; }; # von ARM example
allow-recursion { none; };
recursion no;
zone "example.com" {
in-view "extraslave";
};
// etc.etc.
// here we must NOT refer to the slave rootzones!
// (not sure if this is needed at all)
zone "." {
type hint;
file "/usr/local/etc/namedb/named.root";
};
// localhost and empty zones (shouldn't harm)
include "/usr/local/etc/namedb/named.localempty.conf";
include "/usr/local/etc/namedb/named.localempty-e.conf";
};
! I've put the appropriate "allow-query { localhost; };" into every friggin'
! zone entryto every friggin' zone entry. I REALLY don't like this.
!
! I'm wondering whether there's a more elegant way. Like "secondary-hint" zones.
! Have I overlooked something?
Maybe. As You can see, it can be done, but it's a bit weird -
I got the fancy that I want to have all six-way in one running image. ;)
