Re: [dns-operations] Input from dns-operations on NCAP proposal
Dave Lawrence via dns-operations writes: > I accept that the only way to really capture > all of these queries into the global DNS is via a delegation, Brian Dickson reminded me of his CNAME proposal earlier in the thread, and I think that is also an approach worth further investigation. ___ 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
That might not be true on some Linux distributions. Those with systemd-resolved preinstalled (Ubuntu and Fedora) send single label queries to LLMNR multicast resolution. I think it uses the search directive for list of domains for local networks, but otherwise ignores them. It is debatable whether this approach is more secure or better. On 04. 06. 22 2:18, Randy Bush wrote: Do we have any idea how many systems still use search lists? linux and freebsd installs encourage them -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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 Dave Lawrence via dns-operations said: >Ditto local roots. This feels like something Geoff Huston probably >has some kind of data about, but a cursory search didn't turn it up. >I personally run a local root on my home system, but how prevalent are >they? I believe they are very prevalent in large DNS caches, to the extent that it's unclear how well the queries reaching the public roots match what the world is really asking. 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
--- Begin Message --- Vladimír Čunát writes: > If the root zone is unchanged, many names could be hidden before > reaching root servers - by DNSSEC aggressive caching and/or various > local-root variants. (I'm not sure if we can well measure the extent to > which this happens.) That's an interesting observation. I'm inclined to think (with no data to back it up) that the penetration of DNSSEC is sadly still not deep enough that you'd still see plenty of leakage even in the presence of aggressive NSEC. I know there's data that shows aggressive NSEC does have an positive impact on reducing garbage queries, but also that plenty of garbage still does get through. Ditto local roots. This feels like something Geoff Huston probably has some kind of data about, but a cursory search didn't turn it up. I personally run a local root on my home system, but how prevalent are they? That said, I'm not really just trying to wave off the problems those two scenarios present. I accept that the only way to really capture all of these queries into the global DNS is via a delegation, and just still wonder whether RSS logging wouldn't be good enough to give adequate observations of potential collision problems. Especially because each of the suggested configurations presented originally also have their own problems, as you have already observed. Sounds like at least the two options to synthesize NXDOMAINs for all labels at the delegated authority are worth some lab tests for major resolvers to document just how they'd respond in the presence of the suggested synthesis. Full disclosure: I'm in the "preserve NXDOMAIN" camp, based in part on having worked in the past with systems where the difference between NXDOMAIN and NOERROR/NODATA was significant. I do not knowingly work with such systems now though, so can't make any sort of strong claim as to what would currently be impacted. Well I guess that's not completely true, I *do* regularly encounter the problem with DNSSEC Black Lies, and grumble and mutter every time I do. That's more of a human interface issue though, not a programmatic one. --- End Message --- ___ 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 --- On 06/06/2022 16.57, Dave Lawrence wrote: To be clear, I'm not saying they*should* do it. I'm just trying to better understand the context. If the root zone is unchanged, many names could be hidden before reaching root servers - by DNSSEC aggressive caching and/or various local-root variants. (I'm not sure if we can well measure the extent to which this happens.) --Vladimir | knot-resolver.cz --- End Message --- ___ 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 Mon, Jun 06, 2022 at 10:57:01AM -0400, Dave Lawrence wrote: > I seem to be exceptionally derpy right now, but I'm realizing I can't > articulate why it can't be done with the standard NXDOMAINs that the > roots have been issuing all along. If the "it" is collection of extant use of a suffix, than I think you're right. All the prior fancy gymnastics were at the point in time when the new suffix is actually delegated at the root, but not yet available for registration of subdomains. The intent was to let the *users* of conflicting subdomains know that they are skating on thin ice, before their favourite domains are directed somewhere even more surprising. If the need for a signal back to the source of the query is not in scope, then it seems like NXDOMAIN might suffice. -- Viktor. ___ 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
John R Levine writes: > 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. I seem to be exceptionally derpy right now, but I'm realizing I can't articulate why it can't be done with the standard NXDOMAINs that the roots have been issuing all along. I do get that preciously data about junk queries to the roots has largely been distilled from DNS-OARC's DITL data, and that has its limitation. Is part of the issue here that there is a little/moderate/severe hesitation to ask the RSS operators to make any changes for collecting data about this directly? Have they been approached about it and already rejected the idea? To be clear, I'm not saying they *should* do it. I'm just trying to better understand the context. ___ 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, 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
Re: [dns-operations] Input from dns-operations on NCAP proposal
On Mon, May 23, 2022 at 7:00 AM Thomas, Matthew via dns-operations < dns-operati...@dns-oarc.net> wrote: > > > > -- Forwarded message -- > From: "Thomas, Matthew" > To: "dns-operati...@dns-oarc.net" > Cc: > Bcc: > Date: Mon, 23 May 2022 13:48:12 + > Subject: Input from dns-operations on NCAP proposal > > DNS-Operations, > > > > The Name Collision Analysis Project (NCAP) group is considering new ways > in which additional DNS data can be collected for name collision assessment > purposes while attempting to preserve the NXDOMAIN response dependent > systems and applications currently receive from the root. We are looking > for community input around any known technical challenges or problems with > the proposed delegation strategies listed below. Here is some relevant > background and context for the proposal. > > > > First, within the context of NCAP, a name collision refers to the > situation where a name that is defined and used in one DNS namespace may > also appear in another. Users and applications intending to use a name in > one namespace may attempt to use it in a different one, and unexpected > behavior may result where the intended use of the name is not the same in > both namespaces. > > > > In the 2012 round of new gTLDs, DNS data collected at the root server > system via DNS-OARC’s DITL collection was used to assess name collision > visibility. The use of DITL data for name collision assessment purposes has > growing limitations in terms of accessibility, increasing data > anonymization constraints, a narrow data collection time window, and the > limited annual collection frequency. Other changes in the DNS, such as > Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair > name collision measurements at the root. > > > > The 2012 round of new gTLDs used a technique called Controlled > Interruption. Attempts to query a new TLD during the controlled > interruption period for an A record would result in an answer of the > loopback address 127.0.53.53. The change from NXDOMAIN to an answer was > intended to be a gentle disruption to systems experiencing name collisions > (i.e., systems that were explicitly or implicitly relying on a NXDOMAIN > response) and the mnemonic IP address was intended to lead investigative > system administrators to informative web search results telling them about > the TLD’s delegation. > > > > In preparation for the next round of TLDs, the NCAP team is examining > possible new ways of passively collecting additional DNS data while > providing a less disruptive NXDOMAIN response to queries. > > > > Currently, any recursive name server querying for non-delegated TLDs gets > a NXDOMAIN from the root. Enumerating all possible ramifications of > negative answers on end users and applications is not possible; every > application can react differently to negative answers. Regardless of the > reason, the errors received when returning a NXDOMAIN answer are both > useful to systems and end users (e.g., spam filtering services, search list > processing, etc.). > > > > The proposed system below is an attempt to preserve the NXDOMAIN response > these name collision systems are currently receiving, while enabling > additional data collection capabilities. The NCAP is looking to the DNS > community to see if you are aware of any kind of technical implications > from a risk perspective that the proposed configurations would a.) cause > systems to behave differently or b.) induce harmful collateral damage. > > > > *Proposal*: > > > > The proposal would involve delegating a candidate TLD. The delegation > process of inserting a string into the DNS root zone will make the TLD > active in the domain name system. The required delegation information in > the referral from the root is a complete set of NS records and the minimal > set of requisite glue records. The candidate TLD would be delegated to > servers running custom DNS software. The TLD would not be DNSSEC signed. > > > > We would like to understand which of the following configurations would be > the least disruptive to systems and applications that were relying on the > NXDOMAIN response. > > > > 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: > > > > 1) Query for bar.foo returns NXDOMAIN with SOA > > 2) Query for .foo returns NXDOMAIN with SOA > > 3) Query for .foo SOA returns NXDOMAIN with SOA &g
Re: [dns-operations] Input from dns-operations on NCAP proposal
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 signature.asc Description: Message signed with OpenPGP ___ 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 24. 05. 22 17:54, Vladimír Čunát via dns-operations wrote: On 23/05/2022 15.48, Thomas, Matthew via dns-operations wrote: Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section. I believe the protocol says not to cache such answers at all. Some implementations chose to cache at least a few seconds, but I don't think all of them. Breaking caching seems risky to me, as traffic could increase very much (if the TLD was queried a lot). Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record. Some example queries for the TLD .foo are below: It still feels a bit risky to answer in this non-conforming way, and I can't really see why attempt that. At apex the NXDOMAIN would deny the SOA included in the very same answer... 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. Reasoning: Behavior for non-compliant answer is basically undefined because most RFCs do not describe what to do when a MUST condition is violated. It's hard to see how further evaluation of undefined behavior would help with determining further course of action. -- Petr Špaček @ Internet Systems Consortium ___ 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, Peter, for the response. I want to try and steer this conversation towards the main question/concern the NCAP is looking for community input – What impact/risk comes from delegating a TLD that was receiving NXDOMAIN responses from the root but would subsequently receive a NOERROR NODATA response for single label queries to the authoritative name servers for the TLD after delegation? How does that change in response from NXDOMAIN to NOERROR NODATA impact application behavior (e.g., things like suffix search list processing)? What things will break, change behavior, etc.? Thanks. Matt On 5/25/22, 9:37 AM, "Peter Thomassen" wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Thomas, On 5/23/22 15:48, Thomas, Matthew wrote: > In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. I think these are valid concerns, but they don't necessarily mean that a new assessment methodology is needed. Instead, we could try to work towards reducing these limitations, i.e. improve accessibility, collection frequency etc. > Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root. QNAME Minimization drops labels from the left. How would it impact root traffic? Aggressive NSEC caching covers non-delegated domains. Assuming such a record is cached, the root would not be asked for a name contained in the range, regardless of which special response strategy would be employed for such queries. In both cases, I think it would be helpful to understand better how these mechanisms impair name collision measurements. Can you elaborate? > In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries. Before deciding what set-up best suits the data collection, I'd like to understand what data do you want to collect specifically? > The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, [...] > The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. Given the DNS protocol, these two goals seem inconsistent. If the servers referred to by the NS rrset do know the zone, they will answer NOERROR for apex queries, and depending on the query type, they will also return records (e.g. NS, or SOA). If they don't know the zone, the best practice response is REFUSED. There doesn't seem to be a compliant way to delegate a candidate TLD and then have the auth return NXDOMAIN to queries for that domain. (If you do that, there is no guarantee of success. The set-up would be strange, and resolvers may decide to pass SERVFAIL to their clients, for example. Also, cache issues may arise, as pointed out by Vladimír.) > 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. If I understand correctly, that's similar to what was done in 2012. Again, I'm not sure why it would not work now when it did back then. I think this is the question that should be answered first. > The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be /minimal/; I think it would be "hoped", not "expected" to be minimal. :-) Best, Peter -- Like our community service? Please consider donating at https://secure-web.cisco.com/1L9meurL2lpDues9wEZ5Pn5j_K-T1ujsw9oJpFSM_5f9mUTfWPfCaoXX0DJH9Mxlz5RVvHTZKI4Q3z0ouc7pN7bysaYVPH4i6vHyOWzhNBBldmPb1j01VUWoEokg-ZlM2TOySuNoy0oZVNbikYodSK0PUO5KvVQmQ1oLJC7pJ_tOn-c7O0uFHxmfYafDq75fpsx_JGcYRAz6vkgrKvPh5IBBQIvj3kiCVaoggd2crmbVZeLi8rmbVfbjfTzSZ6PnS/https%3A%2F%2Fdesec.io%2F deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net
Re: [dns-operations] Input from dns-operations on NCAP proposal
Hi Thomas, On 5/23/22 15:48, Thomas, Matthew wrote: In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. I think these are valid concerns, but they don't necessarily mean that a new assessment methodology is needed. Instead, we could try to work towards reducing these limitations, i.e. improve accessibility, collection frequency etc. Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root. QNAME Minimization drops labels from the left. How would it impact root traffic? Aggressive NSEC caching covers non-delegated domains. Assuming such a record is cached, the root would not be asked for a name contained in the range, regardless of which special response strategy would be employed for such queries. In both cases, I think it would be helpful to understand better how these mechanisms impair name collision measurements. Can you elaborate? In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries. Before deciding what set-up best suits the data collection, I'd like to understand what data do you want to collect specifically? The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, [...] The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. Given the DNS protocol, these two goals seem inconsistent. If the servers referred to by the NS rrset do know the zone, they will answer NOERROR for apex queries, and depending on the query type, they will also return records (e.g. NS, or SOA). If they don't know the zone, the best practice response is REFUSED. There doesn't seem to be a compliant way to delegate a candidate TLD and then have the auth return NXDOMAIN to queries for that domain. (If you do that, there is no guarantee of success. The set-up would be strange, and resolvers may decide to pass SERVFAIL to their clients, for example. Also, cache issues may arise, as pointed out by Vladimír.) 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. If I understand correctly, that's similar to what was done in 2012. Again, I'm not sure why it would not work now when it did back then. I think this is the question that should be answered first. The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be /minimal/; I think it would be "hoped", not "expected" to be minimal. :-) Best, Peter -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ 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 --- On 23/05/2022 15.48, Thomas, Matthew via dns-operations wrote: Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section. I believe the protocol says not to cache such answers at all. Some implementations chose to cache at least a few seconds, but I don't think all of them. Breaking caching seems risky to me, as traffic could increase very much (if the TLD was queried a lot). Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record. Some example queries for the TLD .foo are below: It still feels a bit risky to answer in this non-conforming way, and I can't really see why attempt that. At apex the NXDOMAIN would deny the SOA included in the very same answer... 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. --Vladimir | knot-resolver.cz --- End Message --- ___ 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 Mon, May 23, 2022 at 1:53 PM Thomas, Matthew via dns-operations wrote: > DNS-Operations, > > > > The Name Collision Analysis Project (NCAP) group is considering new ways in > which additional DNS data can be collected for name collision assessment > purposes while attempting to preserve the NXDOMAIN response dependent systems > and applications currently receive from the root. We are looking for > community input around any known technical challenges or problems with the > proposed delegation strategies listed below. Here is some relevant background > and context for the proposal. > > > > First, within the context of NCAP, a name collision refers to the situation > where a name that is defined and used in one DNS namespace may also appear in > another. Users and applications intending to use a name in one namespace may > attempt to use it in a different one, and unexpected behavior may result > where the intended use of the name is not the same in both namespaces. > > > > In the 2012 round of new gTLDs, DNS data collected at the root server system > via DNS-OARC’s DITL collection was used to assess name collision visibility. > The use of DITL data for name collision assessment purposes has growing > limitations in terms of accessibility, increasing data anonymization > constraints, a narrow data collection time window, and the limited annual > collection frequency. Other changes in the DNS, such as Qname Minimization, > Aggressive NSEC Caching, etc., also continue to impair name collision > measurements at the root. > > > > The 2012 round of new gTLDs used a technique called Controlled Interruption. > Attempts to query a new TLD during the controlled interruption period for an > A record would result in an answer of the loopback address 127.0.53.53. The > change from NXDOMAIN to an answer was intended to be a gentle disruption to > systems experiencing name collisions (i.e., systems that were explicitly or > implicitly relying on a NXDOMAIN response) and the mnemonic IP address was > intended to lead investigative system administrators to informative web > search results telling them about the TLD’s delegation. > > > > In preparation for the next round of TLDs, the NCAP team is examining > possible new ways of passively collecting additional DNS data while providing > a less disruptive NXDOMAIN response to queries. > > > > Currently, any recursive name server querying for non-delegated TLDs gets a > NXDOMAIN from the root. Enumerating all possible ramifications of negative > answers on end users and applications is not possible; every application can > react differently to negative answers. Regardless of the reason, the errors > received when returning a NXDOMAIN answer are both useful to systems and end > users (e.g., spam filtering services, search list processing, etc.). > > > > The proposed system below is an attempt to preserve the NXDOMAIN response > these name collision systems are currently receiving, while enabling > additional data collection capabilities. The NCAP is looking to the DNS > community to see if you are aware of any kind of technical implications from > a risk perspective that the proposed configurations would a.) cause systems > to behave differently or b.) induce harmful collateral damage. > > > > Proposal: > > > > The proposal would involve delegating a candidate TLD. The delegation process > of inserting a string into the DNS root zone will make the TLD active in the > domain name system. The required delegation information in the referral from > the root is a complete set of NS records and the minimal set of requisite > glue records. The candidate TLD would be delegated to servers running custom > DNS software. The TLD would not be DNSSEC signed. > > > > We would like to understand which of the following configurations would be > the least disruptive to systems and applications that were relying on the > NXDOMAIN response. > > > > 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: > > > > 1) Query for bar.foo returns NXDOMAIN with SOA > > 2) Query for .foo returns NXDOMAIN with SOA > > 3) Query for .foo SOA returns NXDOMAIN with SOA > > 4) Query for ns1.foo NS or ns2.foo returns NXDOMAIN with SOA Any plan that starts with adding buggy TLDs to the root zone is alarming and needs to be extremely carefully studied, but using out-of-bailiwick nameservers -- a.ncap-servers.net? -- is easy and would avoid an additional layer of likely caching difficulties, potential resolution failure and name collisions. > 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. > > > > The level of disruption to existing
[dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- DNS-Operations, The Name Collision Analysis Project (NCAP) group is considering new ways in which additional DNS data can be collected for name collision assessment purposes while attempting to preserve the NXDOMAIN response dependent systems and applications currently receive from the root. We are looking for community input around any known technical challenges or problems with the proposed delegation strategies listed below. Here is some relevant background and context for the proposal. First, within the context of NCAP, a name collision refers to the situation where a name that is defined and used in one DNS namespace may also appear in another. Users and applications intending to use a name in one namespace may attempt to use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root. The 2012 round of new gTLDs used a technique called Controlled Interruption. Attempts to query a new TLD during the controlled interruption period for an A record would result in an answer of the loopback address 127.0.53.53. The change from NXDOMAIN to an answer was intended to be a gentle disruption to systems experiencing name collisions (i.e., systems that were explicitly or implicitly relying on a NXDOMAIN response) and the mnemonic IP address was intended to lead investigative system administrators to informative web search results telling them about the TLD’s delegation. In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries. Currently, any recursive name server querying for non-delegated TLDs gets a NXDOMAIN from the root. Enumerating all possible ramifications of negative answers on end users and applications is not possible; every application can react differently to negative answers. Regardless of the reason, the errors received when returning a NXDOMAIN answer are both useful to systems and end users (e.g., spam filtering services, search list processing, etc.). The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, while enabling additional data collection capabilities. The NCAP is looking to the DNS community to see if you are aware of any kind of technical implications from a risk perspective that the proposed configurations would a.) cause systems to behave differently or b.) induce harmful collateral damage. Proposal: The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. The candidate TLD would be delegated to servers running custom DNS software. The TLD would not be DNSSEC signed. We would like to understand which of the following configurations would be the least disruptive to systems and applications that were relying on the NXDOMAIN response. 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: 1) Query for bar.foo returns NXDOMAIN with SOA 2) Query for .foo returns NXDOMAIN with SOA 3) Query for .foo SOA returns NXDOMAIN with SOA 4) Query for ns1.foo NS or ns2.foo returns NXDOMAIN with SOA 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. The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be minimal; however, the series of referrals and responses received by resolvers are different from a direct NXDOMAIN response from the root server system and deviate from the DNS protocol. It is possible that even this slight difference could impact application resolution processes, such as search list processing. The NCAP would appreciate any technical insights from a risk perspective the community may be able to provide regarding the proposal. Best,
