Filter A records in an IPv6 only environment

Kim Ebert kim at developmint.work
Tue May 1 23:47:47 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180501/29b7f442/attachment.html>


More information about the bind-users mailing list