<div dir="ltr"><div>Here is a rough pass at adding filter-a<br><br><a href="https://github.com/reflectivedevelopment/bind9/tree/v9_10_3_patch_filter_a">https://github.com/reflectivedevelopment/bind9/tree/v9_10_3_patch_filter_a</a><br><br></div>I add the following to my conf. It seems to do what I would like it to do.<br><div><div><br>filter-a break-dnssec;<br><br></div><div>dig a <a href="http://www.google.com">www.google.com</a><br><br>;<a href="http://www.google.com">www.google.com</a>.            IN    A<br><br></div><div>dig aaaa <a href="http://www.google.com">www.google.com</a><br><br><a href="http://www.google.com">www.google.com</a>.        155    IN    AAAA    2607:f8b0:400e:c06::63<br><br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 7:23 PM, Kim Ebert <span dir="ltr"><<a href="mailto:kim@developmint.work" target="_blank">kim@developmint.work</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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...<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 7:21 PM, Mark Andrews <span dir="ltr"><<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Upgrading nodejs and getting verbatim=1 added to the appropriate call<br>
should also help.  The bug report you linked to showed that getaddrinfo<br>
result order will now be honoured with verbatim=1.  You then just need<br>
to ensure that getaddrinfo is correctly configured to return IPv6<br>
addresses before IPv4 addresses.  This should be the default for getaddrinfo.<br>
<span class="m_7522598150892632141HOEnZb"><font color="#888888"><br>
Mark<br>
</font></span><div class="m_7522598150892632141HOEnZb"><div class="m_7522598150892632141h5"><br>
> On 2 May 2018, at 10:50 am, Kim Ebert <<a href="mailto:kim@developmint.work" target="_blank">kim@developmint.work</a>> wrote:<br>
> <br>
> Yeah, fighting with the application developers doesn't appear to be a good option, nor is applying any tunneling mechanisms such as 464xlat.<br>
> <br>
> 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. <br>
> <br>
> Thanks for the feedback though. I appreciate it. <br>
> <br>
> As far as the application developer, it is nearly as frustrating as Android dhcpv6 support. <br>
> <br>
> Kim<br>
> <br>
> On Tue, May 1, 2018, 6:30 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
> Which is really because they don’t understand that happy eyeballs is<br>
> just a tweak to RFC 1123 multi-homed server support.  It isn’t IPv6<br>
> transition support. It’s just the IPv6 results in a LOT MORE MULTI-HOMED<br>
> sites especially when DNS64 is in the mix.<br>
> <br>
> Failure to honour address preferences returned from getaddrinfo should<br>
> be a firing squad offence.  Application developers DO NOT KNOW how the<br>
> network the application is connected to is configured.<br>
> <br>
> You could move to using DS-Lite, MAP-E, MAP-T, 464XLAT etc. to provide<br>
> IPv4 as a service instead of DNS64 + NAT64 (I presume you actually meant<br>
> DNS64 + NAT64 when you said NAT64).  Your local network can still be<br>
> IPv6-only.  MAP-T and 464XLAT can still use your NAT64 box.<br>
> <br>
> DS-Lite and MAP-E are different ways to automatically configure<br>
> IPv4 in IPv6 tunnels.<br>
> <br>
> MAP-T and 464XLAT are just different ways to configure the CLAT<br>
> which translates IPv4 packets to IPv6 packets before sending them<br>
> to the NAT64 for reverse translation.<br>
> <br>
> nodejs should work fine with all of DS-Lite, MAP-E, MAP-T and 464XLAT<br>
> as they allow A records (IPv4 literals) to work for connections.<br>
> <br>
> Mark<br>
> <br>
> > On 2 May 2018, at 9:47 am, Kim Ebert <<a href="mailto:kim@developmint.work" target="_blank">kim@developmint.work</a>> wrote:<br>
> > <br>
> > Developer had refused to apply happy eyeballs. <br>
> > <br>
> > See <a href="https://github.com/nodejs/node/issues/6307" rel="noreferrer" target="_blank">https://github.com/nodejs/node<wbr>/issues/6307</a><br>
> > <br>
> > I can't fix the application, so I need to fix my network.<br>
> > <br>
> > Kim<br>
> > <br>
> > On Tue, May 1, 2018, 5:44 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
> > If you have a IPv6 only network then there should be no default IPv4 route so<br>
> > the connect(), sendto() etc. should all fail immediately with network unreachable.<br>
> > If they don’t then complain to your OS developer. If the application does not<br>
> > detect these failures complain to the application developer.<br>
> > <br>
> > Applications should fail over immediately if there is not a covering route.<br>
> > <br>
> > If you have a local default IPv4 route, the router should be returning network<br>
> > unreachable and the OS should be processing them. This should cause network<br>
> > errors to be delivered to the application.<br>
> > <br>
> > The application should also be implementing happy eyeballs where you fail<br>
> > over to other addresses with sub second delays when there are multiple<br>
> > addresses to try.  There is nothing wrong with having multiple connection<br>
> > attempts happening in parallel.<br>
> > <br>
> > Mucking with DNS responses is only covering up application defects.  Filtering<br>
> > A records also breaks DNS64 for applications that are using DNSSEC as they<br>
> > need to see the A records as well as the AAAA responses.<br>
> > <br>
> > Notify the application vendor they they have a denial-of-service bug.<br>
> > <br>
> > Mark<br>
> > <br>
> > > On 2 May 2018, at 9:00 am, Kim Ebert <<a href="mailto:kim@developmint.work" target="_blank">kim@developmint.work</a>> wrote:<br>
> > > <br>
> > > Hi All,<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 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?<br>
> > > <br>
> > > If anyone is curious, the offending program is nodejs and npm.<br>
> > > <br>
> > > Thanks,<br>
> > > <br>
> > > Kim<br>
> > > ______________________________<wbr>_________________<br>
> > > Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a> to unsubscribe from this list<br>
> > > <br>
> > > bind-users mailing list<br>
> > > <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
> > > <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br>
> > <br>
> > -- <br>
> > Mark Andrews, ISC<br>
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> > PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
> > <br>
> > <br>
> > On May 1, 2018 5:44 PM, "Mark Andrews" <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
> > If you have a IPv6 only network then there should be no default IPv4 route so<br>
> > the connect(), sendto() etc. should all fail immediately with network unreachable.<br>
> > If they don’t then complain to your OS developer. If the application does not<br>
> > detect these failures complain to the application developer.<br>
> > <br>
> > Applications should fail over immediately if there is not a covering route.<br>
> > <br>
> > If you have a local default IPv4 route, the router should be returning network<br>
> > unreachable and the OS should be processing them. This should cause network<br>
> > errors to be delivered to the application.<br>
> > <br>
> > The application should also be implementing happy eyeballs where you fail<br>
> > over to other addresses with sub second delays when there are multiple<br>
> > addresses to try.  There is nothing wrong with having multiple connection<br>
> > attempts happening in parallel.<br>
> > <br>
> > Mucking with DNS responses is only covering up application defects.  Filtering<br>
> > A records also breaks DNS64 for applications that are using DNSSEC as they<br>
> > need to see the A records as well as the AAAA responses.<br>
> > <br>
> > Notify the application vendor they they have a denial-of-service bug.<br>
> > <br>
> > Mark<br>
> > <br>
> > <br>
> > > On 2 May 2018, at 9:00 am, Kim Ebert <<a href="mailto:kim@developmint.work" target="_blank">kim@developmint.work</a>> wrote:<br>
> > > <br>
> > > Hi All,<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > 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?<br>
> > > <br>
> > > If anyone is curious, the offending program is nodejs and npm.<br>
> > > <br>
> > > Thanks,<br>
> > > <br>
> > > Kim<br>
> > > ______________________________<wbr>_________________<br>
> > > Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a> to unsubscribe from this list<br>
> > > <br>
> > > bind-users mailing list<br>
> > > <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
> > > <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br>
> > <br>
> > <br>
> > -- <br>
> > Mark Andrews, ISC<br>
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> > PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
> > <br>
> > <br>
> <br>
> -- <br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
> <br>
<br>
-- <br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742              INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>