Draft: draft-ietf-add-ddr

Commentary: In the security considerations , we should note that the DDR query can be made repeatedly in case it got a negative answer before , to still detect cases where the record had been dropped or blocked before 
 For authentication to matter , it generally has to operate without fallback . Currently the text is not very clear on this point , but it sure seems like IP - authenticated mode is expected to fall back to cleartext if no upgrade is possible . I think we need to clarify the use case for an authenticated mode , or abandon the distinction between opportunistic and authenticated . In my view , authenticated mode only makes sense if ( 1 ) the resolver is identified by its IP address AND ( 2 ) the system knows a priori that this resolver supports encrypted DNS , so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker . This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names ( Section 5 ) or opportunistic instead . 
 Currently , this is what we say ( which I now see a grammatical error in , but there it is ): We do n't say anything else because that would be out of WG scope . The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS . The stub resolver 's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business . Look at this through a common OS scenario : the OS stub resolver learns an IP address from DHCP , and it 's a public IP address ( my old ISP did this ) . It knows of no other resolvers because the user does n't know what DNS is and that 's the default configuration ( use network recommendation ) . If I try to use DDR and I get no answer back , then I 'm in the same position as I was before DDR : I know of no other resolver , so I either have to use this one or have no DNS resolutions . DDR did not introduce that conundrum ; it offers clients a way out of it when DNR is not present and there is no plain - text DNS attack present . The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text . I do not agree this scenario is sufficiently narrow to drop . Is your concern over the usefulness of the scenario , or over naming it " authenticated " ? I am open to suggestions on the latter ; I strongly disagree with the former . 
 Both . How is this information useful to the client ? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated , when the resolver is identified by IP address . As for the name , RFC 7435 is the reference . I find it a bit confusing , but here 's some of the relevant text : The " authenticated " section does not seem to describe an " authenticated " protocol by this definition , because it does not provide a downgrade - resistant method to determine that authentication is expected to work . 
 Please suggest a more accurate name then please . I do agree behavior naming should be consistent with other documents . Your bar for useful is apparently different from mine . Before DDR , a client configured only with an IP address had only unencrypted DNS as an option . With DDR , the client can possibly encrypt that connection . A transient attacker would have to have been present for the initial SVCB discovery to prevent that ; an attacker arriving after DDR has taken place will be kept out of the loop . In the worst case , a client is returned to square one . I do not agree that just because a mechanism can be prevented means the mechanism provides no value . It does n't have to . In the common case , the client is forced by lack of knowledge to use unencrypted DNS . If it can from that default configuration divine encrypted DNS configuration , that 's a net positive . Resolver selection is out of scope and has nothing to do with it . 
 I 've updated to address this question by reformulating the concept of authentication , and being much more explicit about the threat model . Yes , that 's a good step , but it does n't rely on authentication . This is a very helpful observation . I 've incorporated it in . 
 I believe this particular issue is largely overtaken by events . Particularly , I think we 've some clarity and escape hatches with , and protections with . 
 LGTM , one comment which is non - blocking .
Since client can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
packets.  Clients should be aware that it might not be possible to
distinguish between resolvers that do not have any Designated
Resolver and such an active attack.
Since client can receive DNS SVCB answers over unencrypted DNS, on-
path attackers can prevent successful discovery by dropping SVCB
packets.  Clients should be aware that it might not be possible to
distinguish between resolvers that do not have any Designated
Resolver and such an active attack.  To limit the impact of discovery
queries being dropped either maliciously or unintentionally, clients
can re-send their SVCB queries periodically.