2

Why can't Windows' Bonjour (the Apple one) automatically resolve foo.bar.local, when Ubuntu and macOS can?

foo.local instead is resolved without issues by every OS.

Here's my avahi-daemon.conf:

[server]
host-name=foo
domain-name=bar.local
...

This discussion mentions that Windows' Bonjour implementation does not support aliases, is this the culprit?

How does this tool differ from my solution?

EDIT: I don't want to set an alias. foo.bar.local is different from bar.local. I just want to have different hostnames under the same "domain". For example, foo.bar.local is 192.168.0.8 while foo1.bar.local is 192.168.0.9. I won't have foo.local, bar.local and foo.bar.local all in the same network. I will use foo.bar.local, with only foo varying (*.bar.local)

ThreeState
  • 21
  • 4

1 Answers1

0

From my current findings, this seems to be intentional. Excerpt from the source code (mDNSResponder-878.30.4, function NSPLookupServiceBegin in mdnsNSP.c):

    // <rdar://problem/4050633>

    // Don't resolve multi-label name

    // <rdar://problem/5914160> Eliminate use of GetNextLabel in mdnsNSP
    // Add checks for GetNextLabel returning NULL, individual labels being greater than
    // 64 bytes, and the number of labels being greater than MAX_LABELS
    replyDomain = translated;

    while (replyDomain && *replyDomain && labels < MAX_LABELS)
    {
        label[labels++] = replyDomain;
        replyDomain     = GetNextLabel(replyDomain, text);
    }

    require_action( labels == 2, exit, err = WSASERVICE_NOT_FOUND );

It returns an error if the name has more than two labels, as in the case of foo.bar.local.

In my tests, I just removed the last line. With the new build, it resolved names with multiple labels successfully. I did not yet encounter any side-effects so far.

Has anybody an idea about the intention behind not resolving multi-label names?

Daniel Pauli
  • 963
  • 1
  • 7
  • 8