Hi Michael,
DNAME support was added in 3.4.0, but was disabled by default
(experimental-dname-processing=no). For 4.0.0 we have dropped the
experimental prefix but it is still disabled by default for performance
reasons - enabling it does cause a few more queries to your backend.
Hope that helps!
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
On 26 Jan 2016, at 21:19, michael.mo...@expedient.net wrote:
I know this has been requested in the past, however I wanted to lobby
for its potent inclusion for the upcoming 4.0 release of PDNS in a
fresh thread.
In previous posts I've seen people give examples of scripts that can
automate the creation of CNAME records for the back-end to compensate
for the lack of a DNAME RR, however I think approach contributes to a
lot of unnecessary bloat on the back-end, and fails to address the
manageability aspect.
My company's line of business is managed services and co-location, we
have 10 datacenters in 8 different cities. We initially started off as
an ISP, and WAN/MAN connectivity is still a core competency. That
being said we have several public domains from acquisitions that are
essentially aliases to our parent domain. As part of a clean up
effort, it would be preferable to consolidate hosts to the primary
public domain, and create DNAME's for all of the others to alias. This
would allow resolution for a host regardless of which domain suffix is
queried and without several thousand duplicate host records on the
back-end to synchronize or otherwise maintain.
In addition to public forward domains, we have a considerable amount
of IP space that we are authoritative over. For RFC 2317 delegation's,
it would be preferable to leverage the DNAME RR for allocations >=
/24; which represents a respectable population of our reverse zone
delegations.
RFC 6672 states:
The DNAME record provides redirection for a subtree of the domain
name tree in the DNS. That is, all names that end with a particular
suffix are redirected to another part of the DNS. This document
obsoletes the original specification in RFC 2672 as well as updates
the document on representing IPv6 addresses in DNS (RFC 3363).
https://tools.ietf.org/html/rfc6672
If .com and .org are domains, then example.com and example.org would
be subtree's of those domains respectively. I'm the furthest thing
from an application programmer, and I would hate to assume, but would
it be very difficult to add DNAME support in the upcoming PDNS
release?
I'm looking to do a complete overhaul of our DNS topology not long
after 4.0 is release for production use and DNAME's would definitely
solve a number of problems.
Great product, and thanks for all of the hard work!
_______________________________________________
Pdns-dev mailing list
pdns-dev@mailman.powerdns.com
https://mailman.powerdns.com/listinfo/pdns-dev@mailman.powerdns.com
_______________________________________________
Pdns-dev mailing list
pdns-dev@mailman.powerdns.com
https://mailman.powerdns.com/listinfo/pdns-dev@mailman.powerdns.com
