IPv6 configuration on auth0 tenant domain

Recently our iOS app got rejected with the following message.

We discovered one or more bugs in your
app when reviewed on iPhone and iPad
running iOS 11.0.2 on Wi-Fi connected
to an IPv6 network. Specifically, when
we attempt to login with the provided
demo account credentials, your app
produces no further action.

We are using the “implicit grant” strategy for authentication of our ionic (v2) app and as you can read in the message above, they can’t login on their IPv6 only network. Apple advised ( in their docs “Limitations of Local Testing”) to use the following test to test if the API is IPv6 ready.

Our API is ready for IPv6 according to this test it checks for an AAAA records in the DNS configuration, which our API endpoint has. We’ve also run the test on the auth0 domain we’re using but that does not have an AAAA record configured.

We strongly believe that there in lies our problem. When authenticating we redirect, via an in app browser, to a [tenant].eu.auth0.com domain, which doesn’t have a AAAA record configured. Tested via MXtoolbox.

Also our hosted login page has a reference to “https://cdn.auth0.com/js/lock/10.18/lock.min.js” which also does not have a AAAA record configured.

alt text

  1. Has anyone else encountered this issue?
  2. Will the missing AAAA records be configured any time soon or are there other ways to solve this?

There are a couple of things worth noting here, like you said, both the CDN and the [domain].auth0.com won’t respond with a AAAA record (that is inherent to the underlying infrastructure being used which is also a common one used globally; spoiler alert, it’s AWS).

In addition, given this is something common to all Auth0 service accounts I’m doubtful that the record is a real blocking issue. In addition, I’ve seen some other reports of this situation and in some even the simple re-submission of the application (without changes) lead to a different outcome. I’m not suggesting that this would be the case here, but I would entertain the possibility of the root cause being something else than the AAAA record.

If you haven’t done so already, have you tried the suggested setup of a local IPv6 DNS64/NAT64 network with your Mac in order to test the flow locally. I understand this is not a completely equivalent test, but it would be something to try in order to see if it could get you additional information.

Also you state that your own API has the AAAA record so do ensure that it does support IPv6 for sure and is not just incorrectly configured to say it does. As a final note, you also mention the use of the implicit grant which for a native application is not really the recommendation (the use of PKCE would be the recommendation). However, both implicit and PKCE are redirect-based so that may not be relevant for the issue in question.

@tom4 Hi, we have the same problem. How did you solve it?

Our ios app got rejected with the following message:

“We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 11.0.2 on Wi-Fi connected to an IPv6 network. Specifically, when we attempt to login with the provided demo account credentials, your app produces no further action.”

We use https://companyName.auth0.com/authorize?
![alt text][1]

@tom4 Hi, we have the same problem. How did you solve it?

Our ios app got rejected with the following message:

“We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 11.0.2 on Wi-Fi connected to an IPv6 network. Specifically, when we attempt to login with the provided demo account credentials, your app produces no further action.”

We use https://companyName.auth0.com/authorize?
![alt text][1]