DNS lookup should take into account available source IPv6 and IPv4 addresses (IDFGH-12201) #13255
Comments
github-actions
bot
changed the title
|
I now have a pull request up with a fix implementing the RFC 6724 algorithm to select the best destination address to return from The problematic example -- connecting TLS to a dual-stack host from an IPv6-only network -- now works. The logs show both DNS results, and then the selected one; because the device is in an IPv6-only network, the IPv6 address is selected. If connected to an IPv4-only network then the IPv4 address is used. Full log on the same IPv6-only network as in the bug report. The new function logs are prefixed with dns_select, and you can see RFC 6724 Destination Address Selection Rule 2 determines the IPv6 destination address has a source address with a matching scope (both global) whereas IPv4 does not (while the DNS result is global the device only source address is localhost, which is link-local scope). The same configuration, running on an IPv4-only network, uses the IPv4 address: |
sgryphon
changed the title
espressif-bot
added
Status: In Progress
|
@espressif-abhikroy |
|
Hi. Does anyone have any information about this issue? I believe I'm having a related issue, on an IPv4 network, the way that LWIP does DNS result ordering seems to be returning IPv6 IP first, and when it does, HTTPS connection to a server fails. It seems to happen more frequently when a server has 3 or more IPv6 addresses (ie. securetoken.googleapis.com), like there is some kind of limit in how many records LWIP reads and if it doesn't find an IPv4 in the first few records it returns an IPv6. I tried disabling IPv6 on menuconfig, but then it simply does not resolve the server. I found this on https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/lwip.html#ipv6-support :
but I'm not sure if I can change this value or how. I tried adding it in "\components\lwip\port\esp32\include\lwipopts.h" but I see no change, getaddrinfo still responds with a single IP. Looking at the code in netdb.c, and it seems DNS_MAX_HOST_IP is not used anywhere and there are no loops to fill the getaddrinfo or gethostbyname() results with more than 1 value. 🤔 |
@ivancmz Thanks for reaching out. The LWIP DNS component does not perform any reordering of IP addresses; it returns them in the exact order they are received from the DNS server. If you're specifically looking for an IPv4 address, please try calling getaddrinfo() with the AF_INET family, which should return an IPv4 address instead of IPv6. By default, LWIP returns only one IP address per DNS query. If you expect to receive more than one IP address, you can adjust the DNS_MAX_HOST_IP value to a higher number. To increase this setting, please follow these steps:
Navigate to:
This setting determines the maximum number of IP addresses stored per host. If the server returns multiple IP addresses, the actual number stored will be the smaller of either the configured value or the number of addresses returned by the server. If you're unsure of the DNS server's behavior and need a tool to investigate, you may consider adding this managed component to your project: This component provides a console interface, enabling you to run commands like getaddrinfo, get/setdnsserver, ping, and others. If connectivity is available, you can run:
This will allow you to verify the addresses returned by the DNS server. Alternatively you can simply use this project This project demonstrates how to use the console commands effectively. |
@AxelLin @sgryphon There is an issue with the LWIP getaddrinfo() call when using the AF_UNSPEC family. On Linux and macOS, calling getaddrinfo() with AF_UNSPEC returns both IPv4 and IPv6 addresses according to the To address this, I am adding a function in examples/common_components/protocol_examples_common that will implement similar behavior. With this change, getaddrinfo() will be able to return both IPv4 and IPv6 addresses up to the DNS_MAX_HOST_IP limit. I am in the process of getting this change reviewed and it should be available soon. |
|
Hi @espressif-abhikroy thank you very much for such a complete answer! Quick question regarding:
Do you know from which version of the idf onwards do these settings exist? only on master? |
This setting is available on the master branch and has been backported to version 5.2. It will also be included in the upcoming 5.3 release. |
|
Hi, I've been testing with "Maximum number of IP addresses per host" set to 10, and getaddrinfo(). On some IPv4 networks I get a result with 4 IPv6 addresses and 0 IPv4 addresses for a particular server (securetoken.googleapis.com), so I'm still not able to resolve a usable address. The reason I'm getting 4 results seems to be a timeout. I've been looking at the code on dns.c and netdb.c but I can't figure out where this timeout is set and if it might be changed. Is it possible to change this timeout? |
@ivancmz Unfortunately, the timeout is not configurable at this time. However, you can modify the number of retries by adjusting the Please note that this change needs to be made directly in the header file, as it cannot be modified via menuconfig. You may try increasing the value, and if it resolves the issue, kindly inform us if you require this option to be configurable through menuconfig. We can then consider incorporating this into the LWIP DNS configuration. Also make sure the DNS server(securetoken.googleapis.com) actually can return IPv4 address. |
|
Hi @espressif-abhikroy thanks for your help. I don't see much difference in behavior when adjusting the DNS_MAX_RETRIES macro, even with a value of 200. It would be nice that this setting could be tweaked in menuconfig, but since it appears to have little or no effect, I guess it's fine as it is. I'm thinking that the problem I'm experiencing is more on the DNS server side, I'll try to capture DNS traffic to find out more. |
espressif-bot
added
Status: Done
|
The This issue has been addressed in commit e2ae81a. However, the feature is currently disabled by default. |
I would have to check (e.g. on a Linux system), but Happy Eyeballs should only apply to dual-stack clients; the situation above was specified as an IPv4 network -- on an IPv4 only network, there is no point in trying IPv6 addresses at all (and vice-versa on IPv6 only network). Also the implementation linked above appends the IPv6 addresses after the IPv4 addresses. Happy Eyeballs (RFC 6555) specifies to use them in host address preference order (which is usually IPv6 first), and if that is not available, then "implementations MUST prefer IPv6 over IPv4". i.e. on a dual-stack client you should have the IPv6 addresses first, and then the IPv4 after. (On a single stack client, then you only need the relevant stack). For Linux at least in the docs, "The sorting function used within getaddrinfo() is defined in RFC 3484;", see https://man7.org/linux/man-pages/man3/getaddrinfo.3.html This was later obsoleted by RFC 6724 Default Address Selection for IPv6. The fix I proposed, in https://github.com/espressif/esp-idf/pull/13258/files, which relies on changes in ESP-LWIP espressif/esp-lwip#66 does follow the RFC 6724 algorithm, the same as Linux. (i.e. on an IPv4 only network, it will return the IPv4 addresses first). |
The changes in e2ae81a do not fully implement the Happy Eyeballs algorithm. Instead, they introduce a mechanism to make separate queries for IPv4 and IPv6 addresses when the The changes suggested in PR #13258 and espressif/esp-lwip#66 were made at a time when lwIP returned only a single IP address for any query. Currently, the number of IP addresses that lwIP can return for a DNS query is configurable using |
espressif-bot
added
Status: In Progress
Answers checklist.
IDF version.
master
Espressif SoC revision.
ESP32
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
M5Stack Core 2
Power Supply used.
USB
What is the expected behavior?
With both IPv4 and IPv6 fully enabled, DNS lookup (via TLS) should work correctly in all network environments -- IPv4-only, IPv6-only, and dual-stack, for all reachable destinations, by taking into account available addresses.
For example when moving a device to an IPv6-only network only an IPv6 address is available (even though IPv4 is enabled), and so connections to a dual-stack host (that has both) should use the IPv6 address to make the TLS connection.
For this particular bug:
But the connection fails.
What is the actual behavior?
TLS connections fail on an IPv6-only network when connecting to a dual-stack destination, because the preference order is statically configured to IPv4 first. Even though a local IPv4 address is not currently available, for a dual-stack destination the IPv4 address is returned by
getaddrinfo()(instead of the IPv6), so the connection fails.Note that if you disable IPv4, then the connection works; if you enable IPv4 then then connection fails. Enabling IPv4 should not make IPv6 fail (and vice-versa).
Steps to reproduce.
A kind of work around is to reconfigure the application to entirely turn off IPv4, however this then stops the application from being able to roam to different network types and connect to IPv4 only servers.
Debug Logs.
More Information.
Issue
The DNS lookup function getaddrinfo() does not take into account available source address, and so does not work propertly across all network types.
In particular it preferences IPv4 over IPv6, and completely fails in an IPv6-only network for a dual-stack destination, as the IPv4 address is unreachable.
You can work around this in some cases, by checking available addresses yourself and then calling getaddrinfo() multiple times -- this approach has been used in the updated http_request example.
However HTTP is not secure and the same approach can't be used with HTTPS, as the host name is needed to TLS and resolved internally in the TLS code.
Technical details
For the https_request example the TLS code
esp_tls.ceventually callsgetaddrinfo()passing inAF_UNSPECto get any address.However the code in
netdb.cthen converts this into a fixed preference order (when both IPv4 and IPv6 are enabled) ofNETCONN_DNS_IPV4_IPV6.A client with both IPv4 and IPv6 enabled should work in any network IPv4-only, IPv6-only, or dual-stack, and to any reachable destination.
Changing to use a static order of
NETCONN_DNS_IPV6_IPV4wouldn't fully work either.This other order allows IPv6-only to work, and means that dual-stack preferences IPv6 and still falls back for IPv4-only destinations.
But it has the reverse problem that in an IPv4-only network a dual stack destination will fail, as it returns the unreachable IPv6 address.
Proposed solution
To be able to work across all networks, the address selection needs to be dynamic based on what is actually available. (Not static based on what is enabled in configuration)
For a dual-stack destination, if a global (including ULA) IPv6 address is available, then use IPv6, but if it a gobal IPv6 address is not available (even though IPv6 is enabled it may not be provided, e.g. if currently on an IPv4-only network) then the IPv4 address needs to be used.
A full implementation of this approach is detailed in RFC 6724, taking into account not only what addresses are available, but their scopes and with special allowances for deprecated address ranges.
Available addresses should be sorted according to RFC 6724, with the application using the first address returned.
The standard linux function
getaddrinfo()takes this approach "The sorting function used within getaddrinfo() is defined in RFC 3484" (RFC 3484 was replaced by RFC 6724). See https://man7.org/linux/man-pages/man3/getaddrinfo.3.htmlThis new DNS resolution dynamically based on available addresses could be configuration flagged to allow the old behaviour (fixed prefrence of IPv4) to continue to be an option.
The text was updated successfully, but these errors were encountered: