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

2022-06-06 Thread John Levine
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

2022-06-06 Thread Dave Lawrence via dns-operations
--- 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

2022-06-06 Thread Vladimír Čunát via dns-operations
--- 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

2022-06-06 Thread Viktor Dukhovni
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

2022-06-06 Thread Dave Lawrence
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