Applications using SRV requests get a weight and priority additional parameters for each address resolved. Because that is used in both DNS and Multicast DNS. Because struct addrinfo contains the ordered list of addresses, I were thinking that is exactly result of SRV query too. In the end, it serves list of mixed AF addresses, sorted according to priority and weight. We could provide applications uniform ability to process SRV records. getaddrinfo() already has text service name anyway. I think we could use it together with some flag.
Similarly new SVCB and HTTPS records offer addresses too, but can provide additional parameters for connections. I think applications doing HTTPS connections would like API to receive all those addresses with additional parameters. I think simple array with key + val for each such parameter would provide ability to use them. Parameters like alpn would require application to use DNS-only resolution. But that would prevent https://localhost/ to work on typical machine.
I doubt it is common to use those records on mdns, but if some service wanted to provide parameters for encrypted channel, it might be used for that.
Applications using SRV requests get a weight and priority additional parameters for each address resolved. Because that is used in both DNS and Multicast DNS. Because
struct addrinfocontains the ordered list of addresses, I were thinking that is exactly result of SRV query too. In the end, it serves list of mixed AF addresses, sorted according to priority and weight. We could provide applications uniform ability to process SRV records. getaddrinfo() already has text service name anyway. I think we could use it together with some flag.Similarly new SVCB and HTTPS records offer addresses too, but can provide additional parameters for connections. I think applications doing HTTPS connections would like API to receive all those addresses with additional parameters. I think simple array with key + val for each such parameter would provide ability to use them. Parameters like alpn would require application to use DNS-only resolution. But that would prevent
https://localhost/to work on typical machine.I doubt it is common to use those records on
mdns, but if some service wanted to provide parameters for encrypted channel, it might be used for that.