On Aug 5, 2019, at 5:52 AM, Joe Abley <jab...@hopcount.ca> wrote: > I'm concerned about the cases where: > > (a) the data enclosed within a RESINFO response includes embedded IP > addresses that may not match the addresses that correspond to the resolver > service as viewed from another addressing domain, and > > (b) the potential for HTTPS and DNS ALGs to further confuse matters as the > system generating the RESINFO response for one retrieval protocol might not > be the same as for the other.
Both are fair points. But, having said that, which single transport for the resolver information would you pick? DNS is clearly more "native" to the resolver itself, but many people objected to the fact that it is unlikely to be authenticated due to lack of deployment of DNSSEC down the reverse tree, and significant lack of deployment of validating stubs. HTTPS is clearly easier to authenticate with trusted CAs or DANE (for those few stubs that do validate), > I realise it's tempting to imagine that HTTPS is not subject to explicit or > implicit handling by ALGs; however, anecdotally at least, SSL-stripping (e.g. > with jurisdiction-specific trust anchors installed on clients) is on the rise > and not just in enterprise networks. I've also seen networks where traffic is > routed by policy in different directions according to transport-layer > addresses, e.g. for reasons of available capacity or latency. Yep. The real question is whether we react to that by not using HTTPS at all, or use it anyway because it is more likely to get authentic answers to the client than DNSSEC is. > So I echo the concern about having one protocol speaking for another. I > haven't quite got my head around what I think about RESINFO in general but > this particular aspect seems like a more general weakness that is worth > highlighting. We should definitely add this discussion to the draft if the WG adopts it. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
