ESP8266mDNS should send empty AAAA response

[Bluebie]

RFC 6762 Multicast DNS - Section 10:

As a general rule, the recommended TTL value for Multicast DNS
resource records with a host name as the resource record's name
(e.g., A, AAAA, HINFO) or a host name contained within the resource
record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
seconds.

The recommended TTL value for other Multicast DNS resource records is
75 minutes.

ESP8266mDNS's readme states you can pass a TTL value through the begin() method, but I don't see support for this in the source code. Through experimentation I've seen other mDNS devices on my network, like mac computers, have reasonable hostname TTLs and are responsive to access after an initial lookup, but esp8266/arduino devices are not - my computers seem to wait several seconds on an mDNS discovery query for every connection. This makes me think something is going wrong and the ESP8266mDNS library is failing to communicate a sensible TTL.

Anyone have a clue where this is going wrong? Something seems severely broken here.

To reproduce:

1. create a simple web server with an mDNS hostname
2. use curl to load a static resource from it repeatedly, using the mDNS hostname - make a note of how long each attempt takes
3. repeat the experiment using an IP address instead of mDNS hostname.

After the first mDNS query, for the following 300 seconds, mDNS addressed queries should be roughly as fast as IP addressed queries. They are when my test subjects are Mac's, they are not when the test subjects are ESP8266 devices running this arduino core.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[igrr]

I can see that TTL is currently hardcoded in several places in the code.
TXT — 4500
PTR — 4500
SRV — 120
Need to add _ttl member variable and use it in response generation as appropriate.

[igrr]

I can confirm this happens when using curl. However I noticed that this doesn't happen when i ping — it is as fast to start as when I use IP address, on consecutive attempts.
If i force curl to use IPv4, it becomes fast as well.
Here are times for 10 runs of curl, without -4, with -4, and with IP specified:

[igrokhotkov@localhost ~]$ time (for i in $(seq 1 10); do curl http://esp8266-800260.local 2>/dev/null; done)

real    0m50.366s
user    0m0.041s
sys 0m0.033s
[igrokhotkov@localhost ~]$ time (for i in $(seq 1 10); do curl -4 http://esp8266-800260.local 2>/dev/null; done)

real    0m0.957s
user    0m0.040s
sys 0m0.032s
[igrokhotkov@localhost ~]$ time (for i in $(seq 1 10); do curl http://192.168.77.105 2>/dev/null; done)

real    0m0.450s
user    0m0.040s
sys 0m0.031s

It appears that without -4, curl triggers a request for IPv6 address first, which is not in the cache because ESP never sends AAAA response. We should update ESP8266mDNS library to send an empty AAAA response.
But as far as i can tell, there is no issue with TTLs.

[igrr]

I have tried changing the code to send empty responses for AAAA requests (which should be the correct behaviour according to rfc4074): https://github.com/esp8266/Arduino/tree/mdns_answer_aaaa

This doesn't help, unfortunately, at least on OS X. I still get AAAA requests every time curl -6 is run.

(TCP RST is due to the fact that I don't have an HTTP server running on the ESP, but that shouldn't matter)

FYI, I'm not sure what else to try. Feel free to check the code linked above and see if you can figure out why AAAA requests are still being sent.

[me-no-dev]

I also tried everything that I can come up with. Sending empty response, no response, bad response... nothing seem to change the behaviour above.

[devyte]

@igrr @me-no-dev what is the status of this? It seems to me from the previous comments that code changes are needed for the ttl thing, but that there is still a problem with the AAAA response?

[jackjansen]

What is the status of this? I'm being bitten a lot by the lack of AAAA responses. I've looked for the changes @igrr mentioned (on 12-Jun-2016) to use as a starting point, but I cannot find them in the repo.