--- 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" <[email protected]> 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
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to