Connecting to dnsdist console prints 'Added downstream 0.0.0.0' #3257

Closed
ahupowerdns opened this Issue Jan 18, 2016 · 2 comments

Projects

None yet

2 participants

@ahupowerdns
Member

pi@raspberrypi ~/pdns/pdns/dnsdistdist $ sudo ./dnsdist -C plus.conf -c
Read configuration from 'plus.conf'
"Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0
Added downstream server 0.0.0.0:0"

This comes from the constructor, which also opens sockets and stuff. We should probably not be creating those objects in client mode.

@rgacogne
Member

I guess the reason we do is that newServer() returns a DownstreamState, so not returning anything might cause an error if the returned value is used later in the configuration. Do you think we should change that?

@ahupowerdns
Member

well, I don't know about the solution. I do know we are creating actual network connections to 0.0.0.0 now which is pretty odd in client mode. So a solution might be to recognize 'fake' entries?

@rgacogne rgacogne added a commit to rgacogne/pdns that referenced this issue Jan 19, 2016
@rgacogne rgacogne dnsdist: Do not create socket/thread for fake DS in client mode
While parsing the configuration in client mode, we create a fake
DownstreamState for each newServer() call, because we need it to
return a valid DownstreamState object. Unfortunately this leads
to the creation of a socket for 0.0.0.0, and a subsequent
connection attempt.
We now detect that the address does not make sense in this context
and do not create the associated socket.
Closes #3257.
d055e47
@rgacogne rgacogne added a commit to rgacogne/pdns that referenced this issue Jan 19, 2016
@rgacogne rgacogne dnsdist: Do not create socket/thread for fake DS in client mode
While parsing the configuration in client mode, we create a fake
DownstreamState for each newServer() call, because we need it to
return a valid DownstreamState object. Unfortunately this leads
to the creation of a socket for 0.0.0.0, and a subsequent
connection attempt.
We now detect that the address does not make sense in this context
and do not create the associated socket.
Closes #3257.
f99e3aa
@ahupowerdns ahupowerdns closed this in #3266 Jan 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment