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

Lanlan Pan <> Fri, 18 August 2017 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87AF0132964 for <>; Fri, 18 Aug 2017 08:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QNRYYapsS7oN for <>; Fri, 18 Aug 2017 08:33:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B1B8132977 for <>; Fri, 18 Aug 2017 08:33:19 -0700 (PDT)
Received: by with SMTP id c14so735283wmh.1 for <>; Fri, 18 Aug 2017 08:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fQlSfAejAEYnVGhVT6rBBJjhW8kjiWYPIsBumqsTTq4=; b=ui9MATyv8Qajx3xvH+1/Vm1f+b1Aa9C8DU5PPe0pzSc5Mem92qnPUMncemNUkhBGQ/ YKVLEpP9Ywr/VjWPjiLHFvtJPUNp7nG2Q4mhtL/sfB3l1DGhxAHcgpolpGwcWrRWke1l p65jO4E5lBDAR7tHj7YZTYIeEkbPM9rJHPQXKJBV4zjlbCzD/OX/jhcMvXok1eAukcSZ HcF+wf/TH0CS1yqlxSrVZf/lsQyZ2rN/eUPFDSxEreX43zruH8j1YtlE0EbyAuh0TYBf n+5qe/9HA1F68jeAPqdnTpeQLj7xYtVRtNQQUd766HNhVxVjJYyG0+yxZfq9Q7/S9dI9 D3ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fQlSfAejAEYnVGhVT6rBBJjhW8kjiWYPIsBumqsTTq4=; b=O6UYYsYcHjo/lSffmsTsMoUmyKMxP6zsBJrlEVgl+83t9oQn7sfvENI48Aw1nFBnQ+ 7tZEDRF/5zFPmNR0ckz8QI+oqNSV6a5rVYgEhtBjQLug1INzD3oLJtresaaFtFStLih+ Fg17sZFhbJeQVY4KzWuBMvf/g4FzE0v+fKzJvntXmNkaO3DWi2qmn3Npz2JYZAdU6VsQ uN2szAfspPIC8OVI/+PxLKy0WN5vh09Bx7B46TtK8tdlzDkGbNFAI0VV1jz+oO2UvE0I rBDMRfT3ZLInFme9y5Yxjwq789lHxVhcov5CyGfbI2ET0ppLGKi0et4HdXx5y3L0RRnZ 7Z4g==
X-Gm-Message-State: AHYfb5jewZTAMnjPo4CDb/tR7RWB8UOg8Te+gCxffik39NLyf82bQ4fG WTVoOXbjBc0q2PcJteTxy2IkIl/U3xnW
X-Received: by with SMTP id f26mr2264132edd.286.1503070398061; Fri, 18 Aug 2017 08:33:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lanlan Pan <>
Date: Fri, 18 Aug 2017 15:33:06 +0000
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop WG <>
Content-Type: multipart/alternative; boundary="f403045c4eea261eeb055708d940"
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Aug 2017 15:33:22 -0000

Thanks a lot for your pertinent comments, :-)

Ted Lemon <>于2017年8月17日周四 下午9:56写道:

> El 17 ag 2017, a les 0:09, Lanlan Pan <> 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?
It can be used with cache aging heuristic.
Heuristic read in aaa/bbb/, expire and move out;  then read in
xxx/yyy/,  expire and move out;  loop...
=> Map aaa/bbb/ccc/xxx/yy/ to * when heuristic read, it
will reduce the load of move in/out.

> 2) cache miss
> All of temporary subdomain wildcards will encounter cache miss.
> Query,  then query,, ...
> We can use SWILD to optimize it,  only query for the first
> time and get SWILD, avoid to send yyy/ queries to
> authoritative server.
> Can you characterize why sending these queries to the authoritative server
> is a problem?

Ok, Similar to RFC8198 section 6
Benefit but not problem,  directly return from cache, avoid send queries to
authoritative, and wait for response, reduce laterncy.

> 3) DDoS risk
> The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC
> unsigned.
> For example,  [0-9] 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.

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], 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 "*".

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