Very interesting, so BIND already pushes records for the obvious optimisation cases. Did you do any research on how many clients use these records (thus don't follow up with an extra query) ?
Perhaps it would be helpful to look at the it from different perspectives. As an authoritative DNS implementor, I'd like to be able to add related records. Since auths are relatively well maintained, I'd feel more comfortable experimenting here. Signalisation is not strictly required, but perhaps a flag similar to "DO" to signalise "I want related records" would be helpful. So both PUSH and PULL are viable options. PUSH would be nicer if the deployed recursors already accepted these records, however I don't have any data on this. As a recursive DNS implementor, I can't trust everything in the answers. I'd prefer to signalise when I want related records (PULL) to be conservative, because the recursors are not that well maintained. I'd like to have a better guideline on what records should be accepted from the answers. As a stub resolver DNS implementor, I don't want to change anything because this code will live forever. Marek On Thu, Aug 18, 2016 at 7:32 PM, Mark Andrews <ma...@isc.org> wrote: > > Named returns associated > > * A/AAAA records with MX lookups if available > * A/AAAA records with SRV lookups if available > * SRV/A/AAAA records with NAPTR lookups if available > * A/AAAA records with NAPTR lookups if available > > As of 9.11 named returns associated > > * A/AAAA/TLSA records with MX lookups if available > * A/AAAA/TLSA records with SRV lookups if available > * SRV/A/AAAA/TLSA records with NAPTR lookups if available > * A/AAAA records with NAPTR lookups if available > > Now for all of these the original lookup could be stalled for cache > misses and the related data fetched if the server is offering > recursive service to the clients. > > It would also be possible when offering recursive service to perform > prefetching on cache misses. > > It would also be possible to return A on AAAA and AAAA on A. > > It's up to the client to accept or ignore the records. > > 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
