Can the F5 APM API Protection profile use for a DNS resolver a local F5 DNS/GTM listener VS?

I finally got to this (I upgraded to 16.1.3.2 from 16.1.3 so this could also be important) and I also tested with the pet store that was given as an example in https://support.f5.com/csp/article/K12744365?utm_source=f5support&utm_medium=RSS . With external DNS resolver (in my case google 8.8.8.8) it works like a charm and it seems to me that when referensing external or internal DNS resolvable API then the server mode is best used and when referensing a local pool of API servers then the pool mode is best used. My picture below is with the petstore servers without having a pool attached to the virtual server.

Now I have other issues as after intergrating with Azure AD as oauth provider and a sync of the public keys that are at https://login.microsoftonline.com/common/discovery/keys I see the F5 APM getting the keys every hour and they are correct but when I request a token with postman and get a correct token that I have checked at https://jwt.io/ the APM things that there is no valid key that signed the token but this seems like a Job for the support hah as the key is in the APM after I checked.

Nov 8 18:16:15 bigip1.com err apmd[12601]: 01490290:3: /Common/API-PETS_ap::77A02581./Common/oauth/HYQYY5JU7+XxiUmSSuLWgsiAtUEug9m2c9njSNvseiQ=:/Common/oauth_act_oauth_scope_subsession_ag: OAuth Scope: failed for jwt-provider-list '/Common/exampleJWTProvider' , error: None of the configured JWK keys match the received JWT token, JWT Header: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSJ9

I even dumped the token with a subsession variable just to see if the APM is getting the correct one with variable assign agent in the Per-Request API protection policy  " subsession.logon.last.jwt = expr { "[mcget {request.header.authorization}]"}  " and the logging agent "       %{subsession.logon.last.jwt}   " and it is the the same one in Postman and valid so enough of the support was done by me 🙂

I am closing this and as a recommendation an external DNS resolver going to an IP address not on the same F5 device needs to be configured. I may create an iRule and community Tech Article with TCP::collect and TCP::respond to see if this can be bypassed but that is in the future.

Edit:

I even checked when the web browser clients are using authorization codes and F5 exchanges them with Azure AD for tokens and validates them it works normally without an issue ( with https://support.f5.com/csp/article/K07645403 the tokens the F5 per-request policy gets under "subsession.oauth.client.last.access_token" can be decrypted but a logging agent is used as the per-request policy does not have message agent ) but when tokens are send directly to the F5 with postman for API protection well  it seems a bug to me.