kong
kong copied to clipboard
set_target with hostname fails
Is there an existing issue for this?
- [X] I have searched the existing issues
Kong version ($ kong version
)
3.4.0
Current Behavior
According to the Kong API docs I should be able to call set_target to set the upstream target in my plugin. This does not appear to work unless an IP address is used.
I found this issue which appears to be the same but was recently closed without any specific resolution.
Expected Behavior
Calling set_target with a hostname should work.
Steps To Reproduce
This code fails:
function RedirectTest:access(conf)
local ok, err1 = kong.service.set_target("example.com", 443)
if not ok then
kong.log.err(err1)
return
end
end
It results in this error message:
2023/12/13 15:12:11 [error] 69#0: *150 [lua] init.lua:1214: balancer(): failed to set the current peer (address: example.com port: 443): no host allowed while connecting to upstream, client: 127.0.0.1, server: kong, request: "GET / HTTP/1.1", host: "myservice.com"
To verify that DNS resolution is working, I ran this code which works as expected:
local dnsclient = require("resty.dns.client")
function RedirectTest:access(conf)
local resp, err = dnsclient.resolve("example.com")
kong.log.debug(">>> IP: ", resp[1].address)
local ok, err1 = kong.service.set_target(resp[1].address, 443)
if not ok then
kong.log.err(err1)
return
end
end
I have also checked that DNS resolution works via a shell on the pod.
Anything else?
I am running Kong as a container locally in Docker (on MacOS).
I created an internal ticket (KAG-3500) to track this issue.
@chobits , do we have any update about this issue?
hi
This error log was reported by Kong.balancer()
, it seems balancer module does not do dns lookup for it, I still need some time to check
BTW for your code,
local ok, err1 = kong.service.set_target("example.com", 443) if not ok then kong.log.err(err1) return end
you dont need to check return value like ok, err1
of kong.service.set_target
, this function has no return value, it always successes.
hi, it's a conflict between the doc and its internal impelmentation, currently dns balancer will not actively resolve your setting host. using (KAG-3500) to track it.
Currently your resolved method, using dns_client to resolve it, is ok.
This issue is marked as stale because it has been open for 14 days with no activity.