[Unbound-users] How to config whitelist for EDNS client subnetin unbound

Tue Jan 6 02:52:35 UTC 2015

On Tue, Jan 6, 2015 at 10:31 AM, Andrew Strohman <astrohman at edgecast.com>
wrote:

> In this case, it looks like the authority of www.qq.com does respond with
> ECS when it replies with the CNAME(US case).  It's only Akamai's authority
> which does not.
>
 I agree.

> So why is www.qq.com. in the primary cache?  It seems like it should not
> be.  It does make sense that  qq.com.edgesuite.net. and a1574.b.akamai.net.
> are in primary cache, but why would this effect the response for
> www.qq.com.?
>
> I assume that when unbound gets the final answer from Akamai without ECS
extension it decides to store all the records, including www. qq.com CNAME
qq.com.edgesuite.net, in the primary cache.
Thus I suggest to provide an option in unbound.conf to store all the
records of a domain in ECS cache. Records without an ECS extension can be
assigned a subnet of 0.0.0.0/0

Thanks,
>
> Andy
>
> On Mon, Jan 5, 2015 at 4:32 PM, 余坤 <yukun2005 at gmail.com> wrote:
>
>> Just like send-client-subnet command in unbound.conf, I prefer to provide
>> another option in the config file that compiles a white list for domains
>> which enables ECS. All the records from the domains in the white list
>> should be cached in ECS cache instead of the primary cache.
>>
>>
>> On Tue, Jan 6, 2015 at 2:16 AM, Larry Havemann <larry at edgecast.com>
>> wrote:
>>
>>> I think the best way to avoid getting non ecs answers when ecs is
>>> present would be to always pass the query to the ecs module.  Yes this
>>> would slow down non ecs queries, but would avoid the issue of returning a
>>> non ecs answer to an ecs query.  I think this should be acceptable to
>>> anyone who chooses to enable ECS.
>>>
>>> -Larry
>>>
>>> On Tue, Dec 30, 2014 at 1:49 AM, Yuri Schaeffer <yuri at nlnetlabs.nl>
>>> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hi Kun,
>>>>
>>>> Thank you for your feedback!
>>>>
>>>> Apart from the TTL issue it sounds like the software works as
>>>> advertised. The authority server indicated lack of ECS support so we
>>>> cache that information. This strategy greatly improves performance for
>>>> all non-ECS domains. (Read: it will keep stock Unbound performance)
>>>> Once the TTL expires the server is probed again.
>>>>
>>>> How do you propose Unbound should decide this information is a lie,
>>>> sometimes...? Would you be willing to sacrifice performance for all
>>>> non-ECS lookups greatly?
>>>>
>>>> Regards,
>>>> Yuri
>>>>
>>>> On 12/24/2014 10:07 AM, 余坤 wrote:
>>>> > Hi Larry, Yuri After a few days of testing, I'm afraid that this
>>>> > branch is not ready for production use yet. First, just like Larry
>>>> > has pointed out, RTT value in ECS cache does not decrease. Second,
>>>> > when a domain supports ECS partially, unbound may cache suboptimal
>>>> > results. For instance, www.qq.com <http://www.qq.com> supports ECS
>>>> > in China, i.e. all name servers of qq.com <http://qq.com> in China
>>>> > responses correctly when ECS is set in the query. But qq.com
>>>> > <http://qq.com> uses Akamai to deliver contents outside China.
>>>> > When unbound receives a query of www.qq.com <http://www.qq.com>
>>>> > with client=18.0.0.0/8 <http://18.0.0.0/8>, the name server of
>>>> > qq.com <http://qq.com> will redirect this query to Akamai. As we
>>>> > all know, Akamai doesn's support ECS, so name server of Akamai will
>>>> > rerurn a resource record without ECS option. This record ends up in
>>>> > the ordinary cache of unbount! How did I find out this record is
>>>> > cached in the ordinary cache? Because the TTL value of this records
>>>> > does decrease! So subsequent queries of qq.com <http://qq.com>
>>>> > without ECS option will be replied with an IP address in America!
>>>> > This may cause severe performance downgrade. A more specific
>>>> > example: dig @121.194.13.147 <http://121.194.13.147> www.qq.com
>>>> > <http://www.qq.com> ;; ANSWER SECTION: www.qq.com
>>>> > <http://www.qq.com>.300INA115.25.209.39  <= IP in Beijing China
>>>> >
>>>> > ./dig @121.194.13.147 <http://121.194.13.147> www.qq.com
>>>> > <http://www.qq.com> +client=60.255.0.0/16 <http://60.255.0.0/16> ;;
>>>> > OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;
>>>> > CLIENT-SUBNET: 60.255.0.0/16/24 <http://60.255.0.0/16/24> ;;
>>>> > QUESTION SECTION: ;www.qq.com <http://www.qq.com>.INA
>>>> >
>>>> > ;; ANSWER SECTION: www.qq.com
>>>> > <http://www.qq.com>.300INA175.155.116.108 <= IP in another city of
>>>> > China
>>>> >
>>>> > So far so good, now ask unbound with an IP address in America:
>>>> >
>>>> > ./dig @121.194.13.147 <http://121.194.13.147> www.qq.com
>>>> > <http://www.qq.com> +client=18.0.0.0/8 <http://18.0.0.0/8> ;; OPT
>>>> > PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;
>>>> > CLIENT-SUBNET: 18.0.0.0/8/0 <http://18.0.0.0/8/0> ;; QUESTION
>>>> > SECTION: ;www.qq.com <http://www.qq.com>.INA
>>>> >
>>>> > ;; ANSWER SECTION: www.qq.com
>>>> > <http://www.qq.com>.299INCNAMEqq.com.edgesuite.net
>>>> > <http://qq.com.edgesuite.net>. qq.com.edgesuite.net
>>>> > <http://qq.com.edgesuite.net>.21600INCNAMEa1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>. a1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>.20INA23.201.102.40  <= Akamai's IP
>>>> > address a1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>.20INA23.201.102.41
>>>> >
>>>> > Now query unbound without ECS option: ./dig @121.194.13.147
>>>> > <http://121.194.13.147> www.qq.com <http://www.qq.com> ;; ANSWER
>>>> > SECTION: www.qq.com
>>>> > <http://www.qq.com>.292INCNAMEqq.com.edgesuite.net
>>>> > <http://qq.com.edgesuite.net>. qq.com.edgesuite.net
>>>> > <http://qq.com.edgesuite.net>.21593INCNAMEa1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>. a1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>.13INA23.201.102.40  <= Still Akamai's
>>>> > address! a1574.b.akamai.net
>>>> > <http://a1574.b.akamai.net>.13INA23.201.102.41
>>>> >
>>>> > ;; Query time: 0 msec <= get result from cache
>>>> >
>>>> > In this way, unbound stores a sub optimal record in the main
>>>> > cache, subsequent queries will all get this record. This is not
>>>> > acceptable because it will cause too much inter-continent traffic.
>>>> > Since ECS is not a RFC yet, I assume partial support of ECS is
>>>> > quite common. Return sub optimal results to clients can cause
>>>> > serious performance problems. IMHO, unbound should provide a way to
>>>> > config which domain should be stored in ECS cache. In this way,
>>>> > even some of the name servers of a domain do not support ECS, all
>>>> > the records of this domain will be stored in ECS cache. Records
>>>> > without ECS information will have a subnet of 0.0.0.0/0
>>>> > <http://0.0.0.0/0>. The best choice can be determined by longest
>>>> > prefix match of client subnet.
>>>> >
>>>> > Regards, Kun
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iEYEARECAAYFAlSidTUACgkQI3PTR4mhavgQ/ACcDdjAFoKNGSfP4AwRxdjENcBx
>>>> POsAn3z6QX+OgY0/iBajcc7YrvdhkwaB
>>>> =K73M
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> Unbound-users mailing list
>>>> Unbound-users at unbound.net
>>>> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
>>>>
>>>
>>>
>

-- 
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile Phone：+86 13466535220
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20150106/e4684216/attachment.htm>