search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.67k stars 906 forks source link

ALIAS polish #3838

Open Habbie opened 8 years ago

Habbie commented 8 years ago
goestreicher commented 8 years ago

So while testing the LDAP backend with added support for ALIAS it turned out that not setting "recursor" in the configuration file or on the command line causes the test to fail without more information. Core just assumes that the ALIAS record doesn't exists.

cmouse commented 7 years ago

Maybe add:

now it only says

[2017-04-25 18:36:35] Apr 25 18:36:35 Error resolving for ALIAS google-public-dns-a.google.com., aborting AXFR
chasebolt commented 7 years ago

I am running into the ALIAS tcp issue Jul 13 19:55:01 dnsproxy.cc: Error sending reply with sendmsg (socket=21): Bad file descriptor.

PowerDNS Authoritative Server 4.0.3

is there a way to resolve this or is the current strategy to not use ALIAS yet?

mfowlewebs commented 7 years ago

actually support TCP queries (currently they lead to Feb 02 12:07:12 dnsproxy.cc: Error sending reply with sendmsg (socket=19): Bad file descriptor)

This doesn't seem like it's documented or mentioned anywhere.

is there a way to resolve this or is the current strategy to not use ALIAS yet?

Yeah, this. What the hell? We had no idea our customers DNS resolving just wasn't working for them. It's hard to justify ALIAS as usable in these conditions.

Should we open a new ticket to track this specific issue? This doesn't seem like polish- this seems like base functionality, which ATM seems very broken.

Habbie commented 7 years ago

When we implement ANAME (hopefully soon), we'll do it in a different way that will suffer from none of these issues. I agree this is more than polish, but there are no plans to fix it for ALIAS. The best workaround is to AXFR very periodically as we do resolve correctly during AXFR.

joachimtingvold commented 7 years ago

Just to have the history; there was a draft for ALIAS earlier this year (https://tools.ietf.org/html/draft-dnsop-eden-alias-rr-type-00) which didn't seem to get enough momentum. Shortly after a draft for ANAME followed (https://tools.ietf.org/html/draft-ietf-dnsop-aname-00), which seems to have gained more attention, and hopefully get's ratified as a standard.

Habbie commented 7 years ago

@jallakim yes, indeed - it did not get momentum because we asked the ALIAS author (Anthony) to join forces with us on ANAME instead, and he agreed. Thank you for documenting the context here :)

joachimtingvold commented 7 years ago

Hah. How many beers did it take to make him join forces? #bribe

Habbie commented 7 years ago

Hah. How many beers did it take to make him join forces? #bribe

I don't know, Evan and Anthony were at the same conference at the time, I wasn't there ;)

felixsand commented 6 years ago

So this is what triggered all those errors in our logs as soon as we activated ALIAS (not supporting TCP)... Still not possible to get this prioritized?

egon1024 commented 6 years ago

We definitely have interest in seeing support for ANAME records. I'd be happy to help out with testing, if that will be of use.

digitalocean-engineering commented 6 years ago

This is definitely of interest - we'd like to be able to use this feature but cannot currently commit to architecting our DNS infrastructure to rely simply on AXFRs for propagating zone data. A fix for the ALIAS record issue or support for ANAME records would be useful.

Kraeutergarten commented 6 years ago

Any update?

Habbie commented 6 years ago

Update: we did fix TCP for ALIAS. ANAME work is pending.

felixsand commented 6 years ago

@Habbie great news! Is this available in a stable release already or in what release will it be available?

Habbie commented 6 years ago

6337 is the backport to 4.1.x which will be released as part of auth 4.1.2 at some point.

If you go to https://downloads.powerdns.com/autobuilt_browser/#/auth/ and find '4.1.1-8' (at some point builds higher than 8 might appear), this fix should be in it.

Omeryl commented 5 years ago

Hey!

I just got done speaking to @Habbie on the IRC channel (thanks for your time!)

I was wondering if it would be potentially possible for PowerDNS to internally resolve/flatten ALIAS records when it's a zone it is authoritative over.

I.e. the following:

c1.test.dev.        60  IN  TYPE65401 \# 16 05706161733104746573740364657600 ; ALIAS to paas1.test.dev
paas1.test.dev.     60  IN  A   1.1.1.1
paas2.test.dev.     60  IN  A   2.2.2.2

It'd be beneficial when testing with a zone that doesn't exist (as above). I can see a few problems related to efficiency if it had to go out -> hit Cloudflare -> hits us again.

Thanks!

joachimtingvold commented 4 years ago

@Habbie, how's the progress for implementing ANAME?

Habbie commented 4 years ago

The ANAME draft has expired in favour of other IETF dnsop proposals (such as SVCB/HTTPSSVC), and because of that we currently have no plan to work on ANAME in PowerDNS. Instead, I suspect we will polish ALIAS a bit more this year.

Depending on your needs, the existing ALIAS code, or the existing LUA functionality, can likely solve your problems. If you'd like some help, please find us on IRC or mailing list via https://www.powerdns.com/opensource.html

Habbie commented 4 years ago

The ANAME draft has expired in favour of other IETF dnsop proposals (such as SVCB/HTTPSSVC), and because of that we currently have no plan to work on ANAME in PowerDNS. Instead, I suspect we will polish ALIAS a bit more this year.

Depending on your needs, the existing ALIAS code, or the existing LUA functionality, can likely solve your problems. If you'd like some help, please find us on IRC or mailing list via https://www.powerdns.com/opensource.html

I was wondering if it would be potentially possible for PowerDNS to internally resolve/flatten ALIAS records when it's a zone it is authoritative over.

You can accomplish that today by pointing resolver= at a Recursor (or unbound or BIND or ..) on localhost that knows that test.dev lives in your auth that is also reachable without going out on a cable.

edo1 commented 4 years ago

somebody reported on IRC that wildcard ALIAS does not work at all on direct query, appears to be true. 9/oct/2019 fresh report came in for this not working on 4.2.0.

It doesn't work for me as well. PowerDNS version 4.1.6-3 from Debian Buster.

wildcard + A works wildcard + CNAME works explicit + ALIAS works wildcard + ALIAS doesn't work.

zeha commented 3 years ago

Currently ALIAS uses DP->completePacket to handle all the resolving and also relying to the client. This kinda prevents reusing all the existing codepaths for signing etc. I guess the current design was chosen to reap some optimization benefits, but I don’t know what these are.

@Habbie could you please enlighten me on this?

Habbie commented 3 years ago

That choice was made so that the thread holding a DB connection can exit. It was also less typing. I want to change this so it works like LUA (for which the code is already there, too!) so everything just works, just haven't gotten around to it.

aj-gh commented 2 years ago

Noting it here (as discussed): For a FQDN having an ALIAS record only the ALIAS “resolved target” is returned on an ANY query even though other types exist as well. e.g.

foo.bar. IN ALIAS google.com.
foo.bar. IN TXT “test”

would only return the google.com resolved A/AAAA records on an "ANY" query, ignoring the (locally) also-present TXT record

thibmac commented 2 years ago

Hello,

Were there any updates on the DNSSEC / ALIAS topic since it was last discussed in here?

It was also debated here (edit: not ALIAS in particular, but apex cnames)

Thanks!

pschichtel commented 1 year ago

@Habbie I just hit the ALIAS limitation with wildcards. If I understand you correctly, LUA records would already behave correctly. Can I call a resolver from a LUA record?

Habbie commented 1 year ago

https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authoritative)#using-lua-to-simulate-cname-like-behaviour-on-the-zone-apex

klaus-nicat commented 11 months ago

https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authoritative)#using-lua-to-simulate-cname-like-behaviour-on-the-zone-apex

The LUA-ALIAS example was not restored after the vandalism. On purpose (not working anymore), or just forgotten? Then I would restore it (see https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authoritative)/_history)

Habbie commented 11 months ago

It's in https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authoritative-LUA-records) now

klaus-nicat commented 11 months ago

Is there any drawback using LUA (ie blocking of receiver-threads ...)?

Habbie commented 11 months ago

Is there any drawback using LUA (ie blocking of receiver-threads ...)?

yes, it blocks a thread (a distributor thread, I believe)