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,
Hi Kun YU,
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
very thanks.
Do the unbound cache the result that contain edns-client-subnet information?
------------------ Original ------------------
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
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
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
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
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.
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.
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
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,
Hi Larry,
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
[ Quoting <yuri@nlnetlabs.nl> in "Re: [Unbound-users] How to config w..." ]
Hi Larry,
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.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.
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.
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.
? Isn't this exactly what a CND dns server does?
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
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
/Miek
[ Quoting <yuri@nlnetlabs.nl> in "Re: [Unbound-users] How to config w..."
]Hi Larry,
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.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.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.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.
[ Quoting <yukun2005@gmail.com> in "Re: [Unbound-users] How to config w..." ]
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.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.
While I can see where you are coming from, but hardcoding this in a config
file is not an option.
/Miek
recall this option:“send-client-subnet: ”
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.
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.
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...
Also there's Yuris objection against using ecs always:
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
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