Here is a rough pass at adding filter-a https://github.com/reflectivedevelopment/bind9/tree/v9_10_3_patch_filter_a
I add the following to my conf. It seems to do what I would like it to do. filter-a break-dnssec; dig a www.google.com ;www.google.com. IN A dig aaaa www.google.com www.google.com. 155 IN AAAA 2607:f8b0:400e:c06::63 On Tue, May 1, 2018 at 7:23 PM, Kim Ebert <[email protected]> wrote: > Yes, unfortunately, I don't have control over the app(NPM) in NodeJS that > is making the call. A bit of a chicken and the egg problem since they > didn't make it the default... > > On Tue, May 1, 2018 at 7:21 PM, Mark Andrews <[email protected]> wrote: > >> Upgrading nodejs and getting verbatim=1 added to the appropriate call >> should also help. The bug report you linked to showed that getaddrinfo >> result order will now be honoured with verbatim=1. You then just need >> to ensure that getaddrinfo is correctly configured to return IPv6 >> addresses before IPv4 addresses. This should be the default for >> getaddrinfo. >> >> Mark >> >> > On 2 May 2018, at 10:50 am, Kim Ebert <[email protected]> wrote: >> > >> > Yeah, fighting with the application developers doesn't appear to be a >> good option, nor is applying any tunneling mechanisms such as 464xlat. >> > >> > One of the main goals is to establish an ipv6 only network that just >> works. An ipv6 only network doesn't need A records. I'll give a link to my >> patch or repo when it is ready. >> > >> > Thanks for the feedback though. I appreciate it. >> > >> > As far as the application developer, it is nearly as frustrating as >> Android dhcpv6 support. >> > >> > Kim >> > >> > On Tue, May 1, 2018, 6:30 PM Mark Andrews <[email protected]> wrote: >> > Which is really because they don’t understand that happy eyeballs is >> > just a tweak to RFC 1123 multi-homed server support. It isn’t IPv6 >> > transition support. It’s just the IPv6 results in a LOT MORE MULTI-HOMED >> > sites especially when DNS64 is in the mix. >> > >> > Failure to honour address preferences returned from getaddrinfo should >> > be a firing squad offence. Application developers DO NOT KNOW how the >> > network the application is connected to is configured. >> > >> > You could move to using DS-Lite, MAP-E, MAP-T, 464XLAT etc. to provide >> > IPv4 as a service instead of DNS64 + NAT64 (I presume you actually meant >> > DNS64 + NAT64 when you said NAT64). Your local network can still be >> > IPv6-only. MAP-T and 464XLAT can still use your NAT64 box. >> > >> > DS-Lite and MAP-E are different ways to automatically configure >> > IPv4 in IPv6 tunnels. >> > >> > MAP-T and 464XLAT are just different ways to configure the CLAT >> > which translates IPv4 packets to IPv6 packets before sending them >> > to the NAT64 for reverse translation. >> > >> > nodejs should work fine with all of DS-Lite, MAP-E, MAP-T and 464XLAT >> > as they allow A records (IPv4 literals) to work for connections. >> > >> > Mark >> > >> > > On 2 May 2018, at 9:47 am, Kim Ebert <[email protected]> wrote: >> > > >> > > Developer had refused to apply happy eyeballs. >> > > >> > > See https://github.com/nodejs/node/issues/6307 >> > > >> > > I can't fix the application, so I need to fix my network. >> > > >> > > Kim >> > > >> > > On Tue, May 1, 2018, 5:44 PM Mark Andrews <[email protected]> wrote: >> > > If you have a IPv6 only network then there should be no default IPv4 >> route so >> > > the connect(), sendto() etc. should all fail immediately with network >> unreachable. >> > > If they don’t then complain to your OS developer. If the application >> does not >> > > detect these failures complain to the application developer. >> > > >> > > Applications should fail over immediately if there is not a covering >> route. >> > > >> > > If you have a local default IPv4 route, the router should be >> returning network >> > > unreachable and the OS should be processing them. This should cause >> network >> > > errors to be delivered to the application. >> > > >> > > The application should also be implementing happy eyeballs where you >> fail >> > > over to other addresses with sub second delays when there are multiple >> > > addresses to try. There is nothing wrong with having multiple >> connection >> > > attempts happening in parallel. >> > > >> > > Mucking with DNS responses is only covering up application defects. >> Filtering >> > > A records also breaks DNS64 for applications that are using DNSSEC as >> they >> > > need to see the A records as well as the AAAA responses. >> > > >> > > Notify the application vendor they they have a denial-of-service bug. >> > > >> > > Mark >> > > >> > > > On 2 May 2018, at 9:00 am, Kim Ebert <[email protected]> wrote: >> > > > >> > > > Hi All, >> > > > >> > > > I recently came across an issue where the user program preferred >> IPv4 over IPv6. This is a problem because I've created a network that is >> IPv6 only. I'm currently using NAT64 to provide access to services that >> don't have any IPv6 access. >> > > > >> > > > Now this particular program could work if the DNS records didn't >> provide A records. I would rather do everything I can as an admin to make >> the network just work instead of waiting for all of the end user programs >> to be fixed, so I started working on filter-a functionality to filter out A >> responses. Currently implementation status is that it sort of works, which >> is further than I expected to get in 2 days. >> > > > >> > > > I wonder if anyone in the community is interested in me sharing the >> work, and if I should go to the effort to publish the effort? >> > > > >> > > > If anyone is curious, the offending program is nodejs and npm. >> > > > >> > > > Thanks, >> > > > >> > > > Kim >> > > > _______________________________________________ >> > > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> > > > >> > > > bind-users mailing list >> > > > [email protected] >> > > > 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: [email protected] >> > > >> > > >> > > On May 1, 2018 5:44 PM, "Mark Andrews" <[email protected]> wrote: >> > > If you have a IPv6 only network then there should be no default IPv4 >> route so >> > > the connect(), sendto() etc. should all fail immediately with network >> unreachable. >> > > If they don’t then complain to your OS developer. If the application >> does not >> > > detect these failures complain to the application developer. >> > > >> > > Applications should fail over immediately if there is not a covering >> route. >> > > >> > > If you have a local default IPv4 route, the router should be >> returning network >> > > unreachable and the OS should be processing them. This should cause >> network >> > > errors to be delivered to the application. >> > > >> > > The application should also be implementing happy eyeballs where you >> fail >> > > over to other addresses with sub second delays when there are multiple >> > > addresses to try. There is nothing wrong with having multiple >> connection >> > > attempts happening in parallel. >> > > >> > > Mucking with DNS responses is only covering up application defects. >> Filtering >> > > A records also breaks DNS64 for applications that are using DNSSEC as >> they >> > > need to see the A records as well as the AAAA responses. >> > > >> > > Notify the application vendor they they have a denial-of-service bug. >> > > >> > > Mark >> > > >> > > >> > > > On 2 May 2018, at 9:00 am, Kim Ebert <[email protected]> wrote: >> > > > >> > > > Hi All, >> > > > >> > > > I recently came across an issue where the user program preferred >> IPv4 over IPv6. This is a problem because I've created a network that is >> IPv6 only. I'm currently using NAT64 to provide access to services that >> don't have any IPv6 access. >> > > > >> > > > Now this particular program could work if the DNS records didn't >> provide A records. I would rather do everything I can as an admin to make >> the network just work instead of waiting for all of the end user programs >> to be fixed, so I started working on filter-a functionality to filter out A >> responses. Currently implementation status is that it sort of works, which >> is further than I expected to get in 2 days. >> > > > >> > > > I wonder if anyone in the community is interested in me sharing the >> work, and if I should go to the effort to publish the effort? >> > > > >> > > > If anyone is curious, the offending program is nodejs and npm. >> > > > >> > > > Thanks, >> > > > >> > > > Kim >> > > > _______________________________________________ >> > > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> > > > >> > > > bind-users mailing list >> > > > [email protected] >> > > > 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: [email protected] >> > > >> > > >> > >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: [email protected] >> > >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >> >> >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
