Subject: [dnssd] rfc6762 Multicast DNS A/AAAA additional records

From: Tom Deseyn <[email-masked]>
Date: Sat, 14 Dec 2013 14:03:08 +0100

Hi all,

RFC6762 states that a response on a query for an A record should include
AAAA answers and vice versa.

Would it makes sense to generalize this to requiring that additional A/AAAA
records should be added to any message which contains an A/AAAA record?

For example if a machine drops an IPv6 address this results in a message
with an AAAA record with ttl 0. The previous paragraph would mean that
other addresses still valid for this machine (IPv4 and IPv6) are included
in the message.

Wkr,

Tom

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 20 Dec 2013 11:25:24 -0800

On 14 Dec, 2013, at 05:03, Tom Deseyn <[email-masked]> wrote:

> Hi all,
> 
> RFC6762 states that a response on a query for an A record should include AAAA answers and vice versa.
> 
> Would it makes sense to generalize this to requiring that additional A/AAAA records should be added to any message which contains an A/AAAA record?
> 
> For example if a machine drops an IPv6 address this results in a message with an AAAA record with ttl 0. The previous paragraph would mean that other addresses still valid for this machine (IPv4 and IPv6) are included in the message.

Yes, this makes perfect sense.

RFC 6762 says:

   When a Multicast DNS responder places an IPv4 or IPv6 address record
   (rrtype "A" or "AAAA") into a response message, it SHOULD also place
   any records of the other address type with the same name into the
   additional section, if there is space in the message.  This is to
   provide fate sharing, so that all a device's addresses are delivered
   atomically in a single message, to reduce the risk that packet loss
   could cause a querier to receive only the IPv4 addresses and not the
   IPv6 addresses, or vice versa.

So, I think this correctly covers the case of a AAAA record with zero TTL.

An interesting question would be if we should apply this more generally: If a device sends a response message containing an NSEC asserting the non-existence of a AAAA record, should it also volunteer any A records that do exist for that name?

Stuart Cheshire

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Dec 2013 15:11:27 -0500

> An interesting question would be if we should apply this more generally: If a device sends a response message containing an NSEC asserting the non-existence of a AAAA record, should it also volunte…

In the old-fashioned DNS, of course, such a record would be ignored as
probable poison.  If you expect to re-use resolution libraries, then
the answer to the above is therefore "probably not", but if you expect
the libraries to be completely different them I can't see any harm.

A

-- 
Andrew Sullivan
[email-masked]