On Mon, Nov 27, 2023 at 10:23 PM tirumal reddy <kondtir@xxxxxxxxx> wrote: > > On Fri, 24 Nov 2023 at 20:51, Watson Ladd via Datatracker <noreply@xxxxxxxx> wrote: >> >> Reviewer: Watson Ladd >> Review result: Has Issues >> >> I have reviewed this document as part of the security directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These comments >> were written primarily for the benefit of the security area directors. Document >> editors and WG chairs should treat these comments just like any other last call >> comments. >> >> The summary of the review is has issues. I found a few editorial things, and >> have one question, but I suspect that these can be resolved easily. >> >> Firstly the description of split horizon seems to say that any time the >> resolver is authoritative for just some names and recurses for others. I don't >> think this is right: the split is that the answers given are different from >> what they are for any other resolver, and that's what creates the need for this >> draft. This is defined correctly in section 2, it's just a need to reword the >> intro slightly. > > > Sure, we will fix the text as follows: > If this resolver acts as an authoritative server for some names and provides different answers for those domains depending on the source of the query, we say that the network has "split-horizon DNS", because those names resolve in this way only from inside the network. Sounds good. > >> >> >> In Section 5 I think more clarity is needed about which DNS name needs to >> match, and how the matching is to be done, perhaps citing a UTA doc. I think >> what's supposed to be said is that the ADN is a subjectAltName matching under >> RFC 6125. > > > It is discussed in the third paragraph of Section 5. For instance, in the case of DNR, the DNS client would anyway do PKIX validation and validation technique in RFC 6125 (see https://www.rfc-editor.org/rfc/rfc9463.html#section-3.3). The DNS client would have to check if the name of the local encrypted resolver matches the ADN in any one of the authorization claims. I was about to say that now that I've looked again at it I'm deconfused, but on thinking some more I'm confused again. How about switching to the following to make it clear? "If the local resolver is identifed by name, the name used to find it must equal the ADN in an authorization name used to convey authority for the domain being looked up. Otherwise the ADN must be presented on an X509 certificate shown by the resolver, according to the rules in RFC 6125". Sincerely, Watson -- Astra mortemque praestare gradatim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
