Skip to content
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

Closed
apfohl opened this issue Nov 2, 2016 · 3 comments · Fixed by #5112

Comments

@apfohl
Copy link
Contributor

apfohl commented Nov 2, 2016

  • Program: Authoritative
  • Issue type: Bug report

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:

origin.example.com. A     127.0.0.1
origin.example.com. AAAA  ::1
alias.example.com.  ALIAS origin.example.com.

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 the resolver and outgoing-axfr-expand-alias option to my pdns.conf:

local-address=127.0.0.1
local-port=1234
resolver=127.0.0.1:5678
outgoing-axfr-expand-alias=on

Here's a littel scheme of my setup.

           req        AXFR              AXFR
Internet ------> NSD <----- OpenDNSSEC <----- PowerDNS <----- SQlite
                                              |     ^
                                             \|/    |
                              Internet <----- Unbound
                                         req    

Environment

  • Operating system: Ubuntu 14.04 LTS
  • Software version: 4.0.1
  • Software source: PowerDNS repository

Steps to reproduce

  1. Setup as described above
  2. Insert the above records into SQLite database
  3. Query: 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:

750: int ret1 = stubDoResolve(getRR<ALIASRecordContent>(zrr.dr)->d_content, QType::A, ips);
751: int ret2 = stubDoResolve(getRR<ALIASRecordContent>(zrr.dr)->d_content, QType::AAAA, ips);

the stub resolver is used to query for A and AAAA records of the target domain. Looking into pdns/stubresolver.cc:

54: s_stubresolvers.push_back(ComboAddress(::arg()["recursor"], 53));

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 to 53. 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 in pdns.conf, in pdns/stubresolver.cc.

@apfohl
Copy link
Contributor Author

apfohl commented Nov 7, 2016

I managed to enable my setup to work like expected. But it was not easy to find.

I used the /etc/default/pdns option RESOLVCONF_UPDATE_FORWARDERS and installed resolvconf. The original nameserver entries in /etc/resolv.conf are now overwritten with the one that is configured in pdns.conf. This makes PowerDNS to use only this server for resolving. The downside is, that my whole system now has to use the local resolver. I don't like that.

Any ideas how to get around this?

@zeha
Copy link
Collaborator

zeha commented Nov 11, 2016

In the end, I don't think the stubresolver should ever use the recursor setting, see #4616. But maybe a new setting would be alright...

@apfohl
Copy link
Contributor Author

apfohl commented Nov 14, 2016

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 /etc/resolv.conf. Maybe one could think about the push_back in the following line:

54: s_stubresolvers.push_back(ComboAddress(::arg()["recursor"], 53));

Wouldn't it make more sense to add it to the front of the list?

pieterlexis added a commit to pieterlexis/pdns that referenced this issue Mar 6, 2017
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback,
as this could be ourselves.

Closes PowerDNS#4655
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Mar 7, 2017
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback,
as this could be ourselves.

Closes PowerDNS#4655
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Mar 21, 2017
Use resolv.conf otherwise. Also, do not use 127.0.0.1:53 as fallback,
as this could be ourselves.

Closes PowerDNS#4655
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Nov 3, 2017
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)
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Nov 7, 2017
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)
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Nov 7, 2017
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)
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Nov 7, 2017
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)
pieterlexis added a commit to pieterlexis/pdns that referenced this issue Nov 13, 2017
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants