In message <camm+lwhz1qvnu35hgrz6ln0onuatxi8hxrddetlwhumarjm...@mail.gmail.com> , Phillip Hallam-Baker writes: > 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.
Or just add the A/AAAA records to the additional section of the NXDOMAIN/NODATA response to the SRV query using the base name. The client can synthesize the response using the additional data. That way the DNS server doesn't need to know the port mappings. If qtype is SRV strip off leading underscore labels and add addresses records for the resulting name to the additional section of the response. Or the client can just do parallel lookups and wait for all the responses before proceeding. Set a flag day N years out for when to stop performing the A/AAAA lookups. They can decide to stop doing parallel lookups much earlier when they see SRV records being returned consistently. The flag day is just to sunset backwards lookups. > 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
