I read through draft-ietf-dnsop-domain-verification-techniques-05 and have a few minor comments / suggestions.
> this may result in IP fragmentation, which often does not work While it’s true we have come to agree that fragmentation is bad for DNS, I think “often does not work” overstates the situation. I’d say it works more often than not and I don’t see draft-ietf-dnsop-avoid-fragmentation making the case that fragmentation does not work. > Depending on message size limits configured or being negotiated, it > may alternatively cause the DNS server to "truncate" the UDP response > and force the DNS client to re-try the query over TCP in order to get > the full response. Not all networks properly transport DNS over TCP > and some DNS software mistakenly believe TCP support is optional > ([RFC9210]). I have mixed feelings about this. While perhaps factually true, I think broken DNS-over-TCP shouldn’t be a reason for not lumping validation records together. There are other valid reasons to avoid that practice and networks with broken DNS-over-TCP shouldn’t be coddled. > When multiple distinct services create domain Validation Records at > the same domain name, services don’t create records, users/administrators do. Maybe reword as “When multiple distinct services specify placing domain Validation Records at the same …” > The presence of a Validation Record with a predictable domain name > (either as a TXT record for the exact domain name where control is > being validated or with a well-known label) can allow attackers to > enumerate utilized set of Application Service Providers. Not sure I buy this argument. Doesn’t the draft recommend using predictable names anyway, just one per provider? > 1) A domain name related to the domain name being validated 2) A > Validation Record, either directly in RDATA or as the target of a > CNAME (or chain of CNAMEs) It’s not clear to me if this an “OR” list or an “AND” list? > because base64 relies mixed case "utilizes mixed case”? > Application owners SHOULD consult the IANA "Underscored and Globally > Scoped DNS Node Names" registry [UNDERSCORE-REGISTRY] to confirm > there are no collisions with existing entries. maybe this could be less passive as “consult … and avoid using underscore labels that already exist in the registry”? > either the RDATA or a domain name > The RECOMMENDED format for a Validation Record's domain name is > Here and in numerous other places I think “domain name” might be better as “owner name”. i.e.: "the owner name of a validation record" > without having to hand over full DNS access what is DNS access? ;-) > by letting the Intermediary place the random token in their DNS in their zone? > APIs SHOULD be used to relay instructions. Not sure I follow this. An API to relay instructions? > TTL Considerations If I were writing software to verify domain control, I probably wouldn’t use a caching resolver. I’d just send queries to authoritative name servers to avoid caching. The draft doesn’t seem to have any thoughts on this one way or the other? > CNAME Records for Domain Control Validation I think the document could be more clear or explicit that a CNAME target must exist. i.e., a random token in the owner name of a CNAME record is not sufficient and such a CNAME whose target does not exist should be treated as a failure, right? > Application Service Providers MAY include the random token in a > domain name that is related to the domain name being validated. An proposed rewording: Application Service Providers MAY specify that a random token be included in the owner name of a validation record. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
