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
--- 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
[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,
Re: [dns-operations] root? we don't need no stinkin' root!
--- Begin Message --- Verisign has a long track record of working with trusted researchers, universities, and an array of partners to publish a significant amount of research and peer-reviewed work on the topic of name collisions, sharing insights from our unique observation space as a root server operator – see [1] for some examples. We’ve also invested extensively to collect and perform longitudinal analysis on various aspects of this data and make the findings available to the community for consideration, as illustrated in the long list of citations available at [1] on name collisions, as well as other more recent topics (e.g., to inform KSK roll planning [2]). If you have technical concerns with that work, we welcome your feedback. As Duane noted, we do NOT monetize root server data. Conflating those things with the RZM function is not helpful in this context, and to the extent you want to access RZM-related data, ICANN / PTI has it and is very transparent with it already, IMO. You’re certainly entitled to your opinion about the results of the studies we’ve worked on, but your comments about the motivation behind those studies are wrong, unsupported by facts, and frankly out of bounds. We won’t have anything else to say on this matter. Matt Thomas Verisign [1] https://mm.icann.org/pipermail/ncap-discuss/2019-April/08.html [2] http://www.circleid.com/posts/20191126_recognizing_lessons_learned_from_the_first_dnssec_key_rollover/ From: dns-operations on behalf of Rubens Kuhl Date: Friday, November 29, 2019 at 8:38 PM To: "dns-operations@lists.dns-oarc.net" Subject: [EXTERNAL] Re: [dns-operations] root? we don't need no stinkin' root! The data could have monetary value. Passwords that are otherwise difficult to come by might be leaking. Hi Florian, I can assure you that Verisign does not monetize the root server data. If any other operators do, I'm not aware of it. We do utilize root server data for research purposes from time-to-time. Recent examples include the KSK rollover and name collisions. Less recent examples include understanding TTL/caching behavior and preparing for the root ZSK size increase. When DDoS attacks happen, we often analyze the data to see if we can understand how and why it happened, and to be better prepared for the next one. Note that the two paragraphs above contradict each other. The current RZM is known to use root server data as anti-competitive measures against new TLD operators with the label of name collision studies, including making studies that other parties can't reproduce due to being limited to DITL data. Rubens --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
