On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews <ma...@isc.org> wrote: > > > Zero if it is done right. We can easily extend the DNS to say > "Fetch the additional record for the SRV records before answering" > if you have this EDNS option present or just have the server do it > without the option. There is nothing preventing a recursive server > just doing this today. >
+1 Actually that is what I was assuming. If we are using the current DNS protocol then all we need to do is to program the DNS servers to intelligently add the necessary additional RRs. Alternatively, if we are doing DNS over QUIC then we could tweak the protocol so that this is the default. If the SRV prefix is _http._tcp or _https._tcp then the recursive > server SHOULD fetch any missing additional address records for the > SRV server including CNAME records if the server name maps to a > CNAME and add them to the addtional section prior to returning the > response. You could even just do this for all SRV lookups. > Yup. The only catch is that we all need to do discovery the same way. That is why SRV+TXT as specified in RFC6763 is the way to go > A RFC saying something like this would solve the SRV issue over the > long term a recursive servers get replaced. Unfortunately brower > vendors don't seem to want to say "yes, we will add SRV support if > you change the DNS to do this". > I don't think they are interested in SRV just for SRV. But SRV for this plus SNI encryption could be enough. We could also fix up some sort of backwards compatibility scheme. A DNS server that knows that _http._tcp.example.com is http over port 80 can convert A/AAAA records as needed. If we are dealing with a trusted DNS resolver chosen by the relying party that is constant, we can do things like advertise 'next generation discovery'. > And if they have a issue with the prefix one can allocate a new TYPE(s) > for class IN that does the same as SRV records but is for http and https. > > Service to address can be done with a single lookup and can include the > TLSA records as well. > I would prefer to specify the security policy in an accompanying prefixed TXT record because I need more than TLSA provides.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
