On Tue, Jan 6, 2015 at 10:31 AM, Andrew Strohman <[email protected]> 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, 余坤 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> 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
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
