amarbs opened a new issue, #7504: URL: https://github.com/apache/trafficcontrol/issues/7504
<!-- ************ STOP!! ************ If this issue identifies a security vulnerability, DO NOT submit it! Instead, contact the Apache Traffic Control Security Team at [email protected] and follow the guidelines at https://apache.org/security regarding vulnerability disclosure. - For *SUPPORT QUESTIONS*, use the #traffic-control channel on the ASF slack (https://s.apache.org/tc-slack-request) or the Traffic Control Users mailing list (send an email to [email protected] to subscribe). - Before submitting, please **SEARCH GITHUB** for a similar issue or PR * https://github.com/apache/trafficcontrol/issues * https://github.com/apache/trafficcontrol/pulls --> <!-- Do not submit security vulnerabilities or support requests here - see above --> ## This Bug Report affects these Traffic Control components: <!-- delete all those that don't apply --> - Traffic Router ## Current behavior: <!-- Describe how the bug happens --> traffic-router doesn’t seem to be considering ECS (EDNS0 client subnet) when the domain name has randomized case. Below is the TR access log for a ECS query for `cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us.` ` time=1683701671.265 qtype=DNS chi=180.151.43.134 rhi=127.0.0.1 ttms=1.073 xn=45923 fqdn=cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. type=A class=IN rcode=NOERROR rtype=GEO rloc="48.9,2.42" rdtl=- rerr="-" ttl="10 10 10" ans="159.60.139.64 159.60.139.63 159.60.139.65" svc="73dd3914-76fb-486a-987e-8338fb51870e" podName=traffic-router-756cc7df59-cgrvz ` Note that the `chi` correctly has the ECS IP from the query, which is `180.151…` and `rhi` correctly has TCP/UDP client IP `127.0.0.1`. The response also is as per the `chi`. Query used for above: `dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. +subnet=180.151.43.134/32` Below is the same query with randomized case in same domain name `cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us`. Note `cDn` and `sTaging`. Access log: `time=1683701746.164 qtype=DNS chi=127.0.0.1 rhi=- ttms=0.857 xn=27831 fqdn=cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us. type=A class=IN rcode=NOERROR rtype=GEO rloc="37.24,-121.78" rdtl=- rerr="-" ttl="10 10 10" ans="159.60.139.67 159.60.139.66 159.60.139.68" svc="73dd3914-76fb-486a-987e-8338fb51870e" podName=traffic-router-756cc7df59-cgrvz` Note that `rhi` is empty. And, `chi` is now the TCP/UDP client IP. It appears that TR is ignoring ECS IP now. Query used for above: `dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us. +subnet=180.151.43.134/32` ## Expected behavior: With case randomized domain also, TR should consider ECS IP for geo-lookup. This should reflect with correct values of `chi` and `rhi` populated in access-log. Now that google DNS has deployed case randomization defence across its sites (news [link](https://groups.google.com/g/public-dns-announce/c/MLsrx8dI2n4?pli=1)), this bug become quite evident. ## Steps to reproduce: <!-- If the current behavior is a bug, please provide the *STEPS TO REPRODUCE* and include the applicable TC version. --> version - v6.1.0 (not tested yet in 7.x) 1. Make a query to TR with ECS option. Ex: `dig @localhost cdn.73dd3914-76fb-486a-987e-8338fb51870e.cdn.staging.volterra.us. +subnet=180.151.43.134/32`. 2. Observe the access log. `chi` and `rhi` are correctly populated. Answer is as per geo-lookup of `chi`, that is ECS IP. 3. Make the same query as step (1) but with randomized domain name like `cdn.73dd3914-76fb-486a-987e-8338fb51870e.cDn.sTaging.volterra.us.`. Ensure that the case randomization is in the domain's deliveryservice and its parent parts. Randomization of the routing key (`cdn`) does not reproduce the bug. 4. Observe the access log. ECS IP is missing. `chi` instead contains L4 client IP. Answer is as per geo-lookup of L4 client IP. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
