Re: [dns-operations] Input from dns-operations on NCAP proposal
On Fri, 3 Jun 2022, Brian Dickson wrote: If this increases the number of names that will break search lists from 1487 to 1488, how much of a problem is this likely to be in practice, which leads back to ... If it was ONLY a progression of 1487->1488, it might not be that bad (but again, that all depends on what number 1488 actually is.) What it is actually is an exercise in survivorship bias. Anyone who might have been impacted by any of the earlier rounds of expansion, will (likely) have learned their lesson. That lesson may depend on tribal knowledge, which might not be reliable enough for any previous victim to not be re-victimized. Unfortunately, now we've circled back to where we started. Remember that the NC in NCAP stands for Name Collision, and the whole point of the project is to figure out how risky it is to add familiar looking new names. In the last round of TLD expansion they added over 1000 names but indefinitely deferred requests for .CORP .HOME and .MAIL which had well known existing uses. So now I'm scratching my head, what are they hoping to learn from this exercise that wouldn't be totally dominated by the choice of name? I'm tempted to suggest adding .BELKIN and see how many old routers fail. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
On Fri, Jun 3, 2022 at 3:17 PM John R Levine wrote: > On Fri, 3 Jun 2022, John Levine wrote: > >> In such a configuration, if the host name "foo" matches the candidate > TLD > >> "foo", and the latter is changed from NXDOMAIN ... > > > Do we have any idea how many systems still use search lists? We've been > saying > > bad things about them at least since .CS was added in 1991. > > It occurs to me there is another way to look at this. There are already > 1487 delegated TLDs, and I doubt anyone could name more than a small > fraction of them. If this increases the number of names that will break > search lists from 1487 to 1488, how much of a problem is this likely to be > in practice, which leads back to ... > > If it was ONLY a progression of 1487->1488, it might not be that bad (but again, that all depends on what number 1488 actually is.) What it is actually is an exercise in survivorship bias. Anyone who might have been impacted by any of the earlier rounds of expansion, will (likely) have learned their lesson. That lesson may depend on tribal knowledge, which might not be reliable enough for any previous victim to not be re-victimized. Anyone not previously affected may be unaware of the risk their own set-up places them in, until their choices run up against newly deployed TLDs. Until the practice or standard/implementation for search-lists is fully deprecated, the risk will remain, for either new TLDs being deployed or new host names or naming conventions being deployed. Unimaginative host names like "mail001" are likely safe. However, naming hosts after some class of entities, like manufacturers or fast food companies or even classes of things, will ironically be risky. The best analogy I can think of is playing "minesweeper" on a huge board, where the number of mines periodically gets increased, where there are no signals of adjacent mines (1-8), no flags, and no automatic flooding of zero-mine areas. Spots you have clicked on could be subsequently mined, and you lose. It is an asynchronous race condition, where an external party is making moves (adding mines) on your behalf. It would not be considered a "fun" game, IMNSHO. Brian P.S. Having "ndots:N" for N>0 isn't necessarily safe, either. Any new TLD that matches an internal namespace component rather than hostname, won't necessarily be discovered until registrations begin. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
> Do we have any idea how many systems still use search lists? linux and freebsd installs encourage them ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
On Fri, 3 Jun 2022, John Levine wrote: In such a configuration, if the host name "foo" matches the candidate TLD "foo", and the latter is changed from NXDOMAIN ... Do we have any idea how many systems still use search lists? We've been saying bad things about them at least since .CS was added in 1991. It occurs to me there is another way to look at this. There are already 1487 delegated TLDs, and I doubt anyone could name more than a small fraction of them. If this increases the number of names that will break search lists from 1487 to 1488, how much of a problem is this likely to be in practice, which leads back to ... It seems to me that the risk depends a lot more on what the name is rather than the particular DNS response. If it's OEMDMCEKCSN. I doubt anyone will notice, but if it's MAIL., watch out. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
It appears that Brian Dickson said: >"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. Do we have any idea how many systems still use search lists? We've been saying bad things about them at least since .CS was added in 1991. >In such a configuration, if the host name "foo" matches the candidate TLD >"foo", and the latter is changed from NXDOMAIN ... It seems to me that the risk depends a lot more on what the name is rather than the particular DNS response. If it's OEMDMCEKCSN. I doubt anyone will notice, but if it's MAIL., watch out. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
On Fri, Jun 3, 2022 at 11:57 AM Thomas, Matthew via dns-operations < dns-operati...@dns-oarc.net> wrote: > > > > -- Forwarded message -- > From: "Thomas, Matthew" > To: "d...@virtualized.org" , "pspa...@isc.org" < > pspa...@isc.org> > Cc: "vladimir.cunat+i...@nic.cz" , " > dns-operati...@dns-oarc.net" > Bcc: > Date: Fri, 3 Jun 2022 18:48:57 + > 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" wrote: > > Hi, > > On Jun 1, 2022, at 12:39 AM, Petr Špaček 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" > To: "d...@virtualized.org" , "pspa...@isc.org" < > pspa...@isc.org> > Cc: "dns-operati...@dns-oarc.net" > Bcc: > Date: Fri, 3 Jun 2022 18:48:57 + > Subject: Re: [dns-operations] Input from dns-operations on NCAP proposal > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- 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. Matt On 6/2/22, 5:22 PM, "David Conrad" wrote: Hi, On Jun 1, 2022, at 12:39 AM, Petr Špaček 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 --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
