Filter A records in an IPv6 only environment

Kim Ebert kim at developmint.work
Mon May 7 15:34:53 UTC 2018 

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 <kim at developmint.work> 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 <marka at isc.org> 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 <kim at developmint.work> 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 <marka at isc.org> 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 <kim at developmint.work> 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 <marka at isc.org> 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 <kim at developmint.work> 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
>> > > > bind-users at 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: marka at isc.org
>> > >
>> > >
>> > > On May 1, 2018 5:44 PM, "Mark Andrews" <marka at isc.org> 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 <kim at developmint.work> 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
>> > > > bind-users at 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: marka at isc.org
>> > >
>> > >
>> >
>> > --
>> > Mark Andrews, ISC
>> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> > PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>> >
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180507/1c94bcab/attachment-0001.html>

More information about the bind-users mailing list