Problem with recursion for windows bind for Teamviewer
I don't know if this will be fixed before EOL for windows bind but here is the problem Teamviewer (and maybe other sites too) when you do the recursion when no answer under 1000ms it tries again which is trigged by client windows (not the one running bind) which also tries again for a answer this seems to causes the bind server not to give a answer but it tries and tries then Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be causing a problem for bind for windows because I tested bind in Ubuntu having DNS forward for teamviewer.com to it and Teamviewer loads faster. So it be nice if this could be fixed but I will not hold my breath. Thanks for any insight on this -- 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 recursion for windows bind for Teamviewer
Hey, BIND 9.16 is in security-and-critical-only mode, so this won’t get fixed in any case. However, your message is incomprehensible. If you want to get anything fixed, we will need more clarity in the report - describe your setup (clients, recursive servers, authoritative servers) and properly describe the communication between those. Logs from the failing servers are absolute minimum. Perhaps (annotated) tcpdump (wireshark) dumps would be also helpful. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 19. 11. 2023, at 19:40, legacyone via bind-users > wrote: > > > I don't know if this will be fixed before EOL for windows bind but here is > the problem > Teamviewer (and maybe other sites too) when you do the recursion when no > answer under 1000ms it tries again which is trigged by client windows (not > the one running bind) which also tries again for a answer this seems to > causes the bind server not to give a answer but it tries and tries then > Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be > causing a problem for bind for windows because I tested bind in Ubuntu having > DNS forward for teamviewer.com to it and Teamviewer loads faster. > So it be nice if this could be fixed but I will not hold my breath. > Thanks for any insight on this > -- > 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
Stub zones, but secndary?
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 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. ;)
(Original
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
