Unexpected behavior with client-subnet-always-forward and serve-expired

[rs]

Describe the bug
When the client-subnet-always-forward option is enabled and the send-client-subnet field is left empty, it is expected that only downstream queries containing an ECS record would be sent upstream. However, the current behavior is that all queries are sent upstream with either the downstream ECS or the generated one, disregarding the "send-client-subnet" setting entirely.

To reproduce
Steps to reproduce the behavior:

1. Set client-subnet-always-forward to yes and do not specify a send-client-subnet
2. Perform a query with no ECS included
3. Check the produce upstream query

Expected behavior
The upstream query should not include an ECS option generated with the client source address.

System:

• Unbound version: 1.17.0
• OS: Linux
• unbound -V output:

Version 1.17.0

Configure line: --with-libevent --enable-subnet --enable-dnstap
Linked libs: libevent 2.1.8-stable (it uses epoll), OpenSSL 1.1.1k  FIPS 25 Mar 2021
Linked modules: dns64 subnetcache respip validator iterator

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

[Philip-NLnetLabs]

Hi, I'm unable to reproduce this problem. Can you append your unbound.conf to this issue?

[rs]

My bad, after further checking, the bug is a bit harder to reproduce. In order to reproduce, do the following with the same config:

1. dig @localhost www.google.com +subnet=1.0.0.0/24
2. dig @localhost www.google.com +subnet=2.0.0.0/24
3. dig @localhost www.google.com
4. dig @localhost www.google.com
5. dig @localhost www.google.com …

With this you should get two outbound queries with the ECS you requested for 1. and 2. Then you should get uncached requests with ECS = 127.0.0.0/24 for 3,4,5.

Let me know if you need more details.

[Philip-NLnetLabs]

I don't see any ECS in the response from unbound for 3, 4, and 5. And the request that goes upstream also doesn't have ECS for the queries 3, 4, and 5.

[rs]

Just to confirm, subnet is enable at compile time on your build?

[Philip-NLnetLabs]

Yes, I also see the subnet option come back in the first two queries, and I see the option go out upstream for the first two queries.

[rs]

After more testing, I found the right way to reproduce the issue. You need to add the following to the configuration:

    serve-expired: yes
    client-subnet-always-forward: yes

Then to reproduce:

1. perform a dig @localhost www.google.com
2. wait 300 seconds (RR's TTL) for the record to get out of the cache
3. perform another dig @localhost www.google.com

The dig after the record is out of cache will keep going to the upstream with the 127.0.0.0/24 ECS and won't be cached anymore. The response record will also have a fixed TTL of 30, which is the default value of serve-expired-reply-ttl. Once in this state, this record will never be cached again and will flood the upstream with the 127/24 ECS.

My guess is that we rather have a bug with serve-expired and ECS here. Let me know if you can reproduce this way.

[rs]

@Philip-NLnetLabs were you able to reproduce with the new steps above?

[Philip-NLnetLabs]

Yes, I see it as well. Thanks. I'll try to figure out why that happens.

[ShipeiXu]

测试在1.17.1版本已经修复.