Service discovery fails when A/AAAA records arrive before SRV records - entries incorrectly marked as incomplete

[tq-kuehnem]

Problem

The library processes DNS records sequentially and immediately creates/updates ServiceEntry objects in the inprogress map. An entry is only considered complete when it has an IP address, port, and TXT record. However, when DNS records arrive in certain orders, the library creates multiple separate entries that never become complete.

Failure Scenario

1. PTR
2. A (arrives before SRV)
3. SRV
4. TXT

The library creates two separate entries:

• Entry for device.local. with an IP, but no port/TXT -> incomplete
• Entry for device._service._tcp.local. with port/TXT, but no IP -> incomplete

I encountered this problem with the Alfen EV Charger, but there may be more devices, that send DNS Records in that order. Here are the actual records send by the Alfen:

mdns: PTR Record - Name=_alfen._tcp.local., Ptr=ng910-60583-ace0175107._alfen._tcp.local.
mdns: A Record   - Name=ng910-60583-ace0175107.local., IP=10.121.63.134
mdns: SRV Record - Name=ng910-60583-ace0175107._alfen._tcp.local., Target=ng910-60583-ace0175107.local., Port=443, Priority=0, Weight=0
mdns: TXT Record - Name=ng910-60583-ace0175107._alfen._tcp.local., Txt=[ContentType=alfen-ace-v1/json Identity=ACE0175107 Type=1.1.1 SCNNetwork= LastConfig=1764777474213 FWVersion=7.3.0-4377 euaEnabled=0 euaConfigured=0 ]

A working example for the Keba Charger is here:

mdns: PTR Record - Name=_rest-P30-keba-wallbox._tcp.local., Ptr=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local.
mdns: TXT Record - Name=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local., Txt=[devicename=KeContact P30 x-series serialnumber=20963750 alias=KeContact P30 x-series]
mdns: SRV Record - Name=KeContact\ P30\ x-series._rest-P30-keba-wallbox._tcp.local., Target=p30.local., Port=8443, Priority=0, Weight=0
mdns: A Record   - Name=p30.local., IP=10.121.61.206

Root Cause

The alias function is called when SRV.Target != SRV.Hdr.Name, but by that time the A-record has already been processed and associated with the wrong entry name ng910-60583-ace0175107.local. instead of ng910-60583-ace0175107._alfen._tcp.local.. So the alias mapping doesn't propagate the IP address to the service entry.

Expected behaviour

Device discovery should work regardless of DNS record ordering. The mDNS specification (RFC 6762) does not mandate a specific order for records in responses.

Question

Is it planned to improve the alias function or may there be another fix for that problem? Or is there a fork that already does this?

[tq-kuehnem]

I was able to track that problem down to the alias function which overrides the ServiceEntry, that has the IP. We can avoid loosing the IP, if we preserve that IP address for the alias. The code would look like:

func alias(inprogress map[string]*ServiceEntry, src, dst string) {
	srcEntry := ensureName(inprogress, src)

	// Preserve IP addresses from existing dst entry if it exists
	if existingDst, exists := inprogress[dst]; exists {
		if existingDst.AddrV4 != nil && srcEntry.AddrV4 == nil {
			srcEntry.AddrV4 = existingDst.AddrV4
			srcEntry.Addr = existingDst.AddrV4 // @Deprecated
		}
		if existingDst.AddrV6 != nil && srcEntry.AddrV6 == nil {
			srcEntry.AddrV6 = existingDst.AddrV6
			srcEntry.AddrV6IPAddr = existingDst.AddrV6IPAddr
			if srcEntry.Addr == nil {
				srcEntry.Addr = existingDst.AddrV6 // @Deprecated
			}
		}
	}

	inprogress[dst] = srcEntry
}