On Jun 30, 2023, at 9:08 AM, Florian Obser <florian+i...@narrans.de> wrote: > > A recursive resolver implementing this draft will probe on 853 without > RD set. ns1.example.com will respond with refused. The recursive > resolver will answer SERVFAIL. > > At least that's how I'm reading 4.6.9. R is successful, (it's not a > timeout or connection closed), so we do this: > > If R is successful: > > * R is further processed by the resolver > > Well, the resolver got REFUSED and there are no more NS to try. It can > only answer SERVFAIL. Therefore example.com is no longer resolvable. > > This draft breaks a valid configuration that has been working since > 2016. That's why I'm saying that a recursive resolver while probing MUST > be prepared to encounter open resolvers on 853 and not assume that > that's a successful probe.
Thank you for staying in with me on this; I now understand the problem you are describing and agree that with the current text, it will cause undesired failures. The current wording at the end of 4.6.9 is: But if `R` is unsuccessful (e.g. timeout or connection closed): I believe that changing that to the following would fix the problem you describe: But if `R` is unsuccessful (RCODE other than 0, timeout, connection closed): Does that fix your case and not break other cases? --Paul Hoffman _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
