Normalize network hostname lookup

[thromel]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Network attachments are allocated under the hostname supplied by the runtime, while DNS queries are canonical DNS names and may include a trailing dot. DNS hostnames are also case-insensitive. Because AttachmentAllocator keyed hostnames exactly as supplied, a container allocated as web could fail lookup when the embedded DNS path queried web..

This normalizes allocator keys by lowercasing hostnames and treating a single trailing dot as optional across allocate, lookup, and deallocate. The original hostname remains preserved in the returned attachment.

This is a narrow fix for the embedded DNS lookup path. First-class Compose-style bare service discovery from containers through the network gateway is a separate feature request: #1809. Related DNS discussion: #856.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

Checks run:

swift test --filter AttachmentAllocatorTest
swift test -c debug -Xswiftc -warnings-as-errors --filter AttachmentAllocatorTest

Additional manual validation:

• On released container 1.0.0, created a custom network and container; direct dig @127.0.0.1 -p 2053 <container-name> A returned no A record.
• With this patched debug build installed under a temporary /tmp install root, the same direct queries returned the allocated container IP for both <container-name> and <container-name>..

[jglogan]

@thromel I'll need to go back to the DNS refactor PR and look at our design decisions there, and then look at what the change is doing here.

[devops-thiago]

Supporting data for this fix, plus one gap it leaves open.

We hit the same bug on container 1.2.0. With a container named dnsweb running, the hostnames resolver on 2053 answered NXDOMAIN for dnsweb.:

$ dig @127.0.0.1 -p 2053 dnsweb. A +short
(no answer, status NXDOMAIN)

After normalizing the lookup the same query answers with the container's address, so the trailing-dot handling here fixes a real failure, not a theoretical one.

The gap: queries that arrive domain-qualified still miss after this change. A resolver file written by container system dns create test routes queries to this server as dnsweb.test., and after dot-stripping the allocator is asked for dnsweb.test while the key is dnsweb. So the documented opt-in path stays broken for exactly the queries it is designed to route.

Two ways to close it: strip the registered local domain suffix before lookup, or fall back to the first label after an exact miss. The first-label version is only sound if attachment hostnames can never contain a dot; if they can, suffix-stripping against the known domains is the safe one. In a downstream patch we went with first-label fallback (the names there are always single labels) and dnsweb., dnsweb.test. and dnsweb.container.internal. all resolve to the same address, with unknown names still NXDOMAIN.

Happy to send a follow-up PR for the suffix handling if that is easier than folding it in here.

[thromel]

Thanks for the concrete reproduction and for confirming the trailing-dot fix on 1.2.0. You’re right that this patch only canonicalizes case and a single trailing dot; it won’t map dnsweb.test. back to the stored dnsweb key. I also agree that stripping a known registered suffix is safer than a blanket first-label fallback if dotted attachment names are valid. A focused follow-up with bare-name, registered-suffix, and unknown-name tests seems like the clearest way to evaluate that behavior separately from this narrow fix.