Alias should not require resolver, nor should it use resolver first

[hubertnnn]

• Program: Authoritative
• Issue type: Bug report

Short description

When using ALIAS to point to a domain that is handled internally, the server is trying to find target domain using resolver.

Environment

• Operating system: Ubuntu 18.04
• Software version: 4.7.0-alpha1
• Software source: ppa

Steps to reproduce

1. In pdns.conf set

expand-alias=yes
resolver=8.8.8.8

2. In named.conf add

zone "projects.foo.internal" {
    type master;
    file "/etc/powerdns/zones/db.projects.foo.internal";
};

zone "servers.foo.internal" {
    type master;
    file "/etc/powerdns/zones/db.servers.foo.internal";
};

3. In zones/db.servers.foo.internal

$ORIGIN servers.foo.internal.
$TTL    3600
@   IN  SOA ns1.foo.internal. admin.foo.internal. 1 86400 3600 2592000 3600

; Name servers
@           IN  NS  ns1.foo.internal.

; Master record
@           IN  ALIAS   master.servers.foo.internal.

; A records
master      IN  A   10.0.0.1
app-1       IN  A   10.0.1.1
app-2       IN  A   10.0.1.2

3. In zones/db.projects.foo.internal

$ORIGIN projects.foo.internal.
$TTL    3600
@   IN  SOA ns1.foo.internal. admin.foo.internal. 1 86400 3600 2592000 3600

; Name servers
@           IN  NS  ns1.foo.internal.

; Master record
@           IN  ALIAS   master.servers.foo.internal.

; A records
project-1   IN  ALIAS   app-1.servers.foo.internal.
project-1   IN  ALIAS   app-2.servers.foo.internal.
project-2   IN  ALIAS   app-1.servers.foo.internal.
project-3   IN  ALIAS   app-2.servers.foo.internal.

4. Run dig +short @127.0.0.1 projects.foo.internal

Expected behaviour

This should return 10.0.0.1 without ever asking 8.8.8.8 about anything (since the ALIAS target is local to the DNS server).

Actual behaviour

Dig returns nothing (record not found) and pdns logs show:

Error resolving for projects.foo.internal ALIAS master.servers.foo.internal over UDP, A-record query returned Non-Existent domain, returning SERVFAIL

Other information

Workaround

Currently you can workaround this issue by pointing resolver to itself:

resolver=127.0.0.1

But I am not sure if this might not cause issues in case of misconfiguration (eg. infinite loops or something similar)

[mnordhoff]

It may be useful, but it's a distinctly different feature with different security properties.

For example:

• If I'm a customer of a DNS hosting service, and have my-domain.example ALIAS me.popular-cdn.example, I do not want another customer to be able to add popular-cdn.example to their account and hijack my site. (I don't even want Popular CDN to add it to their account and accidentally break my site until they finish setting it up.)

• On the one hand, there would be no DNSSEC validation. On the other hand, DNS records may be received in a trusted way.

[hubertnnn]

What you suggest is the question if we can trust our own DNS records. Depending on who and how can enter them we might or might not trust them. Maybe add a setting for cross zone self trust.