Add hostname lookup support

[hadess]

Example output from the test tool (replaced the IPv6 address though):

$ ~/.cache/jhbuild/build/microdns/examples/host-lookup diskstation.local
diskstation.local resolves to IPv4 address 192.168.1.68
diskstation.local resolves to IPv6 address ffff:fff:ffff:ffff:fff:ffff:fffff:fffff

Please check carefully.

[jbkempf]

Looks good.

[hadess]

I found a couple of things while looking at using this implementation:

• in mdns_listen(), we should check whether the names end in either .local or .local. and reject them if not
• we should also check whether they have have a "label count" of 2 or less (eg. foo.local, not foo.bar.local)
• and in mdns_listen_probe_network(), we should check make sure that .local and .local. suffixes both match the hostnames

[jbkempf]

I found a couple of things while looking at using this implementation:
* in mdns_listen(), we should check whether the names end in either .local or .local. and reject them if not

Why being so strict here?

* we should also check whether they have have a "label count" of 2 or less (eg. `foo.local`, not `foo.bar.local`)

Same?

[hadess]

I found a couple of things while looking at using this implementation:

• in mdns_listen(), we should check whether the names end in either .local or .local. and reject them if not

Why being so strict here?

This is what nss-mdns does:
https://github.com/lathiat/nss-mdns#etcmdnsallow

* we should also check whether they have have a "label count" of 2 or less (eg. `foo.local`, not `foo.bar.local`)

Same?

Because that's not a valid .local hostname, as per draft-cheshire-dnsext-multicastdns.txt, so that must mean that a DNS has authority over the .local domain.

[hadess]

Note that I'm fine with removing those checks, that just means they would need to be done by clients.

[jbkempf]

Note that I'm fine with removing those checks, that just means they would need to be done by clients.

Good point. I would add a flag then inside the entries that are incorrect then. No? WDYT?

[hadess]

Good point. I would add a flag then inside the entries that are incorrect then. No? WDYT?

I'll give it a try.

[hadess]

I'll give it a try.

I answered this because I thought I would be able to make sense of it in the morning, but I couldn't ;)

Apart from checking that the hostname we're looking up matches one of the entries we received, we're not doing any checks once we've started listening to answers from the network.

All of the checks are done ahead of time, when calling _listen(), and we would return early on invalid inputs. We don't run any checks on network answers, but if we did, that's definitely when we would be flagging those entries. Did you want me to add that?

[jbkempf]

All of the checks are done ahead of time, when calling _listen(), and we would return early on invalid inputs. We don't run any checks on network answers, but if we did, that's definitely when we would be flagging those entries. Did you want me to add that?

Yeah, I thought you were going to add a flag on entries to see if they do or do not respect the spec

[hadess]

Yeah, I thought you were going to add a flag on entries to see if they do or do not respect the spec

I've looked through this, and I don't think it's strictly necessary for this particular feature, but I can implement it as a separate PR.

It would protect against dodgy answers from other network devices on the network, but that's already a problem with mdns_listen_probe_network() which sends all the answers if just one entry matches a service we requested.

To implement this, I would need to pass the rr_type from the request to check that the answer type is something we want (a service search shouldn't match a hostname lookup). Do we want to mark those answers of another type as invalid, or drop them altogether? Are answers for a hostname or service we didn't ask for valid or invalid? Should the callback be called for all the answers, or only if there are valid answers in the list of entries?

[hadess]

Was there anything else that would be needed to get this merged?