In message <CAC=TB13se3egHwRGebkPZG7Fj_JaPG=obR7Mo5-jhEYv=+r...@mail.gmail.com> , =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes: > 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) ?
Clients can change. The more servers that return data the more likely clients will optimise to look for it. Stub clients should just accept what is sent and smart ones do (think SMTP servers which remember address records returned with MX responses). > 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. You have baliwick and DNSSEC to consider. You can always cache data + rrsig and validate prior to returning it to clients. Named does also do lazy validation like this. > As a stub resolver DNS implementor, I don't want to change anything > because this code will live forever. > > Marek -- 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
