Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Matthew Pounsett <[e-mail]>]

On 12 August 2017 at 04:29, Lanlan Pan <[e-mail]> wrote:

> Hi Matthew ＆ Paul,
>
> Good question, :-)
>
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>
> My assumption is: *we can give recursive server an alternative solution
> for wildcard subdomain cache issue, not need to depend on DNSSEC.*
> Authoritative server just simply add one SWILD RR, not much deploy cost.
> Recursive server can add SWILD support if it has an interest in wildcard
> subdomain cache optimization,  it is OPT-IN.
>

I confess it was a rhetorical question. All of the major implementations
already support DNSSEC.  8198 doesn't have an implementation status
section, but there's every reason to think the major implementations will
have support within a version of two.  A quick survey of a few issues
databases shows that at least Knot is already working on it.  That is a
significant head start; SWILD support without DNSSEC support can't happen
in any significant way, and SWILD support without support for 8198 doesn't
seem likely.

As for operator adoption, the incentives are all wrong for this to actually
get used.

Recursive operators already have a very low operational bar to turn on
DNSSEC and get the same benefit to their cache.  In both cases (SWILD and
DNSSEC) they rely on the authoritative operator opting in before that
benefit can be realized.

Authoritative operators may choose to use DNSSEC  because it will secure
their zone, and if recursive operators also have 8198-capable name servers
then the workload for both authoritative and recursive is reduced for all
terminal names.

With SWILD, there is no direct benefit to the authoritative operator, as
far as I can see.  Given that the only benefit to using SWILD is to the
recursive operator, what is the motivation for the authoritative operator
to add complexity to their deployment by adopting it?  Traditional
wildcards work fine for them.

To make the adoption problem worse, it appears as if SWILD is more limited
in its use than traditional wildcards.  For example, I don't see how you
could occlude an SWILD record with a more-specific domain name, as you can
with traditional wildcards.
Here's a common scenario based on the example from the draft:
   @    86400  IN   SWILD  _
   _     3600  IN   CNAME  map.bar.net.
   *      600  IN   CNAME  _
 dev      600  IN   CNAME  map.dev.bar.net.

How does SWILD behave when a client queries for dev?  According to the
draft, the authoritative server would return the SWILD record at the apex.
An SWILD-aware recursive server seems like it would ignore the CNAME
returned for dev and instead use the CNAME for _, which is not what the
operator intended.


>
> *I don't expect implementers would adopt SWILD 100% before adopting
> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
> decide adopting or not, before or after, we won't pre-select for them.*
> Even if both Authoritative server and Recursive server support DNSSEC+NSEC
> aggressive, when will they configure default dns query with dnssec ? (for
> NSEC agreesive cached deduced wildcard)
>

We already know that a year ago 26% of all end users were behind some sort
of validating resolver, a number which continues to climb as more ISPs turn
on validation, and more users switch to things like Google Public DNS
<https://labs.apnic.net/presentations/store/2016-06-27-dnssec.pdf>.  This
isn't an ideal deployment status so long after DNSSEC was standardized, but
it's a long way ahead of SWILD.

You'll need to have a very compelling argument for me to believe that SWILD
is both more useful than DNSSEC and more likely to be deployed at any kind
of scale that would make a difference.  I just don't see it.

Add to that Paul's point that we would very much like to encourage DNSSEC
adoption, I don't see why we'd add support for an alternative technology
that accomplishes a subset of its features.