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: filter-a and dns64 in a ipv6-only network
> On Jan 31, 2023, at 15:27, Thomas Schäfer wrote: > > Am Dienstag, 31. Januar 2023, 20:03:42 CET schrieb Marco: > >> >> Why would it make sense to block them? > > Avoiding wrong decisions by "happy eyeballs" - probably the same rare reasons > why isc introduced the filter yeas ago - in theory there is no reason to > block nor A. But blocking A depending on the existence of makes no > sense at all. > (as bind at moment is doing) I’ve found one edge case where blocking records fixes something in order to force it to A addresses. Netflix I use a Hurricane Electric tunnel for my IPv6. Works like a charm for every other site I use. But Netflix rejects connections because it thinks it’s on a VPN. So, filtering the quad A makes it appear it isn’t IPv6 enabled, so it connects over 4. Works like a champ. Eric signature.asc Description: Message signed with OpenPGP -- 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 Feb 2023, at 05:52, Thomas Schäfer wrote: > > Am Montag, 30. Januar 2023, 23:12:53 CET schrieb Mark Andrews: >> Do you want a correctly operating DNS64 server or do you want to filter >> all A records? They are mutually exclusive requirements. Please read >> RFC 6147 to understand why they are mutually exclusive. > > That's simply not true. RFC 6147 is about synthesizing records based on > A > records. It says nothing about blocking A records afterwards. Then pray tell how does section 5.5. "DNSSEC Processing: DNS64 in Validating Resolver Mode” work if the server does not return A records? As I said DNS64 and filtering A records are mutually exclusive. There is down stream stuff that needs to see the records to make their own records. B.T.W. That section is not really compatible with DNSSEC. It works in some circumstances but will fail in other as a validating DNSSEC client needs to ask both CD=0 and CD=1 questions. I tried hard to point out that DNS64 was incompatible with DNSSEC while it was still in draft form. >> You seem to have this strange notion that to run an IPv6-only node or >> network that you need to filter out A records. > > It isn't more strange than filtering records in old IPv4 only networks. > That filter is ironically implemented by the isc - despite there is no > serious > RFC for that. > The purpose of the A record filter is to correct the behavior of apps which > don't respect IPv6 RFCs regarding the preference of IPv6 over IPv4. >> Could you tell me who or >> what told you this was required? > > Thank you for the personal attack within the first contact. Firstly I wanted to correct the source of the misinformation. I’m sorry if you perceived it as an attack. > I am old (enough) > - I can speak for myself. > I am an experienced user of different IPv6 only networks. > e.g > daily at eduroam-IPv6only, a big Wifi network administrated by the Leibniz > Supercomputinger Centre in Munich, > daily at the IPv6-only mobile network(4g/5g) by Deutsche Telekom, > once a year at the RIPE conference WiFi > I am the admin of my home/test lab with: tayga, jool, unbound (filters a, > does > dns64) , dnsmasq (can filter a, but can't do dns64 ) Just because something does something doesn’t make it a good thing. > I know that clat is a solution for *some* very old apps, usually on > smartphones and recently also on macs. > Nevertheless Windows doesn't use clat in wireless/wired LANs. > I want to get rid of clat - aka 464xlat. ( clat was not invented for eternity) > Even linux has no default clat installation on many distributions. On Windows you can manually configure an IPv4 in IPv6 tunnel and use it to talk to a DS-Lite AFTR element (RFC 6333) if it doesn’t do it automatically. I don’t use Windows normally so I don’t know whether it has support to look for the IPv6 DHCPv6 option to automatically configure the tunnel. You can do the same with a Mac and Linux boxes. > My experience until now: the a record filter doesn't break anything, but it > make some apps working without clat - so at least some windows and linux > apps. Well now you have learnt that it does break DNS64. > Now I am testing the usefulness of bind. In the recent state it isn't useful. > > Regards > Thomas Schäfer -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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
Am Dienstag, 31. Januar 2023, 20:03:42 CET schrieb Marco: > > Why would it make sense to block them? Avoiding wrong decisions by "happy eyeballs" - probably the same rare reasons why isc introduced the filter yeas ago - in theory there is no reason to block nor A. But blocking A depending on the existence of makes no sense at all. (as bind at moment is doing) > > > You seem to have this strange notion that to run an IPv6-only node > > > or network that you need to filter out A records. > > > > It isn't more strange than filtering records in old IPv4 only > > networks. That filter is ironically implemented by the isc - despite > > there is no serious RFC for that. > > I don't see a reason for filtering at all. What is the benefit of that? wrong ipv6/ipv4 preference/selections by apps > > > The purpose of the A record filter is to correct the behavior of apps > > which don't respect IPv6 RFCs regarding the preference of IPv6 over > > IPv4. > > Best would be to fix these "apps". > If the computer does not have an IPv4 address, the A records are > useless, it can't use them and needs to connect via IPv6. It would be of course - but reality is - apps, even the defaults in some programming languages like java are still wrong. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/doc-files/net-properties.html > Why don't they work if they can't connect using IPv4? > Which apps are affected? e.g. gpsprune under linux: LANG=C java -jar gpsprune_22.2.jar IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable IOE: java.net.SocketException - Network is unreachable They don't load the cards. I have to set manually the environment for the(each wrong) java app: java -Djava.net.preferIPv6Addresses=true or I have to ensure clatd is running - which is not my understanding of ipv6 only. or I have to remove the A record, independent of the fact if the record is real or synthesized . 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
Am 31.01.2023 um 19:52:11 Uhr schrieb Thomas Schäfer: > Am Montag, 30. Januar 2023, 23:12:53 CET schrieb Mark Andrews: > > Do you want a correctly operating DNS64 server or do you want to > > filter all A records? They are mutually exclusive requirements. > > Please read RFC 6147 to understand why they are mutually exclusive. > > > > That's simply not true. RFC 6147 is about synthesizing records > based on A records. It says nothing about blocking A records > afterwards. Why would it make sense to block them? > > You seem to have this strange notion that to run an IPv6-only node > > or network that you need to filter out A records. > > It isn't more strange than filtering records in old IPv4 only > networks. That filter is ironically implemented by the isc - despite > there is no serious RFC for that. I don't see a reason for filtering at all. What is the benefit of that? > The purpose of the A record filter is to correct the behavior of apps > which don't respect IPv6 RFCs regarding the preference of IPv6 over > IPv4. Best would be to fix these "apps". If the computer does not have an IPv4 address, the A records are useless, it can't use them and needs to connect via IPv6. > My experience until now: the a record filter doesn't break anything, > but it make some apps working without clat - so at least some > windows and linux apps. Why don't they work if they can't connect using IPv4? Which apps are affected? -- 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
Am Montag, 30. Januar 2023, 23:12:53 CET schrieb Mark Andrews: > Do you want a correctly operating DNS64 server or do you want to filter > all A records? They are mutually exclusive requirements. Please read > RFC 6147 to understand why they are mutually exclusive. That's simply not true. RFC 6147 is about synthesizing records based on A records. It says nothing about blocking A records afterwards. > You seem to have this strange notion that to run an IPv6-only node or > network that you need to filter out A records. It isn't more strange than filtering records in old IPv4 only networks. That filter is ironically implemented by the isc - despite there is no serious RFC for that. The purpose of the A record filter is to correct the behavior of apps which don't respect IPv6 RFCs regarding the preference of IPv6 over IPv4. > Could you tell me who or > what told you this was required? Thank you for the personal attack within the first contact. I am old (enough) - I can speak for myself. I am an experienced user of different IPv6 only networks. e.g daily at eduroam-IPv6only, a big Wifi network administrated by the Leibniz Supercomputinger Centre in Munich, daily at the IPv6-only mobile network(4g/5g) by Deutsche Telekom, once a year at the RIPE conference WiFi I am the admin of my home/test lab with: tayga, jool, unbound (filters a, does dns64) , dnsmasq (can filter a, but can't do dns64 ) I know that clat is a solution for *some* very old apps, usually on smartphones and recently also on macs. Nevertheless Windows doesn't use clat in wireless/wired LANs. I want to get rid of clat - aka 464xlat. ( clat was not invented for eternity) Even linux has no default clat installation on many distributions. My experience until now: the a record filter doesn't break anything, but it make some apps working without clat - so at least some windows and linux apps. Now I am testing the usefulness of bind. In the recent state it isn't useful. Regards Thomas Schäfer -- 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
Do you want a correctly operating DNS64 server or do you want to filter
all A records? They are mutually exclusive requirements. Please read
RFC 6147 to understand why they are mutually exclusive.
IPv6-only means that the IP packets being sent and received are only IPv6
packets for the thing (node, network) that is being described as IPv6-only.
You seem to have this strange notion that to run an IPv6-only node or
network that you need to filter out A records. Could you tell me who or
what told you this was required?
Mark
> On 31 Jan 2023, at 06:01, Thomas Schäfer wrote:
>
> Hi,
>
> I use tumbleweed for testing, since compiling bind is hard(at least for me).
>
> bind version: 9.18.11
>
> options {
>
>dns64 64:ff9b::/96 {
>clients { any; };
>recursive-only yes;
>mapped { !10/8; any; };
>};
>
> };
>
>plugin query "filter-a.so" {
> filter-a-on-v6 break-dnssec;
> filter-a-on-v4 break-dnssec;
> filter-a { ::/0 ; };
>};
>
> My test setup is intended to be ipv6-only. Please don't try to convince me,
> that clat would be better.
> (https://lists.isc.org/mailman/htdig/bind-users/2022-March/105826.html) I
> don't want IPv4 at all.
>
> The first line of the man page says:
> "filter-a - filter A in DNS responses when is present"
>
> and here starts my problem: dns64 generates an -Record, but the plugin
> filter-a expects an real -response. In the end a isn't filtered.
>
>
> Example with real -record
> host ct.de ::1
> Using domain server:
> Name: ::1
> Address: ::1#53
> Aliases:
>
> ct.de has IPv6 address 2a02:2e0:3fe:1001:302::
> ct.de mail is handled by 50 secondarymx.heise.de.
> ct.de mail is handled by 10 relay.heise.de.
>
> Example with synthesized -record
>
> host sz.de ::1
> Using domain server:
> Name: ::1
> Address: ::1#53
> Aliases:
>
> sz.de has address 195.50.177.61
> sz.de has IPv6 address 64:ff9b::c332:b13d
> sz.de has IPv6 address 64:ff9b::c332:b13d
> sz.de mail is handled by 50 sz-de.mail.protection.outlook.com.
>
>
> How can I achieve to remove a-records at any time?
>
>
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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
filter-a and dns64 in a ipv6-only network
Hi,
I use tumbleweed for testing, since compiling bind is hard(at least for me).
bind version: 9.18.11
options {
dns64 64:ff9b::/96 {
clients { any; };
recursive-only yes;
mapped { !10/8; any; };
};
};
plugin query "filter-a.so" {
filter-a-on-v6 break-dnssec;
filter-a-on-v4 break-dnssec;
filter-a { ::/0 ; };
};
My test setup is intended to be ipv6-only. Please don't try to convince me,
that clat would be better.
(https://lists.isc.org/mailman/htdig/bind-users/2022-March/105826.html) I
don't want IPv4 at all.
The first line of the man page says:
"filter-a - filter A in DNS responses when is present"
and here starts my problem: dns64 generates an -Record, but the plugin
filter-a expects an real -response. In the end a isn't filtered.
Example with real -record
host ct.de ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:
ct.de has IPv6 address 2a02:2e0:3fe:1001:302::
ct.de mail is handled by 50 secondarymx.heise.de.
ct.de mail is handled by 10 relay.heise.de.
Example with synthesized -record
host sz.de ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:
sz.de has address 195.50.177.61
sz.de has IPv6 address 64:ff9b::c332:b13d
sz.de has IPv6 address 64:ff9b::c332:b13d
sz.de mail is handled by 50 sz-de.mail.protection.outlook.com.
How can I achieve to remove a-records at any time?
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
