On Fri, Jun 3, 2022 at 11:57 AM Thomas, Matthew via dns-operations < [email protected]> wrote:
> > > > ---------- Forwarded message ---------- > From: "Thomas, Matthew" <[email protected]> > To: "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" <[email protected]> > Bcc: > Date: Fri, 3 Jun 2022 18:48:57 +0000 > Subject: Re: Re: [dns-operations] Input from dns-operations on NCAP > proposal > Thank you David. That change from NXDOMAIN to NOERROR/NODATA and things > going "boom" is exactly what we are looking for community input towards. > Do folks know of applications, or things like suffix search list > processing, that will change their behavior. > > There is one particular non-default configuration that definitely would make things go "boom". (This is not a comprehensive list of behaviors, just one example that is known.) If the options value of "ndots:N" is set in /etc/resolv.conf (or whatever analogous configuration elements exist in non-Unix/linux systems) to a value of N==0, then a lookup for a single label name (e.g. "foo") would be made as an absolute query first, before doing search list additions. "ndots" can generally be any number between 0 and X, for implementation-specific X. Some implementations cap X at 15, some at 255, there may be other implementations. In such a configuration, if the host name "foo" matches the candidate TLD "foo", and the latter is changed from NXDOMAIN (non-existing in the root) to anything else (e.g. a delegation is made for "foo"), this will break search list processing for "foo". I.e. earth-shattering kaboom. BEFORE: "foo" => NXDOMAIN, resolver then tries various "foo.bar.example.com", "foo.example.com" etc. AFTER: "foo" => not NXDOMAIN, resolver stops after the answer it gets (especially if there is a matching QTYPE and RRTYPE in the Answer, such as QTYPE == A, answer is 127.0.53.53) Brian > Matt > > On 6/2/22, 5:22 PM, "David Conrad" <[email protected]> wrote: > > Hi, > > On Jun 1, 2022, at 12:39 AM, Petr Špaček <[email protected]> wrote: > > On 24. 05. 22 17:54, Vladimír Čunát via dns-operations wrote: > >>> Configuration 1: Generate a synthetic NXDOMAIN response to all > queries with no SOA provided in the authority section. > >>> Configuration 2: Generate a synthetic NXDOMAIN response to all > queries with a SOA record. Some example queries for the TLD .foo are below: > >>> Configuration 3: Use a properly configured empty zone with correct > NS and SOA records. Queries for the single label TLD would return a NOERROR > and NODATA response. > >> I expect that's OK, especially if it's a TLD that's seriously > considered. I'd hope that "bad" usage is mainly sensitive to existence of > records of other types like A. > > > > Generally I agree with Vladimir, Configuration 3 is the way to go. > > > > Non-compliant responses are riskier than protocol-compliant > responses, and option 3 is the only compliant variant in your proposal. > > Just to be clear, the elsewhere-expressed concern with configuration 3 > is that it exposes applications to new and unexpected behavior. That is, > if applications have been “tuned” to anticipate an NXDOMAIN and they get > something else, even a NOERROR/NODATA response, the argument goes those > applications _could_ explode in an earth shattering kaboom, cause mass > hysteria, cats and dogs living together, etc. > > While I’ve always considered this concern "a bit" unreasonable, I > figure its existence is worth pointing out. > > Regards, > -drc > > > > > > > ---------- Forwarded message ---------- > From: "Thomas, Matthew via dns-operations" <[email protected]> > To: "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > Cc: "[email protected]" <[email protected]> > Bcc: > Date: Fri, 3 Jun 2022 18:48:57 +0000 > Subject: Re: [dns-operations] Input from dns-operations on NCAP proposal > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
