dns-aid style svcb records#4
Conversation
|
+1 to Jeff! I'm not a fan of TXT records, specifically, I'd like to try and prevent the previous failures of SPF in the agentic web. While convenient, they are inefficient. SVCB provide an alias within the same record via a TargetName which is very convenient for hosted or managed agents, service providers, and others. Our proposal talks about additional metadata added via SVCBkeyParams, if required (reducing the need for duplicative TXT records for the same host). Also, including leading underscores invalidate CAs issuing public signed certs due to their unsupported nature in dNSNAME. |
|
Also +1 to Jeff, but I should declare interest as one of the authors of the DNS-AID draft. To expand on @nicknacnic comments... Well known DNS-SD labels registered with IANA can reference a TargetName e.g. _index._agents.acme.com IN SVCB catalogue.acme.com ipv4hint=192.0.2.1 SvcParamKey=value OR _index._agents.acme.com IN SVCB catalogue.acme.com.service-provider.com SvcParamKey=value An SVCB record will provide improved structure over a TXT record in that existing SvcParamKeys can be used for connectivity (protocol suite, IP addressing) and new SvcParamKeys registered where they improve efficiency for instance, which could be the case with providing a .well-known path. We should avoid any TXT records at a zone apex, as Nic noted there can be a proliferation of TXT records for sender policy framework and proof of domain ownership. |
Changed to DNS-AID style SVCB records. Instead of introducing yet another style of records, can we use this proposal? I realize it's not finalized yet but it has gone through several iterations with dns and agents communities input.
If there are issues with the proposal, let me know, we are open to make adjusts as well.