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. |
|
Thanks @jmozley-infoblox and @jdamick . I agree that moving away from TXT records to SVCB for service discovery is much cleaner. Based on the examples shared, it looks like the _index._agents label handles the registry aspect and the TargetName points to the catalog. Could you confirm that this is the intended pattern for both the registry API and static well-know catalog (I think it might be better to have a record for catalog as well)? |
|
@mindpower the concept is we need well known (not /.well-known in this case) labels in DNS to access the resources available in ARD such as a catalogue. This will come through using DNS-SD labels we can register with IANA and then an organisation can point to the location of the resource using the TargetName. Examples: _index._agents.example.com IN SVCB agent-catalogue.example.com svcparamkey=value etc. In the DNS-AID internet draft we used _index._agents.example.com, but instead of _index we could use _catalogue or something else, depending on community consensus. The TargetName (agent-catalogue.example.com in the case) can have a public cert as it doesn't have underscores and this is the name used to connect to the catalogue. We use DNS-SD labels in the domain name as these can be registered, unlike "www" as a defecto location everyone knowns as an organisation's web site.. Using the SVCB record for the catalogue can get you the IP, protocol suite, and other key parameters to access the catalogue (or other ARD resources), while the TargetName is where you go, which might be under your domain or under a service provider's domain, like using a CNAME record, expect the advantage here is the connectivity and alias are all in one DNS record. |
|
I would like to get feedback from Scott Courtney and the community on this
before making this change, given how much more broadly txt records are
used. I am open to adding svcb records *in addition*, as an option, but we
need to retain the option of using txt records.
…On Fri, Jun 26, 2026 at 6:00 PM Junjie Bu ***@***.***> wrote:
*mindpower* left a comment (ards-project/ard-spec#4)
<#4?email_source=notifications&email_token=ABICKCQ3UTMRZFJNHVMBU235B4MCFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBRGQ2DIOJZGA22M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4814449905>
Thanks @jmozley-infoblox <https://github.com/jmozley-infoblox> and
@jdamick <https://github.com/jdamick> . I agree that moving away from TXT
records to SVCB for service discovery is much cleaner.
Based on the examples shared, it looks like the _index._agents label
handles the registry aspect and the TargetName points to the catalog. Could
you confirm that this is the intended pattern for both the registry API and
static well-know catalog (I think it might be better to have a record for
catalog as well)?
—
Reply to this email directly, view it on GitHub
<#4?email_source=notifications&email_token=ABICKCQ3UTMRZFJNHVMBU235B4MCFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBRGQ2DIOJZGA22M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4814449905>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABICKCTR2R5DU3Q4OCEZ3B35B4MCFAVCNFSNUABGKJSXA33TNF2G64TZHMYTENBTG4ZTSMBXGI5US43TOVSTWNBVG4ZDANZWGY3DRILWAI>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
|
I think the analogy here is to do for agents what the HTTPS DNS record (which is really SVCB) did for browsers. |
I would suggest falling back to TXT records would be preferable to using them in the first instance, if they have to be used at all. |
|
Yes, we should not use SVCB records to replace DNS-TXT type of records. They carries different level of trust. Also in general the security schema in the spec is open and supporting different types of trust verifications. |
I am not sure how DNS SVCB records carry a different level of trust to TXT records. Either could be secured using DNSSEC if organisations choose to do this. SVCB/HTTPS records can be used for Encrypted Client Hello (RFC9848) for clients to learn the ECH configuration, which I think implies trust. SVCB/HTTPS records also have a defined structure, where as TXT records do not, so from a data quality and validation perspective there can be more trust in SVCB records I think. I have seen it pointed out that SVCB records have less support. I believe this is with some registrars that don't provide interfaces for their customers to configure these record types, but I know that some large providers do support them, such as GoDaddy. Common DNS software implementations do support these record types and the HTTPS variant particularly is in widespread use. So in this context I can see that a fallback to TXT records is useful in case an organisation's registrar does not support SVCB yet. |
|
Thanks for the detailed clarification. You make an excellent point regarding DNSSEC and ECH. I agree with your assessment here (this is more about discovery at this phase). It sounds like we are aligned on the path forward: introducing SVCB as the cleaner, preferred method for service discovery, while explicitly retaining TXT records as a necessary fallback. @jdamick , can you update the PR to reflect this?
|
|
sure, will do |
5 participants
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.