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

From: Tom Deseyn <[email-masked]>
Date: Tue, 24 Dec 2013 20:56:34 +0100

The section you quote is called "Responding to Address Queries" and it
doesn't says whether it applies to the unsolicited messages which are sent
when an address is added/removed. So perhaps this can be made more explicit.
I checked on my system and avahi v0.6.31 does not include the additional
records.

Your comment on the NSEC assertion makes sense to me. It means that
querying for an A record includes the AAAA responses and vice versa. Such
responses can be a NSEC asserting the non-existence of the AAAA record.

Wkr,

Tom

On Fri, Dec 20, 2013 at 8:25 PM, Stuart Cheshire <[email-masked]> wrote:

> 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: Tom Deseyn <[email-masked]>
Date: Tue, 7 Jan 2014 23:18:08 +0100

Hi Stuart,

Do you have any further thoughts on this topic?

Thanks,

Tom

On Tue, Dec 24, 2013 at 8:56 PM, Tom Deseyn <[email-masked]> wrote:

> On Fri, Dec 20, 2013 at 8:25 PM, Stuart Cheshire <[email-masked]>wrote:
>
>> > RFC6762 states that a response on a query for an A record should
>> include AAAA answers and vice versa.
>> >
>> > 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.
>>

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 22 Jan 2014 21:49:07 -0800

On 20 Dec, 2013, at 12:11, Andrew Sullivan <[email-masked]> wrote:

> On Fri, Dec 20, 2013 at 11:25:24AM -0800, Stuart Cheshire wrote:
> 
>> 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?
> 
> 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.

My view is that the sender should put in any records that it can reasonably predict are likely to be of use to the receiver. It’s up to the receiver’s algorithm to decide what to accept.

I think it’s unlikely that a receiver will decide that it’s willing to accept an NSEC record asserting that, “this owner name has some A records but no AAAA records”, and then at the same time refuse to believe the actual A records provided in the same packet by the same sender. If it trusts the NSEC record to assert that the A records exist, why would it not trust the A records themselves?

Stuart Cheshire