Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional records aren't sent in response to PTR queries #76

Open
jorgensigvardsson opened this issue Aug 30, 2023 · 9 comments
Open

Comments

@jorgensigvardsson
Copy link

When querying for instance mDNSResponder, records associated with the service being queried are returned in the response. mdnsd does not attach any such records.

Is this behavior set in stone, or is it open for change?

@troglobit
Copy link
Owner

I'm guessing you're using the Apple mDNSResponder reference daemon, does Avahi (standard Linux daemon) behave the same? I'm not sure that it does, maybe if you query for Avahi, but I don't think so. In any case I'd like to understand where in RFC6762 this behavior is defined.

To be clear, I'm not closing the door on this suggestion, but if we do anything to mdnsd it should aim to be as RFC compliant as possible.

@jorgensigvardsson
Copy link
Author

It looks like Avahi does not respond with additional records, but mDNSResponder (Apple) and Google's Chromecast. It's not a big deal that it doesn't respond with additional records (on PTR queries), but it sure is convenient, because one does not have to query multiple times for other information (such as SRV and TXT records).

I did try to hack it myself on a fork of mdnsd, but I think I'm too dense for it. Couldn't quite grok the records and queues in the code.

@troglobit
Copy link
Owner

OK, then I understand. Thank you for taking the time to explain!

We'll leave the issue open and maybe someone (me?) will have a look at it later :-)

@jorgensigvardsson
Copy link
Author

jorgensigvardsson commented Sep 2, 2023

I might look into it myself, just need to grok the mechanics of the rr's around.

I will definitely do some OSS contributions to the client library I'm using, because it only covers the "Chromecast use case". I think a PTR response is all I need at the moment anyhow. The day I need versioning and subsequently TXT records, I might take the plunge into mdnsd! Tight schedule right now. 😅

@jorgensigvardsson
Copy link
Author

jorgensigvardsson commented Sep 2, 2023

If I get the chance to add this behavior, I presume you'd want it to be configurable? Big switch such as --chrome-cast-like, or --add-aditional-record-types SRV,TXT?

@troglobit
Copy link
Owner

Yeah, having it configurable when it's non-standard behavior is probably best.

@MonkeyBreaker
Copy link
Contributor

Hey everyone,

Sorry to get into the on-going discussion, but I think I already did some work related to this. I unfortunately did not have the time to polish my WIP. But maybe it could be interesting for any of you, to continue over what I did or maybe just inspire for a solution. If it helps, I will be more than glad to review the solution.

In any case I'd like to understand where in RFC6762 this behavior is defined.

This is a feature from RFC6763.

My fork about this, should be rebased on latest master. As I said, it is a solution I did in the past, I remember it seemed to work, but I was not 100% happy with the implementation. My biggest concern was that the way I create the relation between the PTR and SRV, TXT, A and AAAA. And also if you query SRV, you should also get A or AAAA.

Let me know if I can be of any help. As I said, I unfortunately don't have a lot of time. But, if we can integrate a solution about this in mdnsd, I would definitely enjoy using it.

Best,
Julián

@jorgensigvardsson
Copy link
Author

@MonkeyBreaker I think that sounds promising! What makes you not 100% happy with the implementation? If you do not feel like you have the time to "carry the torch", I could give it a shot. I had a hard time with the terse code, but I'm positive the diff between your code and @troglobit's master would guide me in the right direction.

@troglobit
Copy link
Owner

Thank you both! ❤️ I'd gladly help review any proposals 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants