Duane Thanks for these. I'm going to capture these for the authors (at least one is currently on holiday).
On Tue, Jul 9, 2024 at 5:55 PM Wessels, Duane <dwessels= 40verisign....@dmarc.ietf.org> wrote: > 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. > > Most DNS-over-TCP does seem to work effectively, even with enterprise type resolvers (MS comes to mind). > > 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 …” > > good point. > 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? > The discussion was "if we suggest predictable names, bad actors can search for _foo-challenge.example.com and find out if the domain uses such services, in an attempt to exploit." The authors didn't come to any decision. This may be an excellent bike shed for the working group. (I believe as a domain administrator that I would end up placing bogus TXT records in my domain, to throw off bad actors. "they claim to have docusign but we can't find a way in") > > > 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? > > This I feel I'll answer badly, so I'll make a note for the authors. > because base64 relies mixed case > > "utilizes mixed case”? > yes > > 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”? > > I'm OK with this. I think the guidance is hoping folks prevent collisions. > 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" > > "owner name" sounds a wee bit vague. But I understand what you're driving at. > > without having to hand over full DNS access > > what is DNS access? ;-) > "access to the owners domain records" > > by letting the Intermediary place the random token in their DNS > > in their zone? > "Intermediary place the random token into their own DNS zone" But yes. > APIs SHOULD be used to relay instructions. > > Not sure I follow this. An API to relay instructions? > I'm thinking this comes from reading all the ACME challenge documents. This needs either clarification or removal > > 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? > Should the draft have thoughts on this? I prefer authoritative servers but sometimes the tooling that queries these records are baked into current infrastructure. > > > > 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? > Yes I believe so. > > > > 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 Thanks Duane for the detailed review. I'm going to file these as issues for the authors to address. tim > DW > > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
