RFD 172 CNS Aggregation Discussion

[bahamat]

Open questions from RFD 172.

1. Should these zone be owned by admin?
2. Should these zones be deployed via sdcadm?
3. Should these zones have access to Triton's admin network? (Nothing about them needs access to the admin network.)
   1. Should they be configured with config-agent? (Currently config-agent requires access to SAPI, which would require

[ad-m]

Why not ALIAS record?

[bahamat]

@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.

[ad-m]

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

[bahamat]

@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.

[siepkes]

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.

[bahamat]

@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.

[ad-m]

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.

[siepkes]

@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?

[bahamat]

@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.

[Smithx10]

@siepkes Temporarily, I have this little hack inplace.

https://github.com/Smithx10/ZoneAggregator