RFD 172 CNS Aggregation Discussion about rfd HOT 10 OPEN

@siepkes The intention of this RFD is to promote that front end server to a first-class image in Triton. It would be deployed along side the cns zone, and be the bind replica as well as region aggregation that would be deployed by sdcadm.

from rfd.

@siepkes Temporarily, I have this little hack inplace.

https://github.com/Smithx10/ZoneAggregator

from rfd.

Why not ALIAS record?

from rfd.

@ad-m That’s a good question. ALIAS records, not being actually part of the DNS specification may not be supported by tenant name servers, and even for those that do, the behavior is implementation specific. We want to be able to provide region-wide names for all services directly.

from rfd.

Why not implement that service on top of ALIAS record? For implementation you can choose ALIAS record compatible server.

from rfd.

@ad-m ALIAS records aren't a valid RRTYPE and is never present in DNS packets. It's merely an implementation detail of how some providers perform follow up look-ups. Rather than try to make our needs match someone else's solution, we're creating our own solution that matches our needs.

Even if this service used ALIAS records internally, that would never be exposed to end users or be observed in network traffic so it's irrelevant.

from rfd.

Just thinking out loud here; Don't most deployments always have some other DNS in front of Triton CNS (Bind, PowerDNS, NSD, etc.)? Wouldn't it be easier if one could tell the Triton CNS daemon to tell the upstream DNS via DDNS of which availability zone it is part? For example us-west.cns.example.com in case the Triton DNS daemon is us-west-1.cns.example.com?

That would alleviate the need of an extra moving cog in the form of an extra Bind install.

I think this should be possible with DDNS but I could be off.

from rfd.

It's merely an implementation detail of how some providers perform follow up look-ups. Rather than try to make our needs match someone else's solution, we're creating our own solution that matches our needs.

ALIAS (DNAME) is a concept that is implemented in various DNS servers. I am aware that this is not part of the protocol, but often part of the server configuration. Regardless, it is not difficult to implement it as a module for an existing server.

This solution - in some cases - can be used as an alternative to full zone transfer (push method of data transfer). I do not have full knowledge of the needs of Joyent, so I only put for consideration.

from rfd.

@bahamat Is it the intention that in (some distant) future it would also be possible to add some custom entries to this DNS? Perhaps via an API? For example for the "beautiful" names of services and such. Maybe something a bit like Comcasts Vinyldns? That way one could totally live without any other DNS install. Or will that be (for the foreseeable future) out of scope?

from rfd.

@siepkes We don't have any plan for a DNS hosting service, if that's what you're asking. There are already plenty of DNS hosting services and building our own wouldn't be a good use of our engineering time. We also don't have any plan to add direct support for updating external DNS infrastructure, since that can be handled fairly easily with nsupdate or API calls made from instances at boot/shutdown time.

We've considered adding "vanity" names that would appear in the PTR records that CNS produces, but there are a number of implementation questions left unanswered (and even a few left unasked). And so far there haven't been issues raised from customers (either on-prem or cloud customers) with CNS names being in PTR records, so we've not pursued working on this.

from rfd.