On Tue, 28 Mar 2023, Alex Stuart wrote:
I am employed by a SAML metadata registrar and we require verification that a registrant has effective control over a fully-qualified domain name. We have developed our own DNS TXT based method for verification and are in the process for reviewing it. We would like to be able to refer to a BCP document, and appreciate your work towards one.
That's great!
Here are some questions and comments as feedback on https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-01. I hope they are useful. 1. In section 2, you define the APEX, although this term does not appear in the rest of the document. All the examples show how to verify the apex domain example.com. It is therefore unclear to me whether your technique can be used to verify effective control over an arbitrary fully-qualified domain name. Can the specification generalise?
It can be used for any FQDN, as long as you prefix it deeper into that name. Generally, people want to know about the "whole domain", so the examples use this (the apex). We can add some clarifying text.
2. The examples in Section 3.1 show provider-relevant prefixes which start with an underscore. Is this convention or a requirement?
A good question, and omission at your part. We will also clarify this in the document. The use of underscore comes from the fact that it is a legal character in DNS, but technically not valid for "host names". So using an underscore means we avoid all risk of clashing our "infrastructure" records with regular records. For example, if we used "ownership.example.com" instead of "_ownership.example.com", than anyone using a website "ownership.example.com" might have a hard time using their name and the verification method at once.
3. In Section 3.1 you say "Consumers of the provider services need to relay information from a provider's website to their local DNS administrators". There are other ways to relay the information from provider to consumer, such as S/MIME, and the specification should reflect this.
Will fix.
4. Section 3.1 states "Providers MUST provide clear instructions on when a verifying record can be removed" and A.1.4 has "The service provider doing the verification should specify how long the verification will take". In my experience, the most variable part of the process is at the consumer end, because the person wishing to use the service is not typically the DNS admin. An expiry set solely by the provider doesn't take that variability into account. Maybe it's better for the provider to signal a period after which the verification would be assumed unsuccesful, and to provide guidance to the provider not to make this period too short.
We will clarify this. The issue we are talking about is not the "verification period" until the first verification succeeds, but whether the record is re-used at regular intervals to continue the proof of ownership.
5. My employer's method currently requires the registrant to set a TXT record on the apex domain. Thank you for providing 2 reasons in A.1.1 why we should not.
Excellent! I'm happy to see we are already seeing good results from the draft! :) Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
