Filter A records in an IPv6 only environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Filter A records in an IPv6 only environment

Kim Ebert
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Mark Andrews
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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Kim Ebert
Developer had refused to apply happy eyeballs. 


I can't fix the application, so I need to fix my network.

Kim

On Tue, May 1, 2018, 5:44 PM Mark Andrews <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]


On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Mark Andrews
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>
>
> On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Kim Ebert
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>
>
> On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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: [hidden email]
>
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Mark Andrews
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
> > On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Kim Ebert
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
> > On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Filter A records in an IPv6 only environment

Kim Ebert
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
> > On May 1, 2018 5:44 PM, "Mark Andrews" <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > 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: [hidden email]
> >
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [hidden email]
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]




_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users