-
Notifications
You must be signed in to change notification settings - Fork 904
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stub resolver does not use DNSproxy or ::arg()["recursor"] for ALIAS records if /etc/resolv.conf has "nameserver" entries #4655
Comments
I managed to enable my setup to work like expected. But it was not easy to find. I used the Any ideas how to get around this? |
In the end, I don't think the stubresolver should ever use the |
Yes right, but that wouldn't solve my problem. If that "new" setting will work the same way, it is useless, if there are nameservers set in
Wouldn't it make more sense to add it to the front of the list? |
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655 (cherry picked from commit 2b78726)
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655 (cherry picked from commit 2b78726)
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655 (cherry picked from commit 2b78726)
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655 (cherry picked from commit 2b78726)
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback, as this could be ourselves. Closes PowerDNS#4655 (cherry picked from commit 2b78726)
Short description
I discovered an issue, where the correct A and AAAA records for an ALIAS record can not be resolved.
What I want to achieve is updating the A and AAAA records for an ALIAS record during the AXFR of the zone including the ALIAS record. The special thing is, that the domain to which the ALIAS points is also included in the same zone. Here's the part of the zone which is important for that problem:
The problem is, that the PowerDNS server serving this zone is a hidden master. Thus, it is not reachable from the outside world. Its purpose is generating AXFR answers for an OpenDNSSEC service running on the same machine, which is itself creating AXFRs for the world reachable NSD which is presenting the signed zones to the world.
If an AXFR request is send from the OpenDNSSEC service to the PowerDNS server (hidden master), the ALIAS record is resolved to origin.example.com from the outside world (the public reachable NSD server). That is not what I want to achieve. I want to achive, that the ALIAS is resolved to origin.example.com on the PowerDNS server (hidden master). This is necessary, when origin.example.com is updated in the database of the hidden master server and a new AXFR is send to OpenDNSSEC for signing.
To solve this problem, I set up a local resolver (127.0.0.1:5678) with forwarding for the
example.com
domain to the hidden master (PowerDNS) and inserted theresolver
andoutgoing-axfr-expand-alias
option to mypdns.conf
:Here's a littel scheme of my setup.
Environment
Steps to reproduce
dig @127.0.0.1 -p 1234 alias.example.com.
and watch the log of the Unbound resolver. No requests are comming in from PowerDNS.Expected behaviour
I expect that the ALIAS record is replaced with the A and AAAA records of
origin.example.com.
in an AXRF, if the PowerDNS server is a hidden master.Actual behaviour
The ALIAS record is replaced with the A and AAAA records from the publicly deployed, signed version of the zone.
Other information
I searched the source code and found a few locations where the problem could have it's roots.
In
pdns/tcpreceiver.cc
:the stub resolver is used to query for A and AAAA records of the target domain. Looking into
pdns/stubresolver.cc
:the recursor option is pushed to the end of the list of IP addresses which are used for querying. If there are
nameserver
entries in/etc/resolv.conf
and these nameservers are working, the actual recursor is never queried. And maybe the custom port (5678) is rewritten to53
. Which could also cause the problem.Also there is no evidence of a DNSproxy which is also set up when the
recursor
option is set inpdns.conf
, inpdns/stubresolver.cc
.The text was updated successfully, but these errors were encountered: