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: Gratuitous AXFRs of RPZ after 9.18.11
I was never able to uncover the underlying problem with that update. The only clue I had was the service remained in "activating" state, rather than "running". named was listening as expected, was transfering zone data, was caching and serving the correct data, but didn't seem to recognize it had the same data when it next retrieved the SOA record. I eventually restored the secondary host from backup, and performed the upgrade from 9.18.10 --> 9.18.11 again. It behaves exactly as expected; retrieving the SOA record, recognizing it already has that serial number, and waiting patiently for the refresh interval to expire before checking again. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 1/27/2023 1:53 AM, Ondřej Surý wrote: FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause the described behaviour. That said - in addition to what Greg said, I would suggest increasing the log level to small debug levels if you can and perhaps something will stand out-- 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
