Resloving local IP address

Hi! My router has the function of resolving local addresses through regular DNS queries. But Freertos tries to use only mDNS or LLMNR to resolve local addresses. Are there any ways to do this? Alternatively, by changing this line

  /* Is this a local lookup? */
        if( ( bHasDot == pdFALSE ) || ( bHasLocal == pdTRUE ) )
change to this
        if ( bHasLocal == pdTRUE )

This code works correctly, but is it the right thing to do?

Hi @pistoletov1974,
If your router supports DNS query, I would recommend configuring it as your DNS server, rather than relying on mDNS or LLMNR. This approach would allow all DNS queries from your device to be directed through the router, ensuring address resolution for other local devices on your network.

Thank you.

Hi, @ActoryOu

I did so, but in the FreeRTOS stack CODE , if the name does not contain dots or has an extension .local DNS only works through mdns or llmnr.

Hello @pistoletov1974,

Yes, I think that code change looks correct. Following the path this approach will follow, it seems that it should behave correctly.

I am curious though, why not use mDNS/LLMNR to resolve the local address?

The device I need to find on the network is a black box that does not support mdns/llmnr. This is a microcontroller device with rather limited functionality

1 Like

Thanks for response. I was wondering if you could kindly provide an example of the domain name you’re using? And how do you set the domain name on your router for query? In my opinion, the hostname is usually defined with dot, such as www.amazon.com. That bHasDot, defined for LLMNR, referred to this line, doesn’t consider the case about local query without dot. You might be facing a corner case, but we want to have more detail from you about local settings.

Thank you.

In Keenetic routers, you can enable the ability to add static records to the DNS proxy when issuing DHCP addresses. This feature is disabled by default. To enable it, use the command: (config)> ip dhcp pool _WEBADMIN update-dns.

The pictures below show several examples of determining device addresses from a local network. These names are stitched into the devices and communicated to the router during the DHCP process

Local addresses are usually and naturally resolved by using mDNS and LLMNR, therefor what +TCP does is completely logical and correct. I don’t have quotes from the relevant RFCs on hand, but +TCP acts exactly as it should.

DNS servers usually resolve hosts from different domains or zones.
Having a DNS server that happens to have access to the hostnames reported to the DHCP server is an optional feature and is not the norm. This feature is only possible when the DNS and DHCP servers run on the same host and are designed to interact with each other. This behavior is optional and is by no means standardized.

Because of the above, I believe +TCP’s default behavior should not be changed.

Maybe it makes sense for edge cases lake this to make use a special define that forces all name queries to the DNS server or maybe if mDNS and LLMNR are disabled, then fall back to DNS queries.

4 Likes

Thanks for the detail! If I may suggest, LLMNR/mDNS are typically used for local domain queries, which might not apply in your situation. Perhaps consider renaming your local domain names to include a dot, such as espressif.keenetic, if that’s feasible for you.

@epopov, I totally agree your opinion. But for the fallback, there are some security concerns about using dotless domain name. Thus I’m not sure if it’s a good idea to fallback name queries to DNS server even when mDNS/LLMNR are disabled.

1 Like