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

From: Petr Špaček <[email-masked]>
Date: Thu, 10 Aug 2017 13:04:38 +0200

Hello,

On 4.7.2017 05:54, Lanlan Pan wrote:
> Hi Tony,
> 
> We try to solve similar wildcard problem.
> 
> NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> <https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6>)
> :
> - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> - cached deduced wildcard: give the default wildcard RR.
> 
> SWILD:
> - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> 
> SWILD is applicable even when Authoritative Nameservers don't give
> NSEC/NSEC3 RR.
> SWILD is applicable on non-validating Forwarding Resolvers.

If I understand it correctly:
- the only information added by SWILD RR is an explicit information
about the original (unexpanded) name of wildcard owner
- the very same information can be obtained from RRSIG RR in a
synthtetised answer (RRSIG labels < owner name labels)
- SWILD will work only if there are no nodes below the wildcard

Assuming this analysis is right, I'm against this proposal.

We can get even better behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
is okay: New features are provided only by the latest version of
the protocol.

Petr Špaček  @  CZ.NIC

> 
> Regards,
> 
> Tony Finch <[email-masked] <mailto:[email-masked]>>于2017年7月3日周一 下午
> 8:18写道：
> 
>     Lanlan Pan <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > This document specifies a new SWILD RR type for Intermediate
>     Nameservers to
>     > cache subdomain wildcard record, in order to reduce the cache size and
>     > optimize the wildcard domain cache miss.
> 
>     Isn't this functionality already provided by
>     https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
> 
>     Tony.
>     --
>     f.anthony.n.finch  <[email-masked] <mailto:[email-masked]>> 
>     http://dotat.at/  -  I xn--zr8h punycode
>     Fitzroy: Variable 4 for a time in north, otherwise northeasterly
>     becoming
>     cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate,
>     occasionally
>     poor.
> 
> -- 
> 致礼  Best Regards
> 
> 潘蓝兰  Pan Lanlan

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 11 Aug 2017 05:02:14 +0000

Hi Petr,

Thanks for your comments, :-)

Petr Špaček <[email-masked]>于2017年8月10日周四 下午7:04写道：

> > <
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6
> >)
> > :

Your analysis is totally right.

> - supports wildcards with nodes below it

Yes, aggressive NSEC use has advantages if:
1) AUTH give NSEC RR.
2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
aggressive use.

> is okay: New features are provided only by the latest version of
But:
1) many wildcards occupy the Resolver cache, with no nodes below them.
2) many wildcards AUTH not give NSEC RR.
3) many resolvers not support DNSSEC validating, not to mention NSEC
aggressive use.

On the view of new feature, SWILD can be an alternative simpler choice to
deploy.

Petr Špaček  @  CZ.NIC
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 11 Aug 2017 10:39:50 -0400

> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC

It sounds like you're assuming that SWILD would be supported by caching
servers that do not support DNSSEC or NSEC aggressive use.  Why do you
expect implementers would adopt SWILD before adopting these much older
features?

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 11 Aug 2017 07:51:02 -0700

> expect implementers would adopt SWILD before adopting these much older

This is my top question on the document.

--Paul HOffman

---

From: Richard Gibson <[email-masked]>
Date: Fri, 11 Aug 2017 16:47:03 -0400

I'm assuming there's a very obvious answer to this question, but what would
break if unsigned wildcard caching were covered by allowing
DNSSEC-independent NSEC (and therefore
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )?

$ cat zones/github.io
; apex records
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
github.io. 900 IN NS ns-1339.awsdns-39.org.
github.io. 900 IN NS ns-1622.awsdns-10.co.uk.
github.io. 900 IN NS ns-393.awsdns-49.com.
github.io. 900 IN NS ns-692.awsdns-22.net.
github.io. 900 IN NS ns1.p16.dynect.net.
github.io. 900 IN NS ns2.p16.dynect.net.
github.io. 900 IN NS ns3.p16.dynect.net.
github.io. 900 IN NS ns4.p16.dynect.net.
github.io. 30 IN A 151.101.193.147
github.io. 30 IN A 151.101.129.147
github.io. 30 IN A 151.101.1.147
github.io. 30 IN A 151.101.65.147
github.io. 300 IN TXT "v=spf1 a -all"
; wildcard answer records
*.github.io. 3600 IN CNAME sni.github.map.fastly.net.
; aggressive-use signal covering LDH wildcard-synthesized names
*.github.io. 3600 IN NSEC github.io. CNAME NSEC
; aggressive-use signal covering pre-* wildcard synthesized names (omitted
to demonstrate selective application)
; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC

$ dig @$resolver +noall +answer example.github.io. A    ; positive answer
with covering NSEC for aggressive use
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
example.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer foo.github.io. A    ; positive answer from
cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
foo.github.io. 3590 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 20 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3590 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer bar.github.io. AAAA    ; negative answer
from cache plus fresh SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3579 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer baz.github.io. AAAA    ; negative answer
from cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 890 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3569 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer '\032.github.io.' A    ; positive answer
with non-covering NSEC (due to partial application; could be remedied by
adding another NSEC to the zone)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
\032.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

---

From: Lanlan Pan <[email-masked]>
Date: Sat, 12 Aug 2017 08:29:45 +0000

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 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)

As old features, why DNSSEC + NSEC is not forthcoming global deployed ?
(maybe an old question, tired of discussing)
Both Authoritative server and Recursive server consider about the DNSSEC
validation cost / DDoS.
Authoritative's Zone Enumeration risk, NSEC -> NSEC3 -> NSEC5 -> ???
other reasons...
For example, Google likes to support some optimized protocols/features,
such as QUIC, SPDY, ...
dig @ns1.google.com xxxxxxxx.google.com +dnssec ,  only return NXDOMAIN.

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Aug 2017 15:42:42 +0000

On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote:
> ...

we do, though, and we must. DNSSEC development began in 1996, and deployment 
is stalled due to lack of motivation. it is the IETF's position that DNSSEC is 
a public good in that it will enable a general world-wide security level that 
has always eluded the Internet.

any DNSSEC feature that we decide to offer separately ("a la carte") is both a 
missed opportunity to increase the deployment of DNSSEC, and a self-inflicted 
wound that deliberately further stalls that deployment.

noting that DNSSEC as a protocol is of atrociously low quality ("it's crap"), 
i am in no way defending the design itself. however, it does work, and we 
would be acting contrary to our own best interests ("folly") if we took up 
anything like SWILD, or allowed anything like SWILD on the individual track.

failing that level of commitment, the IETF ought to kill DNSSEC altogether.

this is very similar to the "shall we had IPv6's features to IPv4, since V6 is 
taking so long to deploy, and these features are badly needed?" debate.

vixie

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 12 Aug 2017 12:31:04 -0400

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

> My assumption is: *we can give recursive server an alternative solution
> for wildcard subdomain cache issue, not need to depend on DNSSEC.*

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.

> 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.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Aug 2017 09:55:13 -0700

On 8/12/2017 8:42 AM, Paul Vixie wrote:
> we do, though, and we must. DNSSEC development began in 1996,

Hmmm.  As I recall, discussions on the topic began in 1990 and I thought 
I was cognizant AD, briefly, when the first working group was formed, 
after that.

I had understood that the IETF effort went through two false-starts in 
design before landing on the current design, but don't have an adequate 
sense of the milestone dates for these phases.

I note that the DNSSEC History Project should document this, in detail, 
but lacks dates(*)

d/

(*) https://wiki.tools.isoc.org/DNSSEC_History_Project

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 14 Aug 2017 00:14:26 +0200

On 12 Aug 2017, at 18:31, Matthew Pounsett wrote:

> 8198 doesn't have an implementation status section

https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#section-10 
is not in the published RFC 8198 because 7942 (sadly) mandates that this 
section is removed before publication. I suspect this removal is 
specifically hurting OPENPGPKEY deployment today.

So, if you want to know about implementation status, please click 
through from https://tools.ietf.org/html/rfcXXXX to the relevant draft.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 13 Aug 2017 18:24:56 -0400

On 13 August 2017 at 18:14, Peter van Dijk <[email-masked]>
wrote:

>
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressive
> use-10#section-10 is not in the published RFC 8198 because 7942 (sadly)
> mandates that this section is removed before publication. I suspect this
> removal is specifically hurting OPENPGPKEY deployment today.
>
> So, if you want to know about implementation status, please click through
> from https://tools.ietf.org/html/rfcXXXX to the relevant draft.
>
> Ah, I did not realize that was mandated to be removed.  Thanks for filling
me in!

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 14 Aug 2017 04:56:49 +0000

Hi Paul,

Maybe it makes a mountain out of a molehill.
"Give to the emperor the things that are the emperor's, and to God the
things that are God's.“, we can seperate security issue and subdomain
wildcard cache issue.

I think,  SWILD has no influence on DNSSEC deployment :
1) If recursive wants to deploy DNSSEC, it is almost impossible because of
NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest
motivation behind DNSSEC depolyment.*
2) If recursive doesn't want to deploy DNSSEC, it is almost impossible
because of SWILD. Imagine that, there is no SWILD to give precise subdomain
wildcard information from authoritative, recursive can use random subdomain
detect method to make cache optimization, which was described in DNS Noise:
Measuring the Pervasiveness ofDisposable Domains in Modern DNS Traffic
<http://astrolavos.gatech.edu/articles/dnsnoise-dsn2014.pdf>.

But the rate of "DNSSEC + NSEC + default dns query with DNSSEC” has
influnence on subdomain wildcard cache issue if we only accept unique
solution depend on it.

Paul Vixie <[email-masked]>于2017年8月12日周六 下午11:42写道：

> for
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 14 Aug 2017 07:26:11 +0000

Hi Matthew,

Thanks for your detailed reply, :-)

Matthew Pounsett <[email-masked]>于2017年8月13日周日 上午12:31写道：

>> SWILD is a feature just for recusive cache optimization, only dealing
>> with the wildcard subdomain issue (with no nodes below).

We know that we will have a Swiss Army knife (DNSSEC) in the future, can we
also put a Fruit knife (SWILD) in the kitchen now?

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

Authoritative will be directly benefit, save cost, reduce wildcard
subdomain response laterncy.

As methioned in the draft : "Intermediate Nameservers' cache hit rate will
rise, avoid to query Authoritative Nameserver for the same wildcard domain
configuration."
Imagine that Recursive Resolver knows that SWILD RR of wildcard domain "*.
foo.com". In TTL time, if Recursive Resolver receives "
yyy.foo.com/zzz.foo.com/..." A RR query, it can directly return this
subdomain wildcard response without send dns queries to Authoritative.

Traditional wildcards work no so fine for them, it make recursive send many
subdomain dns queries to Authoritative.

Authoritative operators can choose DNSSEC because of security,  they can
also choose SWILD because of wildcard domain response optimization.  Not
contradictory.

> returned for dev and instead use the CNAME for _, which is not what the

As I replied to Petr, "many wildcards occupy the Resolver cache, with no
nodes below them."

Most of the subdomain wildcards for CDN, P2P, advertise, anti-virus, DNSBLs
service have not specific subdomain like "dev",  SWILD is not for this
condition.

>> 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)
>>
>

Every protocol feature has a deployment progress, nobody thinks that will
be a short time, the same with other features such as ANAME, DANE, ...

> 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.
>

I don't think SWILD will be more useful than DNSSEC,  everyone knows that
they are different features, and it is impossible.

I think SWILD has no influence on DNSSEC deployment,  details in last mail
replied to Paul.

One question:  is wildcard subdomain cache issue solution must bind with
security feature ?

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Aug 2017 14:32:02 -0700

WG Chairs: i oppose adoption of this draft.

> Hi Paul,

tl;dr: this message marks the end of this thread from my side.

> I think, SWILD has no influence on DNSSEC deployment : 1) If
> recursive wants to deploy DNSSEC, it is almost impossible because of
> motivation behind DNSSEC depolyment.* 2) If recursive doesn't want
> to deploy DNSSEC, it is almost impossible because of SWILD. Imagine
> that, there is no SWILD to give precise subdomain wildcard
> information from authoritative, recursive can use random subdomain
> detect method to make cache optimization, which was described in DNS
> Noise: Measuring the Pervasiveness of Disposable Domains in Modern
> DNS Traffic

Mr. Pan, your words above are a striking example of absurd reduction, 
which through a series of difficult-to-assail false equivalencies, an 
outcome unacceptable to your correspondent may begin to "look good on 
paper".

Proof of this can by found by trying to reason your way to the 
conclusion you are offering, by any other path. You'll find this 
difficult, since the likelihood of someone deploying DNSSEC if it has no 
compelling features is lower, and aggressive negative caching with or 
without a wildcard is a feature of both DNSSEC and SWILD.

In any case I find that you are arguing in bad faith, starting from your 
desire and then finding ways to justify it, rather than starting from 
the facts and finding out where those lead to. I won't play along any 
further. For your possible use, see these words from the NY Times 
opinion pages, published a day or so ago:

<<What becomes clear to anyone following the climate debate, however, is 
that hardly any climate skeptics are in fact trying to get at the truth. 
I’m not a climate scientist, but I do know what bogus arguments look 
like — and I can’t think of a single prominent climate skeptic who isn’t 
obviously arguing in bad faith.

Take, for example, all the people who seized on the fact that 1998 was 
an unusually warm year to claim that global warming stopped 20 years ago 
— as if one unseasonably hot day in May proves that summer is a myth. Or 
all the people who cited out-of-context quotes from climate researchers 
as evidence of a vast scientific conspiracy.>>

-- 
P Vixie

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 15 Aug 2017 04:45:17 +0000

Hi Paul,

Don't judy other's motivation with meaningless skeptics. The endless
skeptics can also push on your RPZ to DNSSEC.

As an network engineer, I think good faith is face to the realistic
internet world, try my best to offer a better solution to technology
problem.

If we anticipated the subdomain wildcard scenario when designing wildcard
years ago, *make Authoritative give more precise wildcard information to
Recursive* (SWILD) is natually.
SWILD is not starting from "desire", not to mention "reducing DNSSEC
deployment".

*1) I believe,  reduce solution interdependence between different problem
areas is comfortable.*

Subdomain wildcard cache issue solution is not need to bind with security
issue,  in natural.

*2) I believe,  design an alternative solution to an existed problem is
ordinary.*

IPv4/IPv6 Migration can use Tunnel, NAT, ...
Subdomain wildcard cache optimization can use NSEC aggressive wildcards,
SWILD, ...

You can oppose to SWILD,  but wish you not oppose to the alternative
solution designing.

*3) I believe,  network protocol / feature deployment progress is decided
by the key function, not because of additional function.*

IPv6 deployment  will sharply rise mostly because of *IPv4 addresses
exhaustion*,  but almost impossible because of any improved IPv6 featue
that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ...
DNSSEC deployment will sharply rise if global nameservers desire *dns
security*, but almost impossible because of an addtional wildcards feature.

That is why I say "SWILD has no influnence on reducing DNSSEC deployment",
going further,  "NSEC aggressive wildcard has no influnence on rising
DNSSEC deployment".

Repeat the Google example,  as far as I can see:
- Google has expert on NSEC aggressive wildcard.
- Google likes to support some optimized protocols/features, such as QUIC,
SPDY, ...

Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return
NXDOMAIN.
Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED
in future, more probability than because of NSEC aggressive wildcards.

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Aug 2017 15:14:21 +1000

> skeptics can also push on your RPZ to DNSSEC.

I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
DNSSEC.

> Subdomain wildcard cache issue solution is not need to bind with security

Only if you believe spoofed responses can't be delivered.
 
> IPv4/IPv6 Migration can use Tunnel, NAT, ...

And that is a problem for router vendors and OS developers because
they end up having to implement them all.  Part of the reason there
aren't lots of CPE Routers today that support IPv6 is that the
vendors have to spend lots of $$$$$$ implemententing and testing
all the different transition mechanisms.  If they don't want to
spend lot of $$$$$$ then there is no real guidance on what mechanisms
to discard.

> in future, more probability than because of NSEC aggressive wildcards.

Google validates answers on its recursive servers so Google has already
partially deployed DNSSEC.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 15 Aug 2017 06:20:58 +0000

Mark Andrews <[email-masked]>于2017年8月15日周二 下午1:14写道：

>
> In message <
> [email-masked]>
> , Lanlan Pan writes:
> >
> > Hi Paul,
> >

Just for compare example, I mean that I also can't see how Paul can say
SWILD is to reduce DNSSEC deployment.

Not depend on,  is not equal to , reducing deployment.

> Only if you believe spoofed responses can't be delivered.
Everyone knows spoofed response can be delivered, that is why DNSSEC exists.
SWILD can work with DNSSEC validation, and save validation cost.
DNSSEC-enabled Recursive only need validate SWILD RR one time, not need
calculate/match NSEC3/NSEC5/... for yyy/zzz/.foo.com range.

> partially deployed DNSSEC.
My example is Google's Authoritative Server,  ns1.google.com.

> PHONE: +61 2 9871 4742 <+61%202%209871%204742>                 INTERNET:
> [email-masked]
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Aug 2017 06:51:55 GMT

> From: Lanlan Pan <[email-masked]>

> skeptics can also push on your RPZ to DNSSEC.

A significant difference between RPZ and the SWILD is that RPZ does
not depend on non-participants doing anything.  For example, RPZ works
fine on a single, isolated resolver.
(Of course, the owners of the IETF printing presses would have to
agree to publish anything, but publishing a description is neither
implementing nor deploying.)

The history of RPZ might suggest a temporary solution.  Why not implement
SWILD using a private rtype or perhaps even TXT?  An implementation
and a few 1000 installations might convince some skeptics and render
many objections moot.

> security*, but almost impossible because of an addtional wildcards feature.

I don't understand that.  My zones have plenty of wildcards, but as
far as I can tell, no new wildcard features will break my DNSSEC
signatures.

I don't understand "global nameservers [desiring] dns security".
Are "global nameservers" resolvers or authorities?
If they are resolvers, then there is absolutely no immediate prospect
of many (any?) resolvers that might be called "global" dropping
unsigned DNS data.
If they are authorities, then I thought that the reasons why almost
all com zones are unsigned are well understood, recently listed here,
and have nothing to do with wildcards.  What am I missing?
http://scoreboard.verisignlabs.com/
http://scoreboard.verisignlabs.com/percent-trace.png

   .......................

] From: Mark Andrews <[email-masked]>

] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
] DNSSEC.

I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
or DNSSEC and RPZ work together perfectly well"  (in either case,
assuming a trusted path such as (trusted) localhost name or 127.0.0.1
address to a trusted resolver, where "trusted resolver" includes
"trusted to rewrite."  Of course, without a trusted path to a trusted
resolver or a verifying stub, DNSSEC doesn't mean much.)

As Mark Andrews understands but many people don't, the common RPZ
implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
that RPZ invalidates and removes signatures and so verifying stubbs
and verifying downstream resolvers will not accept rewritten answers."

Also, in the two RPZ implementations I've written, the default
BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.

Vernon Schryver    [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Aug 2017 17:07:54 +1000

In message <[email-masked]>, Vernon Schryver 
> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks

I should have been more precise RPZ breaks DNSSEC for down stream
validators if it modifies responses from signed zones.  RPZ
implementations can be configured to do this.

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 15 Aug 2017 08:16:31 +0000

Hi Vernon,

Thanks for your advice, :-)

> and a few 1000 installations might convince some skeptics and render

Yeah,  TXT is my history plan: Recursive Resolvers that support wildcard
detect method with TXT record
<https://github.com/abbypan/dns_wildcard_on_intermediate_nameservers/blob/a4188548c87b6a10af45aa23575b86d9f33f39ec/draft.txt>

> of many (any?) resolvers that might be called "global" dropping

Both recursives and authoritatives.
I mean more and more recursives and authoritatives enable DNSSEC for dns
query by default configuration, sorry for my poor English.

> http://scoreboard.verisignlabs.com/percent-trace.png

The deployment problem is on the Authoritative Nameservers of billions of
second level domains,  not on TLD.
And Recursive must enable DNSSEC validation for dns query by default
configuration.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Aug 2017 13:41:23 GMT

] From: Lanlan Pan <[email-masked]>

] Give the choice to operators, time is the best witness, like IP surpassed
] ATM.

That is backwards.  IP did not surpass ATM, because IP came long before
ATM.  Instead, end-to-end ATM was the last gasp of the end-to-end
circuit switching point of view.  End-to-end ATM was supposed to replace
IP, but instead the new virtual circuits of ATM came far too late and
did not solve the problems that packet switching had already solved.

ATM has not yet died and is still common for some uses.  For example,
ATM  is used as x.25 was used under IP in the early days of IP; many
DSL installations use AMT VCs.

A better and more relevant history is that of the SPF RR.  The SPF RR
was supposed to replace the use of the TXT rtype for SPF.  The SPF RR
was widely available in deployed DNS authoritative servers (via BIND).
I think it was in milter modules for sendmail and postfix.  Nevertheless,
it died because it came late, was only a modest improvement, and required
operators to do something more than they were doing.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Aug 2017 13:27:11 -0400

I tried to ignore this thread for a while, but became alarmed after reading
some of the recent comments, so I went and read the document.

As far as I can tell, this document gives no clear justification for why it
is a good idea.   We have not been told of the practical operational
problems that motivate it.   It appears to solve a problem we have already
solved, in a way that creates new security vulnerabilities.   We have not
been told why the existing solution to the problem is not adequate.

If the authors have a real problem that they feel has not already been
solved, the first step in the process ought to be to present that
information to the working group, rather than to present a solution to the
working group with no clear statement about the problem it solves, and in
particular no data about the seriousness of the problem.

For what it's worth, which isn't much since the chairs haven't issued a
call for adoption, I don't think the working group should work on this.

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 16 Aug 2017 04:19:10 +0000

Hi Ted,

Thanks for your relevant comments, :-)

Ted Lemon <[email-masked]>于2017年8月16日周三 上午1:28写道：

> I tried to ignore this thread for a while, but became alarmed after
> reading some of the recent comments, so I went and read the document.
>
> As far as I can tell, this document gives no clear justification for why
> it is a good idea.   We have not been told of the practical operational
> call for adoption, I don't think the working group should work on this.

We analyzed our recursive query log, about 18.6 billion queries from
12/01/2015 to 12/07/2015.

We found about 4.7 Million temporary domains occupy the recursive's cache,
which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
360safedns, Cloudfront, Greencompute...

Temporary Domain Names/ All Names: 41.7%
Queries for Temporary Domain Names/ All Queries: 0.12%

Details in: Dealing with temporary domain name issues in the DNS
<https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>

<https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>
The operational problem is, subdomain wildcards waste recursive cache
capacity. Existing solution to the problem is not adequate in recursive
operating environment at present, because of low DNSSEC deployment.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 16 Aug 2017 11:15:39 +0530

> expect implementers would adopt SWILD before adopting these much older

(Without commenting about SWILD)

It does not have to be due to implementation support alone. Many
operators stick to unsigned zones. There are many reasons, some of which
I'd mentioned in the unsigned NSEC thread. Resolvers have to deal with
cache pollution and unnecessary upstream queries, but they have no
control over whether the authoritative zones are signed.

2 mails up this thread, there is a comment about "New features are
provided only by the latest version of the protocol." This seems to mix
unrelated things together. The latest version of DNS (if there's such a
thing) doesn't mandate operational use of DNSSEC. Use of unsigned zones
is not obsolete and may well outlive us. Most zones today are unsigned
and a carrot like NSEC agressive use is unlikely to change the level of
adoption of DNSSEC significantly.

Alexa Top domains and DNSSEC:

24 / 500 top domains (4.8%)
20548 / 1 million top domains (2.05%)

(12 years after introduction of 403{3,4,5})

		Mukund

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 08:21:37 +0200 (CEST)

> (12 years after introduction of 403{3,4,5})

https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1

20% of European users is behind a validating resolver, in some countries 
it's 70% plus.

So this is now happening, albeit at a not high enough pace. But at least 
it's going in the right direction, and I do believe that there is enough 
people behind validating resolvers that people can't mess up signing their 
zone and push away blame on who needs to fix things.

So at least there is benefit in signing your zone now, there wasn't as 
much before when nobody was validating.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 23:29:56 -0700

Mukund Sivaraman wrote:
...
> (12 years after introduction of 403{3,4,5})

we should give up.

or we shouldn't.

not a mixture.

-- 
P Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 16 Aug 2017 12:08:43 +0530

> > (12 years after introduction of 403{3,4,5})

I'm not saying we should give up.. but it's going to be a while before
we get to an utopia of maximal DNSSEC deployment. In the meantime, there
are practical problems that need mitigation.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 16 Aug 2017 12:18:55 +0530

On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote:
> So at least there is benefit in signing your zone now, there wasn't as much
> before when nobody was validating.

The validating resolver is half of the system.

DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was
designed for) that many businesses cannot afford to bank on if something
were to go wrong. An administrative error or signer software bug on the
authoritative side can take the whole zone down and every service with
it (as DNS is at the head of network activity). Software is still not
perfect, so I don't know how this can change - I see practical signer
bugs still that take down the zone entirely. It's also still painfully
inconvenient to update parent zones, that makes fixing mishaps
difficult. The amount of damage that a break in DNSSEC validation chain
could do is far greater than other implementations of crypto such as TLS
where it is limited to a service.

(Note that I'm not advocating against DNSSEC, as much as this email may
sound so. The things I mention are practical issues that I see as an
implementor.)

A colleague says "If TLD’s allowed UPDATE messages to be processed most
of the issues with DNSSEC would go away. At the moment we have a whole
series of kludges because people are scared of signed update messages."

		Mukund

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 09:03:41 +0200 (CEST)

On Wed, 16 Aug 2017, Mukund Sivaraman wrote:

> DNSSEC is brittle.

Absolutely. But before we were in a situation where people signed zones, 
screwed it up, and then the (sometime single) ISP running a validating 
resolver got the run-around "must be wrong at your end, nobody else is 
complaining" and the zone signing was never fixed.

Now I think we're past that. There are enough users behind validating 
resolvers nowadays that you can't get away with getting your signing 
wrong and blaming others.

Yes, we need better APIs so applications can tell the user what went 
wrong, instead of just throwing a DNS failure. If there is need to update 
the DNS specs for this to be possible, then that should be done.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 16 Aug 2017 12:34:45 +0530

> where it is limited to a service.

Caching can also exacerbate such problems making a bad situation worse,
so a fix may not be instantaneously observed. This is unlike with other
popular crypto protocols such as TLS.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 00:05:32 -0700

> are practical problems that need mitigation.

anybody who needs secure denial of existence, of wildcards or other 
data, should deploy dnssec.

anybody who needs their networking partners to have this, should urge 
their partners to deploy dnssec.

if we don't believe that this can be done, then we should give up on dnssec.

there is no middle road here.

-- 
P Vixie

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 16 Aug 2017 07:05:58 +0000

Is your RPZ a mixture ?

Doesn't RPZ rewrite DNS answer, break DNSSEC validation ?

Should we give up , or we shouldn't ?

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 00:06:43 -0700

> DNSSEC is brittle.

then let's fix it.

or give up on it.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 00:19:06 -0700

> (Without commenting about SWILD)

no.

> Doesn't RPZ rewrite DNS answer, break DNSSEC validation ?

the I-D advises against this. some implementations offer a switch to 
rewrite DNSSEC-signed results. i don't use this myself, and i recommend 
against its use. my reasoning is that if the initiator indicates a 
desire for dnssec meta data, and there is in fact dns metadata, then any 
lie will be transparently obvious, and you should not in that case tell 
that lie.

some time before bad people get around to using dnssec to bypass rpz, 
the spec will have to evolve to allow new signalling ("i want to hear 
both the truth and the lie, and please sign the lie with our shared key 
so i'll know it's from you"). i figure we have a few years to get it 
done. it's one of the first things this WG will take up if an RFC is 
published on the current protocol, at which point vernon and i have 
agreed to surrender change control.

thank you for giving me this platform to explain the dnssec dilemma 
faced by rpz, along with my position, and my expectations. RPZ is not 
meant to be a censorship tool and will not, and should not, work as one. 
DNS filtering must be seen as a value-add by its user community or else 
it should be, and will in fact be, nonfunctional.

> Should we give up , or we shouldn't ?

see #1, #4, especially #7, and #12 from <http://katsudon.net/?p=4746>.

your lacks of respect and of professionalism is noted.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Aug 2017 17:19:20 +1000

In message <20170816064855.GB16977@jurassic>, Mukund Sivaraman writes:
> A colleague says "If TLDs allowed UPDATE messages to be processed most

And there is even a IANA assign SRV prefix to allow UPDATE messages
to be directed to directed to a server other than those that are
answering the queries.  Apple was good enough to get it registered
several years ago.  SIG(0) and TSIG UPDATE messages are forwardable
so all the TLD operator needs to do is to redirect the messages to
the appropriate registrar, based on the records being updated, for
processing then return the reply.

Named forwards both types of messages and returns the replies so
this is all technically possible.

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 16 Aug 2017 08:18:03 +0000

> adoption of DNSSEC significantly.
+1
DNS Poison Attack risk such as Brazilian Bank Targeted By Phishing Site And
DNS Poisoning
<https://www.zscaler.com/blogs/research/brazilian-bank-targeted-phishing-site-and-dns-poisoning>is
the greatest motivation to deploy DNSSEC.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 16 Aug 2017 10:22:20 +0200

Moin!

> Queries for Temporary Domain Names/ All Queries: 0.12%
So you are designing a protocol change for 0.12% of your queries? IMHO 
not a
good use of engineering time.

> operating environment at present, because of low DNSSEC deployment.
Sorry can't read that, but from the abstract and your emails I think the 
main
flaw in your thinking is that you want to cache all the records, 
regardless of
how often they are queried. That is not how caching resolvers work. 
Records that
are not used frequently and most of these signalling queries are one 
time queries
just expire from the cache, either by LRU mechanism or TTL.

So long
-Ralf

---

From: Davey Song <[email-masked]>
Date: Wed, 16 Aug 2017 16:44:16 +0800

> taking so long to deploy, and these features are badly needed?" debate.
+1.

If any operator would like to implement SWILD without DNSSEC or NAT44
without IPv6, It's OK. It maybe a good solution in their network for their
custormer. I do know many people and solutions walk around DNSSEC, IPv6
(due to IPsec) and TLS for surveillance issues. But IETF as a worldwide
standard body has its position on the technical path towards a better
Internet.

Davey

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 16 Aug 2017 08:54:07 +0000

> good use of engineering time.

The temporary domain name's rate > 40%.

Every xxx/yyy/zzz.foo.com query must be sent to Authoritative Nameserver
for the subdomain wildcard same answer, we can try to reduce this cost, and
shorten the response laterncy.

> https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html
> >
> >
> > <
> https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html
> >

Yes, LRU and TTL can expire from the cache, which were also discussed in
the paper.

Recursives commonly cache "all queried domain in n days" for some
SERVFAIL/TIMEOUT condition, which has been documented in
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,  and we can make some
optimization.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Davey Song <[email-masked]>
Date: Wed, 16 Aug 2017 17:35:26 +0800

Accroding to your description, I feel that IPv6 has better chance to win
than its "brother" DNSSEC. LoL

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 12:01:03 +0200 (CEST)

> than its "brother" DNSSEC. LoL

Currently they're both winning, and in kind of the same fashion.

https://www.google.com/intl/en/ipv6/statistics.html

Clients are sitting behind DNSSEC validating resolvers, but there are few 
zones to validate (apart from in a few markets, like .se and .cz). Clients 
are more and more getting IPv6 enabled, but the long tail content is not 
being enabled, and neither is the enterprise.

So generally, enterprise is problematic in both spaces.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 08:54:28 -0400

El 16 ag 2017, a les 0:19, Lanlan Pan <[email-masked]> va escriure:
> We analyzed our recursive query log, about 18.6 billion queries from 12/01/2015 to 12/07/2015.
> We found about 4.7 Million temporary domains occupy the recursive's cache, which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, Cloudfront, Greencompute...
> 

Okay.   So it sounds like you have an algorithm for detecting temporary domain names.   It seems to me that a quicker solution to your problem is to publish an operational document describing that algorithm and proposing ways that recursive caches can use it to prune such domains from the cache early.

I'm curious if you studied the behavior of existing recursive caches in the presence of these domains: do they in fact cache at the rate you predict they will?   The reason I ask is that I know that my own company's cache, which is widely deployed in the exact scenario you are describing, has a pretty sophisticated set of heuristics for deciding what to cache.   It would surprise me if it exhibited the behavior you are concerned about.

BTW, your paper is behind a paywall, so please don't cite it as a reason to do anything in the IETF.   If you want the IETF to take action based on what is in the paper, you need to publish it openly.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 11:44:51 -0700

Davey Song wrote:
> without IPv6, It's OK. It maybe a good solution in their network for
> their custormer. I do know many people and solutions walk around DNSSEC,
> IPv6 (due to IPsec) and TLS for surveillance issues. But IETF as a
> worldwide standard body has its position on the technical path towards a
> better Internet.

agreed. and, see also:

https://mailarchive.ietf.org/arch/msg/ietf-announce/ObCNmWcsFPNTIdMX5fmbuJoKFR8

noting that DNSSEC isn't a form of confidentiality, the general spirit 
of the IAB's position as linked above, supports a co-goal of end-to-end 
authenticity. i see no reason to expend community development effort, or 
to add complexity costs, on alternatives in whole or in part to DNSSEC, 
unless it's a complete replacement protocol, or complete abandonment of 
the goal itself.

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 16 Aug 2017 23:09:17 -0000

>> series of kludges because people are scared of signed update messages."

Someone is wildly overoptimistic.  

The problem I run into over and over again is that I run someone's DNS
and other services, but I am not the registrant and I am not the
registrar, I just run the DNS.  Either I have to walk the registrant
through the process of installing DNSSEC keys, or she has to give me
her registrar account password, neither of which scales.  Slightly
more automatic processing of updates for which I do not have the
credentials will not help.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Aug 2017 13:47:47 +1000

> credentials will not help.

Or you can have credentials to allow the hoster to update the DS
records alone.  UPDATE allows for fine grained credentials.  Named
has had fine grain update support for over a decade now.  You can
specify keys that can do everything and you can specify keys that
can just update a single type.  This isn't hard to do.

The DNS hoster gives the registrant the public key they use to
update DS records.  This is passed to the registrar which uses it
to verify UPDATE requests that change the DS records.  You can do
similar with TSIG but that is a shared secret between three parties.

This is like using master keys and more specific keys.  The only
reason this isn't done today is that we aren't using UPDATE and are
forcing all the transactions through a web interface.

Mark

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 17 Aug 2017 04:09:34 +0000

Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU
& TTL works fine.
SWILD not save many online cache size, because of the queries rate.
And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,  the
rate can be about 10% for 1 day statistics. Because temporary domain names
expire after TTL time.  Ralf has similar curious.

The problem is:

1)  cache size
Recursives commonly cache "all queried domain in n days" for some
SERVFAIL/TIMEOUT condition, which has been documented in
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,  we can use heuristics
algorithm for deciding what to cache, or just use simple rule like "select
domain which queies time > 5 in last n days".
We can use SWILD to optimize it, not need to detecting, just remove items
which SWILD marked, to save cost.

2) cache miss
All of temporary subdomain wildcards will encounter cache miss.
Query xxx.foo.com,  then query yyy.foo.com, zzz.foo.com, ...
We can use SWILD to optimize it,  only query xxx.foo.com for the first time
and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative
server.

3) DDoS risk
The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC
unsigned.
For example,  [0-9]+.qzone.qq.com is a popular SNS website in China, like
facebook. If botnets send "popular website wildcards" to recursive,  the
cache size of recursive will rise, recursive can not just simply remove
them like some other random label attack.
We prefer recursive directly return the IP of subdomain wildcards, and not
rise recursive cach, not send repeat query to authoritative.

Ted Lemon <[email-masked]>于2017年8月16日周三 下午8:54写道：

> Okay.   So it sounds like you have an algorithm for detecting temporary
> domain names.   It seems to me that a quicker solution to your problem is
> to publish an operational document describing that algorithm and proposing
> ways that recursive caches can use it to prune such domains from the cache
> early.
>
> I'm curious if you studied the behavior of existing recursive caches in
> the presence of these domains: do they in fact cache at the rate you
> predict they will?   The reason I ask is that I know that my own company's
> cache, which is widely deployed in the exact scenario you are describing,
> has a pretty sophisticated set of heuristics for deciding what to cache.
> It would surprise me if it exhibited the behavior you are concerned about.
>
> BTW, your paper is behind a paywall, so please don't cite it as a reason
> to do anything in the IETF.   If you want the IETF to take action based on
> what is in the paper, you need to publish it openly.
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Petr Špaček <[email-masked]>
Date: Thu, 17 Aug 2017 09:39:49 +0200

> Someone is wildly overoptimistic.  

Or maybe not. CZ registry is now getting CDNSKEY from unsigned domains
and use the obtained value to derive parent-side DS. This allows even
third parties running DNS for the domain owner (e.g. Cloudflare) to
DNSSEC-sign domains with no action required from the domain owner.

Yes, someone might try to attack a domain using this. To lower
probability of this kind of attack CZ.NIC is nagging the technical
contact for one week before the DS gets installed into the CZ zone.

For further details please see
https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/

We will see how it goes.

-- 
Petr Špaček  @  CZ.NIC

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 17 Aug 2017 07:33:07 -0400

> credentials will not help.
Have a look at:
<
https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

It allows a registrar (or a registry in some ccTLD environments) to do
CDS/CDNSKEY without having to constantly scan their registrants' name
servers, and provides some advice on how to safely bootstrap DNSSEC using
CDS/CDNSKEY.

There's currently a registrar implementation at Gandi, enabled for the TLDs
for which they do DNSSEC (I believe it's beta, so you have to speak to
their support to find the API URI), and registry implementations at CIRA
(.ca) and APNIC (for their reverse zones).  The CZ.NIC folks have also
started building it into Fred, their open source registry software.

There are a few more changes the draft will go through before it's ready
for last call, but the API it describes should remain largely unchanged
from this point onward.

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2017 09:54:51 -0400

> https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

I've talked to Jacques about it, will try it when I have a chance. I only 
have two .CA domains so it's not a very high priority at this point.

I agree that at this point it's the most promising approach if registries 
and registrars can solve the metaproblem of finding the update server. 
There's a dismaying amount of pushback on RDAP among the ICANN registries 
(policy issues, nothing technical) so I'm not holding my breath.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Aug 2017 09:56:17 -0400

El 17 ag 2017, a les 0:09, Lanlan Pan <[email-masked]> va escriure:
> We can use SWILD to optimize it, not need to detecting, just remove items which SWILD marked, to save cost.

So, can you talk about how your proposal saves cost over using a heuristic?

> Query xxx.foo.com <http://xxx.foo.com/>,  then query yyy.foo.com <http://yyy.foo.com/>, zzz.foo.com <http://zzz.foo.com/>, ...
> We can use SWILD to optimize it,  only query xxx.foo.com <http://xxx.foo.com/> for the first time and get SWILD, avoid to send yyy/zzz.foo.com <http://zzz.foo.com/> queries to authoritative server.

Can you characterize why sending these queries to the authoritative server is a problem?

> 3) DDoS risk 
> The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC unsigned.
> For example,  [0-9]+.qzone.qq.com <http://qzone.qq.com/> is a popular SNS website in China, like facebook. If botnets send "popular website wildcards" to recursive,  the cache size of recursive will rise, recursive can not just simply remove them like some other random label attack.
> We prefer recursive directly return the IP of subdomain wildcards, and not rise recursive cach, not send repeat query to authoritative.

Why do you prefer this?   Just saying "we prefer ..." is not a reason for the IETF to standardize something.

There are a bunch of problems with your proposal, as I'm sure others have remarked before.   It breaks DNSSEC validation for stub resolvers that aren't aware of SWILD.  In the absence of DNSSEC validation, it creates a new and very effective spoofing attack (poison the cache with bogus SWILD records).   Etc.

So you need to clearly explain why it is that you prefer this approach, and not just say that it's something you like.   Are you using it in production?   Do you have data on what it does?   Do you have data on the behavior of real-world caches that you can cite that shows that SWILD would produce more of an improvement than just using a better cache aging heuristic?

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2017 10:13:54 -0400

On Thu, 17 Aug 2017, Mark Andrews wrote:
> records alone.

Of course, but that's independent of how you present the updates to the 
registry or registrar.

Regards,

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 17 Aug 2017 11:16:20 -0400

Moin!

> expire after TTL time.  Ralf has similar curious.
As you mention me, with the data you supplied it is highly unlikely that a
lot of records will still be active in the Cache because of the TTL and
how least recently used (LRU) algorithms work.

> https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
That is not what the draft suggest and is not what the current
implementations of this or similar features do. They all rely on a cache
with a fixed size and if the record that normally would be expired is
still in the cache extend it's lifetime when queried. The records you
mention are not queried and thus would be expired because other records
that are queried more frequently would have overwritten them anyway.

There also is nearly no harm if these queries fail in case the
authoriative is not responding as most of those queries you describe
are computer and not human generated. The draft above and similar
techniques where done because of the twitter.com problem. Now I can
assure you that twitter.com will always be hot (asked at least every
couple of seconds) in a regular resolver at your ISP or a provider
of DNS services, and thus the expired record will probably still be
in the cache.

> which SWILD marked, to save cost.
The cost of sending a query now and then is very low resolvers do that all
the time and the rate on which they have to do that is very low. However to
actually save costs you would have to deploy your proposal on the
authoritative server that have that behaviour and the resolvers. Good luck
with that. I also assume some of the authorities are actually interested in
the queries so they would not implement your proposal even if they could,
making the theoretical improvement of 0.12% even smaller.

> and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative
See above.

> them like some other random label attack.
As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall attacks
as others call them are usually asking every subdomain once (and these botnets
take great care on doing this) the record would be removed by the least
recently used (LRU) algorithm when other records that are used more are
questioned.

While these attacks on recursive resolvers can stress the recursive to
authoritative part of the resolver there are techniques to limit the
exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring
Workshop in Amsterdam on that topic:
	https://indico.dns-oarc.net/event/21/contribution/29
and the summary of it is that all major vendors of recursive resolvers
handle this, so again while your solution would be one once universally
deployed there are already solutions to the problem out there, so why do
another one?

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Aug 2017 10:11:53 +1000

In message <[email-masked]>, "John R Levine" wri
> Of course, but that's independent of how you present the updates to the 

Yet, you chose to attempt to shoot down the proposal based on the
premise that you would be giving up full control.  Fine grain control
using UPDATE has existed in nameservers since 2000.  I'm yet to
here of anyone doing fine grain control via the web .

Mark

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2017 21:13:45 -0400

On Fri, 18 Aug 2017, Mark Andrews wrote:
> premise that you would be giving up full control.

You appear to be responding to someone else.  My point is that in 
practice, registries do not provide credentials for DNSSEC updates only, 
regardless of how they're presented.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Aug 2017 11:36:01 +1000

> regardless of how they're presented.

And the proposal was for registrars to process them except in the
case where the registry and registrar are the same entity.  The
only thing the registry needs to run is a forwarding agent which
looks at the name of the zone to be updated (sanity checking and
possible database selection for the next step) and the name of the
first record to be updated in the update section to find which
registrar to forward the update to.  This is similar to how nsupdate
works out which zone to update without being told explicitly.

All validation (TSIG/SIG(0)), beyond is the UPDATE in scope, is
done by the registrar which doesn't require the registry to handle
any credentials.

---

From: "John R Levine" <[email-masked]>
Date: 17 Aug 2017 22:39:31 -0400

> works out which zone to update without being told explicitly.

I'm sorry, but once again I can't see how response is related to what 
you're responding to.

It is a business issue whether the DNSSEC records (and the NS for that 
matter) are updated through the registry or the registrar.  Some do it one 
way, some do it the other, and the registars and registries I've talked to 
feel very strongly about whichever way they do it.  Either way, the 
problem is that almost none of them issue credentials that let you update 
a zone's DNSSEC separate from letting you update everything else about a 
registrant.

As I've said a couple of times, where you present those non-existent 
credentials and whether you do it through TSIG or some web thing (web 
servers are really good at 3xx redirects) is an implementation nit.  At 
this point Jacques' proposal that gives you a challenge token to stick in 
your zone to prove you're authorized is looking pretty good.

R's,
John

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 18 Aug 2017 07:21:10 +0200

On 18 Aug 2017, at 4:39, John R Levine wrote:

> Some do it one way, some do it the other, and the registars and registries I've talked to feel very strongly about whichever way they do it.

Correct, and that is why my only strong view is that both mechanisms can be implemented by the solution IETF develops (including ability to say "NO" to the not chosen option).

   Patrik

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 18 Aug 2017 15:33:06 +0000

Thanks a lot for your pertinent comments, :-)

> So, can you talk about how your proposal saves cost over using a heuristic?
It can be used with cache aging heuristic.
Heuristic read in aaa/bbb/ccc.foo.com, expire and move out;  then read in
xxx/yyy/zzz.foo.com,  expire and move out;  loop...
=> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read, it
will reduce the load of move in/out.

> We can use SWILD to optimize it,  only query xxx.foo.com for the first
> time and get SWILD, avoid to send yyy/zzz.foo.com queries to
> authoritative server.
>
>

Ok, Similar to RFC8198 section 6
<https://datatracker.ietf.org/doc/html/rfc8198#section-6>
Benefit but not problem,  directly return from cache, avoid send queries to
authoritative, and wait for response, reduce laterncy.

> the IETF to standardize something.

Sorry, my expression is fault.

More details:
1) All of the attack botnets were customers of ISP, sent queries to ISP
recursive with low rate, so all of the client's IP addresses were
"legitimate", could not simply use ACL.
2) Normal users also visit [0-9]+.qzone.qq.com, all the the random queries
domain seems to "legitimate".
=> The client ip addresses and the random subdomains are all in the
whitelist, not in blacklist.
3) ISP didn't have any DNS firewall equipment ( very sad situation, but it
was true ) to take over the response of "*.qzone.qq.com".

In this weaker scenario,  it will be better if give recursive more
information to directly answer queries from cache, and make recursive not
to send/cache many subdomains query/response.
Of course, we can defense the attack with professional operation, solve the
problem very well. But there are also many more weaker recursive only run
bind software, without any protection...

> There are a bunch of problems with your proposal, as I'm sure others have
> remarked before.   It breaks DNSSEC validation for stub resolvers that
> aren't aware of SWILD.  In the absence of DNSSEC validation, it creates a
> new and very effective spoofing attack (poison the cache with bogus SWILD
> records).   Etc.
>

> So you need to clearly explain why it is that you prefer this approach,
> and not just say that it's something you like.   Are you using it in
> production?   Do you have data on what it does?   Do you have data on the
> behavior of real-world caches that you can cite that shows that SWILD would
> produce more of an improvement than just using a better cache aging
> heuristic?
>

I will reconsider these problems of the proposal, make the improvement
analysis on real-world caches before next step.
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 18 Aug 2017 16:37:18 +0000

Thanks a lot for your detail analysis, :-)

> of DNS services, and thus the expired record will probably still be
You are totally right.
I admit the online cache size is not a problem on fixed size LRU/TTL
refresh.

> making the theoretical improvement of 0.12% even smaller.
0.12% is the rate of recursive queries times.
authorities's improvement rate is not 0.12%, it depends on the query
distribution of subdomain wildcards on the whole zone, and the number of
recursives that enable SWILD.

> time
same as above, and the above reply to Ted, :-)

> deployed there are already solutions to the problem out there, so why do
See also the above reply to Ted.
All major vendors of recursive resolvers can deal "legitimate subdomain
wildcards" problem with some feature like Response Rate Limiting.
The difference of my solution is directly reply IP to all "legitimate"
clients' low rate queries, not move in/out the subdomain wildcard records
with LRU.

So long
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2017 13:05:10 -0400

El 18 ag 2017, a les 11:33, Lanlan Pan <[email-masked]> va escriure:
> Heuristic read in aaa/bbb/ccc.foo.com <http://ccc.foo.com/>, expire and move out;  then read in xxx/yyy/zzz.foo.com <http://zzz.foo.com/>,  expire and move out;  loop...
> => Map aaa/bbb/ccc/xxx/yy/zzz.foo.com <http://zzz.foo.com/> to *.foo.com <http://foo.com/> when heuristic read, it will reduce the load of move in/out.

By "move out" you mean "remove," right?   Move out implies that you are moving it somewhere.   You haven't actually answered my question.  You say that SWILD will remove the load, but you don't give any evidence of this.

> Ok, Similar to RFC8198 section 6 <https://datatracker.ietf.org/doc/html/rfc8198#section-6>
> Benefit but not problem,  directly return from cache, avoid send queries to authoritative, and wait for response, reduce laterncy.

Okay, but this isn't a reason to prefer this to existing, standardized technology.

> 1) All of the attack botnets were customers of ISP, sent queries to ISP recursive with low rate, so all of the client's IP addresses were "legitimate", could not simply use ACL.
> 2) Normal users also visit [0-9]+.qzone.qq.com <http://qzone.qq.com/>, all the the random queries domain seems to "legitimate".
> => The client ip addresses and the random subdomains are all in the whitelist, not in blacklist.
> 3) ISP didn't have any DNS firewall equipment ( very sad situation, but it was true ) to take over the response of "*.qzone.qq.com <http://qzone.qq.com/>".
> 
> In this weaker scenario,  it will be better if give recursive more information to directly answer queries from cache, and make recursive not to send/cache many subdomains query/response.
> Of course, we can defense the attack with professional operation, solve the problem very well. But there are also many more weaker recursive only run bind software, without any protection...

Maybe they should upgrade.

> I will reconsider these problems of the proposal, make the improvement analysis on real-world caches before next step.

Thanks!   However, I would really encourage you to step back from your proposal and see if there's a way to accomplish what you want without adding this resource record.   I think you can get the same results you want without SWILD, and the result will be a lot better for the DNS as a whole.

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2017 01:48:50 -0000

>https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/

That's certainly one of the approaches that Olafur suggested, and it
would definitely be easy to implement.

Please let us know what you learn.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Mon, 21 Aug 2017 14:44:30 -0400

I was really trying to stay out of this thread...

On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon <[email-masked]> wrote:
> By "move out" you mean "remove," right?   Move out implies that you are
> moving it somewhere.   You haven't actually answered my question.  You say
> that SWILD will remove the load, but you don't give any evidence of this.

Yup.

Earlier in the thread, one of justifications for this work was "DNS
Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS
Traffic." (posted by Lanlan Pan).
In the abstract of the same is: "Disposable domains are likely
generated automatically, characterized by a “one-time use” pattern,
and appear to be used as a way of “signaling” via DNS queries."

The document contains some examples of these "disposable domains", including:
0.0.0.0.1.0.0.4e.135jg5e1pd7s4735ftrqweufm5.avqs.mcafee.com

McAfee's site says: "GTI File Reputation looks for suspicious
programs, Portable Document Format (PDF) files, and Android
Application Package (.APK) files that are active on endpoints running
McAfee products, including Endpoint Security (ENS), VirusScan
Enterprise (VSE), and SaaS Endpoint Protection (formerly known as
Total Protection Service). If any suspicious files are found that do
not trigger existing signature DAT files, GTI sends a DNS request to a
central database server hosted by McAfee Labs."

Basically, the way that this works is to generate a hash (or similar)
of an object and query that hash in the DNS -- information is returned
encoded in the address.
It is quite clear that McAfee could not (and would not) want to
publish a record saying that this is a wildcard -- if they did, they
would either mark all objects as safe, or as malicious.

Another example is:
load-0-p-01.up-1852280.mem-251379712-24440832-0-p-50.swap-236691456-297943040-0-p-44.3302068.1222092134.device.trans.manage.esoft.com
Fascinating, but device.trans.manage.esoft.com has no incentive to
publish a wildcard marker -- the whole purpose of this query appears
to get data back to manage.esoft.com -- having this get answered from
an intermediate cache would defeat this.

The third example is:
p2.a22a43lt5rwfg.ihg5ki5i6q3cfn3n.191742.s1.v4.ipv6-exp.l.google.com
Lorenzo Colitti, Steinar, Erik Kline, Tiziana Refice have a good
writeup of the purpose of these here: "Evaluating IPv6 Adoption in the
Internet" - https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36240.pdf
Again, these queries are being made for a reason -- it isn't that the
senders figured "I know, let's make a DNS query for fun!!!" - they
wanted to query for some data, or send some data -- like the abstract
says: "“signaling” via DNS queries."

In all of the above, publishing a "this is a wildcard" completely
breaks the purpose of the queries, and so there is no incentive for
these entities to publish such a record...

>> time and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative
>> server.
>>
>>

For the examples used in the paper justifying this, it's not a
problem, it's the purpose :-)

>> cache size of recursive will rise, recursive can not just simply remove them
>> like some other random label attack.
> information to directly answer queries from cache, and make recursive not to
> send/cache many subdomains query/response.
> Thanks!   However, I would really encourage you to step back from your
> proposal and see if there's a way to accomplish what you want without adding
> this resource record.   I think you can get the same results you want
> without SWILD, and the result will be a lot better for the DNS as a whole.
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 22 Aug 2017 07:52:38 +0000

Hi Warren,

Thanks for your work, :-)

I totally agree:  Not all Disposable Domains are wildcards like
xxx.github.io / xxx.blogspot.com / xxx.qzone.qq.com. So, wildcard solution
can not cover all example Disposable/Temporary Domains in the paper, as
your analysis.

The question is how to avoid unnecessary caches and queries, give recursive
more power to defense with wildcard issue.

As Ted's advice, for a better justification, I will do more analysis on
recursive cache, which kind of temporary domain is "particular", wildcard
domains or "domains has no incentive to publish a wildcard marker".

Warren Kumari <[email-masked]>于2017年8月22日周二 上午2:45写道：

> Internet" -
> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36240.pdf
> authoritative
> >> Can you characterize why sending these queries to the authoritative
> server
> >> is a problem?
> >
>
> >> Why do you prefer this?   Just saying "we prefer ..." is not a reason
> for
> >> the IETF to standardize something.
> >
> >
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Petr Špaček <[email-masked]>
Date: Tue, 22 Aug 2017 16:17:39 +0200

> Please let us know what you learn.

Few people asked me privately about more details so I'm going to post
our IEPG presentation here as well:

http://iepg.org/2017-07-16-ietf99/Fully%20automatic%20DNSSEC%20-%20final.pdf

Feel free to play with it, we very much welcome feedback!
Please direct further questions to Jaromír Talíř <[email-masked]>.

Have fun!

-- 
Petr Špaček  @  CZ.NIC