[lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - affecting probing

[Jasper Verschueren]

Follow-up Comment #4, bug #58142 (project lwip):

Hi David,

I went through the RFC6762 probe tiebreaking section again and noticed
something that proves the bug report is valid.

In RFC6762 section 8.2.1., Simultaneous Probe Tiebreaking for Multiple
Records, you can read the following:

   The records are sorted using the same lexicographical order as
   described above, that is, if the record classes differ, the record
   with the lower class number comes first.  If the classes are the same
   but the rrtypes differ, the record with the lower rrtype number comes
   first.  If the class and rrtype match, then the rdata is compared
   bytewise until a difference is found.  For example, in the common
   case of advertising DNS-SD services with a TXT record and an SRV
   record, the TXT record comes first (the rrtype value for TXT is 16)
   and the SRV record comes second (the rrtype value for SRV is 33).

The example given states that for a DNS-SD service both TXT and SRV record are
found in the authority section.
This proves that the TXT record should be in.

If we go back to the previous discussed section 8.2 Simultaneous Probe
Tiebreaking:

   When a host is probing for a group of related records with the same
   name (e.g., the SRV and TXT record describing a DNS-SD service), only
   a single question need be placed in the Question Section, since query
   type "ANY" (255) is used, which will elicit answers for all records
   with that name.  However, for tiebreaking to work correctly in all
   cases, the Authority Section must contain *all* the records and
   proposed rdata being probed for uniqueness.

The in previous comments discussed key word is *uniqueness*.
I think uniqueness refers to the group of related records with the same name
being probed for.
Not to the records answering that query.
So it's not about the rdata being unique but about the service name being
unique.
As they again give an example of a group made from a SRV and TXT record, this
tells me the TXT record should be in.

To explain this differently, lets use an example:
We host a DNS-SD service, being http.
Our hostname is device1.
So the service name is: "device1._http._tcp.local"
We want that service name to be unique on the network.
So we probe that service name.
It is asked to use query type ANY, so we only have one query.
I now see two scenarios, depending on the TXT record being in the authority
section or not. 

1. The TXT record is not in. This means we do not think the TXT record is a
valid answer to the query we just send out.
We also do not think that this TXT record answer needs to be unique.
This means that if a host on the network says it has a TXT record for the
service name you want to own, you would ignore it.
This does not sound correct.
2. The TXT record is in. This means we do want to be the only one having a TXT
record for this service name.
This makes sense to me. 
By including the TXT record we are now certain that no other user on the
network will respond to a TXT record query with our name. 
And that is the complete point of the probing step.

It was previously said that the TXT record shouldn't be unique.
But actually it needs to be unique. 
The TXT record is directly related to the service name containing the device
hostname. 
I do not see why we make a difference between the SRV and the TXT record.
They both need to be unique.
There contents / rdata however is indeed different. 
The SRV record contents again refers to the hostname, which we want to be
unique.
The TXT record contents on it's own does not need to be unique in the network.

It just contains some text information, if it contains anything at all.
So not the TXT content but the TXT record needs to be unique.

I think Apple is following there own standard here and this deviates from the
by RFC6762 defined standard.
The legacy implementation isn't always correct, and we shouldn't copy it's
mistakes.

I think the question boils down to: does lwIP follow the RFC or does it follow
Apple.
Since we refer to the RFC a lot and we call it mDNS and not Apple Bonjour, I
suggest we follow the RFC and revert this commit.

Kind regards,
Jasper 

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?58142>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/