DNS-Client (FNET-library) doesn't resolve Azure Table Storage URLs

Question

I have noticed that on a Microcontroller board (Teensy 4.1), which uses FNET library as a dns-client, URLs of Azure Table Storage accounts in the form of 'myaccount.table.core.windows.net' are not resolved, apparently because of the use of CNAME records in the dns-response.
Now I'm interested in a statement of Microsoft and I'm searching for participants in the discussion whether this is an issue of the FNET library or not and whether relevant RFC dns rules are violated if such URLs are not resolved.
https://github.com/butok/FNET/issues/7
https://stackoverflow.com/questions/67421802/should-rfc-conform-dns-clients-resolve-urls-of-azure-table-storage-accounts-whic
Thanks in advance
RoSchmi

Answer 1

@Roland Schmidt
Apologies for the delay following up here. I have spoken with our Azure Table Storage service team and they advise that this doesn’t appear to be specific to Azure Table Storage as there is documented issues with other urls and it seems to only impact this DNS client. They believe this is likely a bug with the DNS client.

I am looping in our IoT team to see if they can possibly provide some assistance or more information.

Answer 2

@deherman-MSFT Thanks for your answer, which is in accordance with my personal point of view.
However, as I interpret the statements of the owner of the 'FNET' library, they only seem to accept arguments expressed in terms of 'non correspondence with a RFC' of their FNET library.
As I think, either the FNET dns-client must be incomplete or faulty or the rr-records used by Azure must be not covered by the relevant RFC rules.
Perhaps it would be helpful to let the authors of FNET rethink their implementation of the FNET dns-client if someone of the Azure team could express the conformity of the rr-records used by Azure in terms of RFC rules.
I'll set a link to this thread in my 'Issue' inthe FNET Github repository.