[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt

["Wessels, Duane" <[e-mail]>]

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