On Tue, Jul 9, 2024 at 2:54 PM Wessels, Duane <dwess...@verisign.com> wrote:
> I read through draft-ietf-dnsop-domain-verification-techniques-05 and have > a few minor comments / suggestions. > Thanks Duane! > > 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. Yes, I agree that this is overstated, and that IP fragmentation often (and maybe even mostly) works. I'm fine with walking this back, but let me tag Paul Wouters here, who I believe added this specific text, for his thoughts. > 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. > Maybe more efficient operation of the DNS infrastructure is a better reason to keep responses small rather than coddling to broken DNS/TCP implementations. I'm okay with rewording this. But if you have specific suggested text, please offer it up. > > 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 …” > Well automated applications can create DNS records too, not just users or admins. But I get your point, and your rewording sounds good to me. > 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? > Arguably, there is a potential privacy concern here. But there are so many other ways to determine what service provider(s) a domain is using, that I'm not persuaded that we need to address this and obfuscate the verification record too. Erik Nygren - I think this was your proposed change. Can you elaborate on your argument? > 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? > I'd recommend inserting an "and" in there. > > > because base64 relies mixed case > > "utilizes mixed case”? > Ok. > > > 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”? > Ok. > > > 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" > Yes, I agree. > > > > without having to hand over full DNS access > > what is DNS access? ;-) > We can reword this. I think we mean handing over full access to edit the zone contents to the intermediary. > > > by letting the Intermediary place the random token in their DNS > > in their zone? > Yes, and ok. > > > APIs SHOULD be used to relay instructions. > > Not sure I follow this. An API to relay instructions? > I think this means the application provider has an API that is used to obtain the instructions for how to populate the validation record (owner name, rdata content etc). Though this wasn't my text. I hope one of my co-authors will speak up to confirm. > > > 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? > That would certainly avoid most of the TTL considerations stated. But it is more work for the verifier (and requires more DNS knowledge), so I suspect most applications don't do this today. I would be okay however with stating that this one possible way a verifier could work. > 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? > I don't think this necessarily has to be the case, but in practice it usually is. > 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. > Ok. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
