Re: [lwip-devel] Q. should mdns be announcing an ip4 address of 0.0.0.0?

[Joel Cunningham]

On 12/29/2017 6:22 AM, Douglas wrote:
> Hi,
>
> Working on the mdns responder, and noticed that it sends out ipv4
> packets before the interface has an ipv4 address, so sends them out with
> a source address of 0.0.0.0 and announces an A record with address 0.0.0.0.
>
> This is when using dhcp to obtain the ipv4 address, so the interface can
> be up and ipv6 can be operational and announced even before ipv4.
>
> Every time the connection drops and reconnects it goes thought this
> announcement. Given that UDP is not reliable, might this be mdns less
> reliable.
>
> Would anyone know if this is the correct behaviour.
I've worked a lot with Apple's mDNSResponder and am familiar with RFC 
6762, hopefully my background can provide some guidance :)

> A. Should the mdns responder announce to an ipv4 broadcast address
> before the interface has an ipv4 address? If not then it could still
> announce to the ipv6 broadcast address before it has an ipv4 address.
I would say no because the responder is advertising services that can't 
be contacted by a remote host (due to the interface being down).

I can also think of other complications if multiple devices advertised 
conflicting service instances via a 0.0.0.0 address and the network 
traffic happened to be loopedback (how would you know which packets were 
from which device?)

IPv4 and IPv6 are treated as ships passing in the night and you can even 
think of them as separate .local. domains instances. See 
https://tools.ietf.org/html/rfc6762#section-20.  So advertising on IPv6 
when that link is up (but not IPv4) is completely fine.  Maybe the IPv4 
link never comes up.
> B. Should the mdns responder announce an A record of 0.0.0.0 before it
> has an ipv4 address? Might this flush out the address in case it
> changes, or would it be better to just skip announcing this A record
> until the address is obtained?
An A record with address 0.0.0.0 is definitely not correct.  In terms of 
how to flush old cache entries in remote caches, there are a couple 
different active mechanisms depending on what's happening with the resource:

1) If the resource record is going away, i.e. service is removed or the 
host is shutting down, then a Goodbye packet should be sent with a TTL 
of 0, but all the same rdata.  See 
https://tools.ietf.org/html/rfc6762#section-10.1

2) In the case where a device's link goes down after advertising an A 
record with a previous address, when the link goes back up (with new 
address), the device will Probe and Announce the new record with the 
cache flush bit enabled, causing the remote caches to be updated. See 
https://tools.ietf.org/html/rfc6762#section-10.2 and 
https://tools.ietf.org/html/rfc6762#section-8

Joel