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

Discussion:

余坤

2014-12-18 07:21:36 UTC

Hi all,
I downloaded the code from
http://unbound.nlnetlabs.nl/svn/branches/edns-subnet/ and configured
unbound with "--enable-subnet".
Initial test shows that unbound indeed can process ECS queries but I cannot
figure out how to config a white list of servers that support ECS in the
config file.
I have gone through all the documentation and readmes but found nothing.
Can someone kindly show me how to do this?
Any help would be highly appreciated.

Regards,

--
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile PhoneïŒ+86 13466535220

Yuri Schaeffer

2014-12-18 08:32:09 UTC

Permalink

Hi Kun YU,

Post by ä½å¤
Initial test shows that unbound indeed can process ECS queries but
I cannot figure out how to config a white list of servers that
support ECS in the config file.

The unbound.conf man page should have what you are looking for. ECS
relevant bits:

"""

send-client-subnet: <IP address>
Send client source address to this authority. Append /num to indicate a
classless delegation netblock, for example like 10.2.3.4/24 or
2001::11/64. Can be given multiple times. Authorities not listed will
not receive edns-subnet information.

client-subnet-opcode: <number>
Specify positive integer smaller than 65536. Defaults to 8.

max-client-subnet-ipv6: <number>
Specifies the maximum prefix length of the client source address we are
willing to expose to third par? ties for IPv6. Defaults to 64.

max-client-subnet-ipv4: <number>
Specifies the maximum prefix length of the client source address we are
willing to expose to third par? ties for IPv4. Defaults to 24.

"""

Regards,
Yuri

lin

2014-12-18 09:05:09 UTC

Permalink

very thanks.
Do the unbound cache the result that contain edns-client-subnet information?

------------------ Original ------------------
From: "Yuri Schaeffer";<***@nlnetlabs.nl>;
Date: Thu, Dec 18, 2014 04:32 PM
To: "unbound-users"<unbound-***@unbound.net>;

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kun YU,

Post by ä½å¤
Initial test shows that unbound indeed can process ECS queries but
I cannot figure out how to config a white list of servers that
support ECS in the config file.

Yuri Schaeffer

2014-12-18 10:13:14 UTC

Permalink

very thanks. Do the unbound cache the result that contain
edns-client-subnet information?

Larry Havemann

2014-12-18 18:03:01 UTC

Permalink

Just a simple warning on using this branch, none of the issues detailed in
this mailing list thread have been addressed:
http://t28223.network-dns-unbound-user.dnstalk.us/edns-client-subnets-t28223.html

-Larry

-Larry

Post by lin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

very thanks. Do the unbound cache the result that contain
edns-client-subnet information?

Yes!
It has an additional cache for ECS responses. For performance reasons
lookups in this cache are only done when there are reasons to believe
it is necessary. I.e. 1) When an answer is not found in the regular
cache and the authority server is whitelisted. or 2) The client
includes ECS option.
//Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlSSqLoACgkQI3PTR4mhaviDBgCgzrnSOCX0wggIdjF2WkCtDbiR
WcUAn3zQ0WDD9lsonKs3XdB8PKmEmXjM
=3o06
-----END PGP SIGNATURE-----
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

余坤

2014-12-24 09:07:52 UTC

Permalink

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 supports ECS in China, i.e. all name
servers of qq.com in China responses correctly when ECS is set in the
query. But qq.com uses Akamai to deliver contents outside China. When
unbound receives a query of www.qq.com with client=18.0.0.0/8, the name
server of 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 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 www.qq.com
;; ANSWER SECTION:
www.qq.com. 300 IN A 115.25.209.39 <= IP in Beijing China

./dig @121.194.13.147 www.qq.com +client=60.255.0.0/16
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 60.255.0.0/16/24
;; QUESTION SECTION:
;www.qq.com. IN A

;; ANSWER SECTION:
www.qq.com. 300 IN A 175.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 www.qq.com +client=18.0.0.0/8
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 18.0.0.0/8/0
;; QUESTION SECTION:
;www.qq.com. IN A

;; ANSWER SECTION:
www.qq.com. 299 IN CNAME qq.com.edgesuite.net.
qq.com.edgesuite.net. 21600 IN CNAME a1574.b.akamai.net.
a1574.b.akamai.net. 20 IN A 23.201.102.40 <= Akamai's IP address
a1574.b.akamai.net. 20 IN A 23.201.102.41

Now query unbound without ECS option:
./dig @121.194.13.147 www.qq.com
;; ANSWER SECTION:
www.qq.com. 292 IN CNAME qq.com.edgesuite.net.
qq.com.edgesuite.net. 21593 IN CNAME a1574.b.akamai.net.
a1574.b.akamai.net. 13 IN A 23.201.102.40 <= Still Akamai's address!
a1574.b.akamai.net. 13 IN A 23.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. The best
choice can be determined by longest prefix match of client subnet.

Regards,
Kun

Post by Larry Havemann
Just a simple warning on using this branch, none of the issues detailed in
http://t28223.network-dns-unbound-user.dnstalk.us/edns-client-subnets-t28223.html
-Larry
-Larry

Post by lin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

very thanks. Do the unbound cache the result that contain
edns-client-subnet information?

_______________________________________________
Unbound-users mailing list
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

Yuri Schaeffer

2014-12-30 09:49:41 UTC

Permalink

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

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
<http://www.qq.com> ;; ANSWER SECTION: www.qq.com
<http://www.qq.com>.300INA115.25.209.39 <= IP in Beijing China
<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
<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
<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

Larry Havemann

2015-01-05 18:16:23 UTC

Permalink

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

Post by lin
-----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

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
<http://www.qq.com> ;; ANSWER SECTION: www.qq.com
<http://www.qq.com>.300INA115.25.209.39 <= IP in Beijing China
<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
<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
<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

余坤

2015-01-06 00:32:47 UTC

Permalink

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.

Post by Larry Havemann
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

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
<http://www.qq.com> ;; ANSWER SECTION: www.qq.com
<http://www.qq.com>.300INA115.25.209.39 <= IP in Beijing China
<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
<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
<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

_______________________________________________
Unbound-users mailing list
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

Andrew Strohman

2015-01-06 02:31:25 UTC

Permalink

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.

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

Thanks,

Andy

Post by ä½å¤
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.

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
<http://www.qq.com> ;; ANSWER SECTION: www.qq.com
<http://www.qq.com>.300INA115.25.209.39 <= IP in Beijing China
<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
<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
<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

_______________________________________________
Unbound-users mailing list
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
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

余坤

2015-01-06 02:52:35 UTC

Permalink

Post by Andrew Strohman
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.

Post by Andrew Strohman
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,

Post by Andrew Strohman
Andy

Post by Larry Havemann
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

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
<http://www.qq.com> ;; ANSWER SECTION: www.qq.com
<http://www.qq.com>.300INA115.25.209.39 <= IP in Beijing China
<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
<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
<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

--
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile PhoneïŒ+86 13466535220

Yuri Schaeffer

2015-01-06 13:46:16 UTC

Permalink

Hi Larry,

Post by Larry Havemann
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.

I'm afraid this would not work sufficiently. Unbound does not know
which source addresses get handled incorrectly by the authority. Thus,
if no match is found in the subnet-cache has no choice than to ask the
authority. Effectively Unbound won't be able to cache at all for the
CDN queries.

There are two ways to look at this IMHO:
1) The setup is broken, you can't have authorities answer differently
and always expect to have an optimal answer.
2) The draft is broken because it can not deal with this setup.

I fail to see a way to fix this problem AND adhere to the draft AND
not cause unexpected failures for anyone else. I'm open for fresh
ideas though.

Regards,
Yuri

Miek Gieben

2015-01-06 14:07:48 UTC

Permalink

Post by ä½å¤
Hi Larry,

Post by Larry Havemann
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.
acceptable to anyone who chooses to enable ECS.

this is effectively the text in the draft:

If the address of the client does not match any network in the cache,
then the Recursive Resolver MUST behave as if no match was found and
perform resolution as usual. This is necessary to avoid suboptimal
replies in the cache from being returned to the wrong clients, and to
avoid a single request coming from a client on a different network
from polluting the cache with a suboptimal reply for all the users of
that resolver.

Post by ä½å¤
1) The setup is broken, you can't have authorities answer differently
and always expect to have an optimal answer.

? Isn't this exactly what a CND dns server does?

Post by ä½å¤
2) The draft is broken because it can not deal with this setup.
I fail to see a way to fix this problem AND adhere to the draft AND
not cause unexpected failures for anyone else. I'm open for fresh
ideas though.
Regards,
Yuri
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

/Miek

--
Miek Gieben

余坤

2015-01-06 14:51:20 UTC

Permalink

Post by Miek Gieben

Post by ä½å¤
Hi Larry,
I think the best way to avoid getting non ecs answers when ecs is

Post by Larry Havemann
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. acceptable to anyone who
chooses to enable ECS.

If the address of the client does not match any network in the cache,
then the Recursive Resolver MUST behave as if no match was found and
perform resolution as usual. This is necessary to avoid suboptimal
replies in the cache from being returned to the wrong clients, and to
avoid a single request coming from a client on a different network
from polluting the cache with a suboptimal reply for all the users of
that resolver.
This is why I believe compiling a list of DNS servers who support client

subnet is not enough. There should be another option to config a list of
domains which supports client subnet. Any records in these domains should
be cached in secondary cache instead of the primary one.

Post by Miek Gieben

Post by ä½å¤
1) The setup is broken, you can't have authorities answer differently
and always expect to have an optimal answer.

? Isn't this exactly what a CND dns server does?
2) The draft is broken because it can not deal with this setup.

Post by ä½å¤
I fail to see a way to fix this problem AND adhere to the draft AND
not cause unexpected failures for anyone else. I'm open for fresh
ideas though.
Regards,
Yuri
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

/Miek
--
Miek Gieben
_______________________________________________
Unbound-users mailing list
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

Miek Gieben

2015-01-06 15:16:23 UTC

Permalink

Post by ä½å¤

Post by Miek Gieben
If the address of the client does not match any network in the cache,
then the Recursive Resolver MUST behave as if no match was found and
perform resolution as usual. This is necessary to avoid suboptimal
replies in the cache from being returned to the wrong clients, and to
avoid a single request coming from a client on a different network
from polluting the cache with a suboptimal reply for all the users of
that resolver.
This is why I believe compiling a list of DNS servers who support client

While I can see where you are coming from, but hardcoding this in a config
file is not an option.

/Miek

--
Miek Gieben

余坤

2015-01-06 15:39:50 UTC

Permalink

recall this option:"send-client-subnet: <IP address>"
although send-client-subnet command support IP prefix, it's not easy to
aggregate DNS servers that support ECS.
It's safe to assume the number of DNS servers and the number of domains
that support ECS are comparable. Thus compiling a list of domains with ECS
support in the config file is totally possible, especially when ECS is not
wildly used nowadays.

Post by Miek Gieben

Post by ä½å¤

While I can see where you are coming from, but hardcoding this in a config
file is not an option.
/Miek
--
Miek Gieben

--
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile PhoneïŒ+86 13466535220

Over Dexia

2015-01-06 15:50:24 UTC

Permalink

Post by Miek Gieben

Post by ä½å¤

Post by Miek Gieben
This is why I believe compiling a list of DNS servers who support client

While I can see where you are coming from, but hardcoding this in a config
file is not an option.

I can see where you are coming from, but instead of viewing it as
"hardcoding ECS capabilities of domains" it could be regarded as
"marking domains for 'query ecs module first' (expensive)" ... that
would be more like a feature.
Still doesn't feel very good, admittedly a workaround for a draft not
covering difficult real-life scenarios, but would mitigate most
objections raised, wouldn't it?

regards, jo.

Over Dexia

2015-01-06 18:32:14 UTC

Permalink

How about adding a flag to the rrset cache for each authority. If the
flag shows ecs support pass it to that module if not send it to regular
cache. Ask every authority not in the rrset cache if it supports ecs
before sending it the query.

That would induce the penalty of consulting the ecs module first for all
domains supporting it, even if it isn't required by the query, which was
to be avoided...

But I believe that would be mitigated by storing the no-ecs response
with a source 0.0.0.0/0 (like Kun YU proposed) in the subnet cache. If
all queries for that domain use this cache, the reply should be like
intended.

regards, jo.

Yuri Schaeffer

2015-01-07 22:23:48 UTC

Permalink

Post by Over Dexia
But I believe that would be mitigated by storing the no-ecs
response with a source 0.0.0.0/0 (like Kun YU proposed) in the
subnet cache. If all queries for that domain use this cache, the
reply should be like intended.

Think about what having a scope netmask of 0 means:
"The most specific answer available for your source IP has the first
0 bits in common with the address 0.0.0.0"

Thus any query will match this cache entry. Which will result in the
same behaviour as the current implementation.

//Yuri

余坤

2015-01-08 00:59:53 UTC

Permalink

If 0.0.0.0/0 is not a good idea, how about setting the prefix length
as max-client-subnet-ipv4 option?
According to unbound.conf manual,
max-client-subnet-ipv4: <number>
Specifies the maximum prefix length of the client source address we
are willing to expose to third parties for IPv4. Defaults to 24.

Since this is the default prefix length exposed to the DNS server that
supports ECS, the records returned by the DNS server must be optimal for
the prefix with a length set by max-client-subnet-ipv4/6.

Post by lin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"The most specific answer available for your source IP has the first
0 bits in common with the address 0.0.0.0"
Thus any query will match this cache entry. Which will result in the
same behaviour as the current implementation.
//Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlStsfQACgkQI3PTR4mhavjOlACeLaRnZA849R3ZbZcRZcNY45dg
5uYAnAzrQzv7SsX6a44y/YM032KGk3Lm
=T1fI
-----END PGP SIGNATURE-----
_______________________________________________
Unbound-users mailing list
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

Yuri Schaeffer

2015-01-08 11:01:40 UTC

Permalink

Post by ä½å¤
If 0.0.0.0/0 is not a good idea, how about setting the prefix
length as max-client-subnet-ipv4 option?

We've performed some thought experiments with this idea as well.
However this would create some new problems.

My objections:
- - This goes against the specifications.
- - We'd be making up authoritative data.

I believe that the setup you are describing is not compatible with the
draft and the only way for Unbound to deal with it is also to go
against the specs. The problem is that your server -depending on query
content!- signals support or no support for ECS. It is explicitly the
job of the resolver to cache this information.

What should happen is that the answers of the queries relayed to the
CDN should get a /24 (or whatever you choose) ECS option returned.

Additionally, we may be able to 'punish' less harsh when we get a
stray non-ECS answer while we know /some/ ECS data is available in the
cache. But that comes with its own set of problems (like loss of
caching for certain blocks when some authority server misbehaves), at
this time I'm unsure we should do this.

//Yuri

余坤

2015-01-09 05:37:13 UTC

Permalink

Looks like it's not easy to reach a rough consensus about this issue right
now. I've decided to wait until the draft becomes rfc and to evaluate
whether to add this functionality to our DNS server at that time.
The discussion helps me understand this issue much further than I expected.
Thank you guys.

Post by lin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by ä½å¤
If 0.0.0.0/0 is not a good idea, how about setting the prefix
length as max-client-subnet-ipv4 option?

We've performed some thought experiments with this idea as well.
However this would create some new problems.
- - This goes against the specifications.
- - We'd be making up authoritative data.
I believe that the setup you are describing is not compatible with the
draft and the only way for Unbound to deal with it is also to go
against the specs. The problem is that your server -depending on query
content!- signals support or no support for ECS. It is explicitly the
job of the resolver to cache this information.
What should happen is that the answers of the queries relayed to the
CDN should get a /24 (or whatever you choose) ECS option returned.
Additionally, we may be able to 'punish' less harsh when we get a
stray non-ECS answer while we know /some/ ECS data is available in the
cache. But that comes with its own set of problems (like loss of
caching for certain blocks when some authority server misbehaves), at
this time I'm unsure we should do this.
//Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlSuY5QACgkQI3PTR4mhavh3GgCdHyj9OdpiJFbc6qTS4XrTW+19
eicAniEDm5AE2PZmS2VBQw6x+exIl4dt
=6DK5
-----END PGP SIGNATURE-----

--
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile PhoneïŒ+86 13466535220

Larry Havemann

2015-01-07 22:41:48 UTC

Permalink

Post by Over Dexia

That would induce the penalty of consulting the ecs module first for all
domains supporting it, even if it isn't required by the query, which was
to be avoided...

The idea here is to use the ecs module more when enabled not less. The
rrset cache is shared between the ecs module and normal unbound. So asking
the rrset cache if the authority supports ecs before querying the authority
does not touch the ecs module. The penalty you would take with this
approach is if the authority is not yet in the rrset cache you would have
to ask it if it supports ecs. But again, so long as it is documented
anyone enabling ecs should know there will be a small penalty.

-Larry