Re: filter-a and dns64 in a ipv6-only network
Am 01.02.23 um 16:12 schrieb Bjørn Mork: This sort of "works" for me (although very broken by design, as already noted): Thank you for providing a work around and testing it. I am still not convinced that the filter-a harms less when a real is provided instead of the synthesized. It breaks dnssec anyway. Regards, Thomas -- 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: filter-a and dns64 in a ipv6-only network
Ondřej Surý writes:
> Nobody is preventing from doing the work yourself, or paying somebody for
> doing
> the work for you. That's where the open-source model shines.
Or simply trigger the curiousity of some innocent victim who will then
do the work for free :-)
I don't necessarily believe this is a good idea, for all the reasons
presented earlier in this thread...
But I did't understan why Thomas could't just chain two BIND instances
together to achieve his goal. So I had to try. And found that it's
even possible to do it with views in a single instance, if that's
important.
This sort of "works" for me (although very broken by design, as already
noted):
options {
directory "/tmp/c1";
dnssec-validation auto;
auth-nxdomain no;
listen-on-v6 port 60053 { ::1; };
listen-on port 60054 { 127.0.0.1; };
server-id hostname; // +nsid
no-case-compress { any; };
};
view dns64 {
match-destinations { 127.0.0.1; };
recursion yes;
dns64 64:ff9b::/96 {
clients { any; };
recursive-only yes;
mapped { !10/8; any; };
};
};
view clients {
match-clients { any; };
recursion yes;
forward only;
forwarders { 127.0.0.1 port 60054; };
plugin query "filter-a.so" {
filter-a-on-v6 break-dnssec;
filter-a-on-v4 break-dnssec;
filter-a { ::/0 ; };
};
};
Gives me DNS64 synthesis with A records filtered (i.e. double broken):
bjorn@miraculix:~$ dig a oracle.com @::1 -p 60053
; <<>> DiG 9.18.11-2-Debian <<>> a oracle.com @::1 -p 60053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37408
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 52dca01049a91632010063da7fc70971947511271b6a (good)
;; QUESTION SECTION:
;oracle.com.IN A
;; Query time: 220 msec
;; SERVER: ::1#60053(::1) (UDP)
;; WHEN: Wed Feb 01 16:05:43 CET 2023
;; MSG SIZE rcvd: 67
bjorn@miraculix:~$ dig oracle.com @::1 -p 60053
; <<>> DiG 9.18.11-2-Debian <<>> oracle.com @::1 -p 60053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57965
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ca0aab9924690d5c010063da7fce9c376cafcbc3f08e (good)
;; QUESTION SECTION:
;oracle.com.IN
;; ANSWER SECTION:
oracle.com. 292 IN 64:ff9b::8a01:21a2
;; Query time: 0 msec
;; SERVER: ::1#60053(::1) (UDP)
;; WHEN: Wed Feb 01 16:05:50 CET 2023
;; MSG SIZE rcvd: 95
Feel free to replace the IPv4 loopback with some IPv6 address. That was
just a convenient additional address I happened to have on my test
system :-)
And the odd port number is of course just for my test as an ordinary user.
Bjørn
--
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: filter-a and dns64 in a ipv6-only network
> On 1. 2. 2023, at 13:33, Thomas Schäfer wrote: > > I have learned bind/isc is not willing to support such (test) scenarios. And yet again, let me emphasize that open-source isn't free Swedish buffet. If you want other people to do the work it must either have a strong case (like being useful to more than a single person on planet earth) or incentivised in some other way. Neither was presented here, you just came here telling us that we should not tell you what to do because you know the best. Ok, your choice, your consequences. Nobody is preventing from doing the work yourself, or paying somebody for doing the work for you. That's where the open-source model shines. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: filter-a and dns64 in a ipv6-only network
Thank you for your answers. Of course dns64 breaks dnssec, like any other manipulation of dns resource records. But it doesn't mean that filtering A records breaks dns64, it still only breaks dnssec. So filtering A records and dnssec is mutually exclusive. I know almost all popular dual stack methods. e.g. pure dual stack ( at work since 2005) ds-lite ( very common in Germany for private users, personally since 2018) 464xlat - used here at mobile by DTAG and WiFi at work After two decades of dual stack my approach is to see an end of the migration. That means single stack IPv6. One element of it is DNS64 with NAT64. Another element maybe filtering A records, so clat can be removed. ( clat was originally invented for very very old ip stacks/apps - 10 years ago) Other people have recently introduced a third way between dual stack and ipv6 only called "ipv6 mostly"( RFC 8925) That is two steps forward and one backward. Nevertheless the goal is: IPv6 single stack. I have learned bind/isc is not willing to support such (test) scenarios. Thanks for the conversation. Thomas -- 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: (use-)alt-transfer-source deprecated
Hello Matthijs
Thank you for clarifying, it makes sense now.
I'll just leave use-alt-transfer-source in the configuration for now and
remove it before updating to 9.20.
Kind Regards
Stephan
On 01/02/2023 10.45, Matthijs Mekking wrote:
Hi,
On 2/1/23 09:57, Gasoo wrote:
Hello
I recently updated to 9.18.x and noticed the deprecation warning in
the logs for the option use-alt-transfer-source.
After reading the manual and checking my configuration, I am confused
on how this is going to work in future releases.
My configuration includes the following statements:
options {
listen-on { 1.1.1.1; 2.2.2.2; 3.3.3.3; };
transfer-source 3.3.3.3;
query-source 3.3.3.3;
notify-source 3.3.3.3;
use-alt-transfer-source no;
...
}
Looking at your configuration, you actually don't use
alt-transfer-source: there is no such option in your example and
'use-alt-transfer-source' is set to no anyway.
1.1.1.1 and 2.2.2.2 are only used for incoming DNS queries from
clients and can not be used for zone transfers.
If I remove the option use-alt-transfer-source, in some cases (e.g.
SERVFAIL from primary), additional zone transfers are tried via
0.0.0.0#0, which the OS then sends via the best matching interface /
IP address. >
For this reason the option use-alt-transfer-source is in my
configuration.
From the manual.
use-alt-transfer-source:
This indicates whether the alternate transfer sources should be used.
If views are specified, this defaults to no; otherwise, it defaults
to yes.
alt-transfer-source:
This indicates an alternate transfer source if the one listed in
transfer-source fails and use-alt-transfer-source is set.
How will this be handled in future releases, if transfer-source is
specified, no views are defined and an error occurs?
Is there any other solution to disable transfers from 0.0.0.0#0 in my
case?
I guess in your 9.18 configuration if you don't set
'use-alt-transfer-source', it defaults to yes. Since
'alt-transfer-source' defaults to 0.0.0.0#0', you still need the
configuration despite it is being deprecated.
From 9.20.0 the feature will be gone, the options
'use-alt-transfer-source' and 'alt-transfer-source' will no longer
exist, and thus alternate transfer source will no longer be tried.
In other words, from 9.20.0 it will be as if 'use-alt-transfer-source'
was set to 'no'.
Best regards,
Matthijs
Kind Regards
Stephan
--
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: (use-)alt-transfer-source deprecated
Hi,
On 2/1/23 09:57, Gasoo wrote:
Hello
I recently updated to 9.18.x and noticed the deprecation warning in the
logs for the option use-alt-transfer-source.
After reading the manual and checking my configuration, I am confused on
how this is going to work in future releases.
My configuration includes the following statements:
options {
listen-on { 1.1.1.1; 2.2.2.2; 3.3.3.3; };
transfer-source 3.3.3.3;
query-source 3.3.3.3;
notify-source 3.3.3.3;
use-alt-transfer-source no;
...
}
Looking at your configuration, you actually don't use
alt-transfer-source: there is no such option in your example and
'use-alt-transfer-source' is set to no anyway.
1.1.1.1 and 2.2.2.2 are only used for incoming DNS queries from clients
and can not be used for zone transfers.
If I remove the option use-alt-transfer-source, in some cases (e.g.
SERVFAIL from primary), additional zone transfers are tried via
0.0.0.0#0, which the OS then sends via the best matching interface / IP
address. >
For this reason the option use-alt-transfer-source is in my configuration.
From the manual.
use-alt-transfer-source:
This indicates whether the alternate transfer sources should be used. If
views are specified, this defaults to no; otherwise, it defaults to yes.
alt-transfer-source:
This indicates an alternate transfer source if the one listed in
transfer-source fails and use-alt-transfer-source is set.
How will this be handled in future releases, if transfer-source is
specified, no views are defined and an error occurs?
Is there any other solution to disable transfers from 0.0.0.0#0 in my case?
I guess in your 9.18 configuration if you don't set
'use-alt-transfer-source', it defaults to yes. Since
'alt-transfer-source' defaults to 0.0.0.0#0', you still need the
configuration despite it is being deprecated.
From 9.20.0 the feature will be gone, the options
'use-alt-transfer-source' and 'alt-transfer-source' will no longer
exist, and thus alternate transfer source will no longer be tried.
In other words, from 9.20.0 it will be as if 'use-alt-transfer-source'
was set to 'no'.
Best regards,
Matthijs
Kind Regards
Stephan
--
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
(use-)alt-transfer-source deprecated
Hello
I recently updated to 9.18.x and noticed the deprecation warning in the
logs for the option use-alt-transfer-source.
After reading the manual and checking my configuration, I am confused on
how this is going to work in future releases.
My configuration includes the following statements:
options {
listen-on { 1.1.1.1; 2.2.2.2; 3.3.3.3; };
transfer-source 3.3.3.3;
query-source 3.3.3.3;
notify-source 3.3.3.3;
use-alt-transfer-source no;
...
}
1.1.1.1 and 2.2.2.2 are only used for incoming DNS queries from clients
and can not be used for zone transfers.
If I remove the option use-alt-transfer-source, in some cases (e.g.
SERVFAIL from primary), additional zone transfers are tried via
0.0.0.0#0, which the OS then sends via the best matching interface / IP
address.
For this reason the option use-alt-transfer-source is in my configuration.
From the manual.
use-alt-transfer-source:
This indicates whether the alternate transfer sources should be used. If
views are specified, this defaults to no; otherwise, it defaults to yes.
alt-transfer-source:
This indicates an alternate transfer source if the one listed in
transfer-source fails and use-alt-transfer-source is set.
How will this be handled in future releases, if transfer-source is
specified, no views are defined and an error occurs?
Is there any other solution to disable transfers from 0.0.0.0#0 in my case?
Kind Regards
Stephan
--
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
