[dns-operations] Input from dns-operations on NCAP proposal

[Brian Dickson]

On Fri, Jun 3, 2022 at 11:57 AM Thomas, Matthew via dns-operations <
dns-operations at dns-oarc.net> wrote:

>
>
>
> ---------- Forwarded message ----------
> From: "Thomas, Matthew" <mthomas at verisign.com>
> To: "drc at virtualized.org" <drc at virtualized.org>, "pspacek at isc.org" <
> pspacek at isc.org>
> Cc: "vladimir.cunat+ietf at nic.cz" <vladimir.cunat+ietf at nic.cz>, "
> dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
> 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" <drc at virtualized.org> wrote:
>
>     Hi,
>
>     On Jun 1, 2022, at 12:39 AM, Petr Špaček <pspacek at isc.org> 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" <dns-operations at dns-oarc.net>
> To: "drc at virtualized.org" <drc at virtualized.org>, "pspacek at isc.org" <
> pspacek at isc.org>
> Cc: "dns-operations at dns-oarc.net" <dns-operations at dns-oarc.net>
> 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220603/f919e270/attachment.html>