Class Unique fix - #217

@jstasiak, I’m not expecting you to be prepared to merge this yet, but wanted to have you look over where this is going and see if there is anyone you know of who could help review these changes as I appreciate you mat not be familiar with the spec as we discussed before.

Cheers, I'll have a look at the patch (and at the specs to educate myself) some time this week.

Having looked through the spec and the code, there are a number of areas that I have concerns about, what’s your view on how you’d like to work on these? Perhaps discuss via Slack? Also do you think that a number of your other contributors might like to collaborate on this?

If no one else chimes in here we're on our own I'm afraid. I'd say discussing things here is all right.

Ok, I’ll reopen this PR to debate this one and raise some issues on the main page to discuss each concern to see if anyone else chimes in

I'd love to participate in discussion, but I don't remember what CLASS_UNIQUE exactly does and have no time right now to dive into RFCs.. Could you at least point to the exact paragraph where it's discussed @mattsaxon?

The _CLASS_UNIQUE bit sets the cache-flush bit in the class field.

Here is the portion of the spec that refers to it https://tools.ietf.org/html/rfc6762#section-10.2

Also see https://tools.ietf.org/html/rfc6762#section-2 on unique vs shared records.

Effectively, the _CLASS_UNIQUE bit tells the client cache to flush, i.e. the responder is saying I own this record (set) so you should remove all other references to this record in your cache.

@dtantsur for your use case, I believe the right way is to;

1. not flush the cache (i.e. don't set the cache-flush bit with _CLASS_UNIQUE)
2. this needs to be done for TXT and SRV records as you say (I'm not sure about how PTR records and A/AAAA should work as yet)

The complexities I can see with this are.

1. knowing what are 'compatible' TXT and SRV records may be difficult for python-zeroconf to know, it may need to be controlled at a high layer of the protocol, i..e outside of python-zeroconf

2. that python-zeroconf seems to have not been designed with this mode of operation in mind (i.e. I think the intent is for these records to be unique, hence this PR)

Can you outline the sort of records that you think you want to publish (PTR, SRV, TXT and A/AAAA) so I can get my head around how you think this should work (i.e. the second mode of operation). Note I suspect this might be documented, at least to some extent in https://tools.ietf.org/html/rfc6763, but haven't yet read it in any detail.

I'm publishing A, AAAA, TXT and SRV. They're published completely the same from all responders, so UNIQUE will probably work, but I'm not exactly sure.

Thanks for the feedback. Glad this shouldn’t conflict with your use case.

Would you be able to rest this for me or do you need other changes....

Have you had a chance to review my proposal on #163?

@jstasiak, this commit is actually a good one! This failure is worth you taking a look at, I've been having intermittent failure such as this pretty much as long as I can remember, do you ever see them? If you click restart build, I suspect it will pass. The failure only occurs sometimes and in a typical build set will only fail one build. Have you seen this before?

Having looked through both RFC6762 and RFC6763 now quite a bit, I'm convinced the implementation is correct.

Here are the section that justify this;

For PTR records, they should be shared

https://tools.ietf.org/html/rfc6762#section-8.3
In the case of shared records (e.g., the PTR records used by DNS- Based Service Discovery [RFC6763])

For A and AAAA record, they should be unique

https://tools.ietf.org/html/rfc6762#section-6
For unique records, where the host has already established sole ownership of the name, it MUST return negative answers to queries for records that it knows not to exist. For example, a host with no IPv6 address, that has claimed sole ownership of the name "host.local." for all rrtypes, MUST respond to AAAA queries for "host.local." by sending a negative answer indicating that no AAAA records exist for that name

This implies that SRV records should also be unique
https://tools.ietf.org/html/rfc6762#section-8.1
For example, a host can simultaneously probe for uniqueness of its "A" record and all its SRV records [RFC6763] in the same query message.

Since SRV and TXT records come together, the TXT records should therefore also be unique.

I restarted the build, once it passes this can be merged I think.