Hey Stephen, > > Hiya, > > On 20/10/2024 22:27, tojens.i...@gmail.com wrote: > > We welcome your feedback! > > I had a read and have a couple of questions: > > 1. Is the "authenticate to me or I won't let you get to malware" > thing actually real? I don't know of any such recursive and it'd seem pretty > odd.
No, it is not. That paragraph is talking about public, open resolvers with endpoints that refuse to resolve names on endpoints their threat lists say are malware-associated. It is using them as an example of scenarios where client auth is not needed because having different IP addresses is sufficient to let a client opt into different server behaviors. The text tries to get into detail about when clients really should not trust the strange server asking for its personal information, hence the extra detail throughout. > Recursives that do that kind of thing just do it on different IPs AFAIK. The draft agrees with you, saying that recursives offer such services on different IP addresses today and those scenarios are no justification for client auth: "A client who wishes to opt-in to a server with a particular resolution policy can do so by sending queries to the corresponding IP address, and no client identification is required." > > 2. If the answer to 1 is "no" or that that kind of service is speculative, > then am I > correct in my reading of the draft when I conclude that the real reason for > client > auth is so the server can know which lies to tell a client? (I.e. split > horizon, rpz) > This could be used to support split horizon, sure (not that we are thrilled about that practice, notice "split" is nowhere in the text). RPZ in the refuse/allow sense is the intended scenario: a corporation can decide what to resolve and refuse the rest. Still resolving but to values not returned by the authoritative would break DNSSEC, which is not mentioned only because it seems a bit off topic for this draft. All that said, I see the wording of Section 6.3's header uses the term "differently" though the section only talks about to resolve or not to resolve. Maybe "Refusing to resolve different names per client" would be better. > (I'm putting that in a deliberately provocative manner to try tease out if > there's > some benefit for the client, of it this is all and only about satisfying > authoritarian > infrastructure:-) "Deliberately provocative" is appropriate for breaking the ice on this topic I think :) > > Thanks, > S. > > PS: Not saying I dislike this, but my starting position is that I'd need > convincing. Challenge accepted! _______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
