at the moment, the dns smart proxy functionality is fairly limited - add /
remove A/PTR records.
in order to solve #551: Add DNS Aliases support and #782: DNS API should
include the zone, I started to review the implementation.
due to the way nsupdate is working it was very easy to hack something
functional (as we have today), but unlike the dhcp proxy, we lack
the identification of a zone, record etc.
does anyone else besides me thinks this need to be fixed? this in theory
should allow us to support for zone transfers, and to be able to construct
the whole (or most) of a dns zone in ruby objects.
as far as it goes to rest, it should be fairly simple to change the api to
something like that:
GET /dns/<zone> --> gets all records for a zone, either for a PTR or a plain
zone.
GET /dns/<zone>/A --> gets all dns A records for a zone
POST /dns/<zone>/A --> creates a new A record
GET /dns/<zone>/CNAME --> gets all dns aliases for a zone
POST /dns/<zone>/CNAME --> gets all dns aliases for a zone
…
…
Does anyone is interested in such API, or rather the exists
dns management solutions are sufficient?
> Hi,
> at the moment, the dns smart proxy functionality is fairly limited - add /
> remove A/PTR records.
> in order to solve #551: Add DNS Aliases support and #782: DNS API should
> include the zone, I started to review the implementation.
> due to the way nsupdate is working it was very easy to hack something
> functional (as we have today), but unlike the dhcp proxy, we lack
> the identification of a zone, record etc.
> does anyone else besides me thinks this need to be fixed? this in theory
> should allow us to support for zone transfers, and to be able to construct
> the whole (or most) of a dns zone in ruby objects.
> as far as it goes to rest, it should be fairly simple to change the api to
> something like that:
> GET /dns/<zone> --> gets all records for a zone, either for a PTR or a plain
> zone.
> GET /dns/<zone>/A --> gets all dns A records for a zone
> POST /dns/<zone>/A --> creates a new A record
> GET /dns/<zone>/CNAME --> gets all dns aliases for a zone
> POST /dns/<zone>/CNAME --> gets all dns aliases for a zone
> …
> …
>
> Does anyone is interested in such API, or rather the exists
> dns management solutions are sufficient?
> Ohad
I've been thinking about the DNS smart proxy, and think that it should
be expanded to support backend third party DNS service providers and
their APIs. The 4 providers I think that would be useful to support
initially would be: DNSmadeeasy.com, DynDNS, UltraDNS, and Route53
(Amazon).
Have you given any thought in this direction?
Regarding your initial question, I absolutely think it would be very
helpful to develop a full DNS API, and should be higher priority than
providing third party DNS support, (for us, we'd be very happy if
smart proxy could manage two independent and redundant Bind servers
that would be configured to distribute to a third party service
provider tier of anycast global DNS servers). One reason you may want
to look at the third party providers, is that by comparing their APIs,
we can get a common set of high priority methods to add to the
smartproxy API. I would be willing to help with that research piece if
you were interested. I am also willing to help with fleshing out the
specs on the DNS SmartProxy, but I personally don't have the coding
skills to effectively help. (Unless you think Awk scripts would be of
much use).
How we handle DNS is going to become more and more important as we
integrate Foreman with EC2, as I'd prefer to develop some pattern for
the community to use while we are doing it. Using smartproxy is
definately a win here. Mmmm. I'm wondering if supporting Amazon's
Route53 early, is something we should be targetting?
One tangentially related thought: as we look to the future and put
more and more functionality into Foreman, I'm starting to think about,
HA, DR and Global distribution of puppetmasters, Foreman nodes and
whatnot. (I would like to know what the current state is, and what the
future plans are. You can probably reply in a separate thread.)
Cheers,
Brian
···
On Sun, May 8, 2011 at 8:10 AM, Ohad Levy wrote:
first of all, this was meant for foreman-dev user list… sorry about
that.
> I've been thinking about the DNS smart proxy, and think that it should
> be expanded to support backend third party DNS service providers and
> their APIs. The 4 providers I think that would be useful to support
> initially would be: DNSmadeeasy.com, DynDNS, UltraDNS, and Route53
> (Amazon).
>
> Have you given any thought in this direction?
I always saw the proxy as way to bridge between different backend
implementations, therefor this is exactly the usage cases for it.
> Regarding your initial question, I absolutely think it would be very
> helpful to develop a full DNS API, and should be higher priority than
> providing third party DNS support,
Ok… any chance you can come up with a high level proposal for the API
structure?
> (for us, we'd be very happy if
> smart proxy could manage two independent and redundant Bind servers
I think its already possible for simple A/PTR records.
> that would be configured to distribute to a third party service
> provider tier of anycast global DNS servers). One reason you may want
> to look at the third party providers, is that by comparing their APIs,
> we can get a common set of high priority methods to add to the
> smartproxy API. I would be willing to help with that research piece if
> you were interested. I am also willing to help with fleshing out the
> specs on the DNS SmartProxy, but I personally don't have the coding
> skills to effectively help. (Unless you think Awk scripts would be of
> much use).
Sounds good
>
> How we handle DNS is going to become more and more important as we
> integrate Foreman with EC2, as I'd prefer to develop some pattern for
> the community to use while we are doing it. Using smartproxy is
> definately a win here. Mmmm. I'm wondering if supporting Amazon's
> Route53 early, is something we should be targetting?
my take on it is, if people find it useful, then yes
Ohad
···
On Sun, 2011-05-08 at 12:53 -0400, Brian Gupta wrote:
In order to achieve 100% high availability, you would need to break the
components into:
Foreman web services (UI/API)
Database
Proxy services (if you are using foreman with provisioning).
The first two, are identical to every rails app you deploy on the web,
the last one greatly depends on how your proxy are used, and really what
is the service which runs behind them.
I would imagine, that if the service that the proxy is managing is
highly available too, then we could use a proxy per instance (or at
least two) with some dns round robin or something to find a working
proxy.
note, that if foreman goes down you lose:
reporting
node classifications (but not really an issue, as we should implement
a simple local cache
the ability to make changes
the ability to provision new hosts.
So in one way, its like puppet going down, as you basically lose the
ability to make changes, but at the same time, all running instances
should not be effected.
Note that foreman supports multiple puppetmasters from its first
release.
Ohad
···
On Sun, 2011-05-08 at 12:53 -0400, Brian Gupta wrote:
One tangentially related thought: as we look to the future and put
more and more functionality into Foreman, I’m starting to think about,
HA, DR and Global distribution of puppetmasters, Foreman nodes and
whatnot. (I would like to know what the current state is, and what the
future plans are. You can probably reply in a separate thread.)
> first of all, this was meant for foreman-dev user list… sorry about
> that.
>
>> I've been thinking about the DNS smart proxy, and think that it should
>> be expanded to support backend third party DNS service providers and
>> their APIs. The 4 providers I think that would be useful to support
>> initially would be: DNSmadeeasy.com, DynDNS, UltraDNS, and Route53
>> (Amazon).
>>
>> Have you given any thought in this direction?
> I always saw the proxy as way to bridge between different backend
> implementations, therefor this is exactly the usage cases for it.
Great.
>> Regarding your initial question, I absolutely think it would be very
>> helpful to develop a full DNS API, and should be higher priority than
>> providing third party DNS support,
> Ok… any chance you can come up with a high level proposal for the API
> structure?
Starting on it below… Please let me know what more info do you
need? IE: I'm not 100% sure what a high level API proposal requires.
>> (for us, we'd be very happy if
>> smart proxy could manage two independent and redundant Bind servers
> I think its already possible for simple A/PTR records.
Yes, but for us in EC2, due to the fact that they use split horizon
DNS to handle the private/public IP addressing split, requires that we
use CNAMEs, to make everything work. So in a way for us, CNAMEs are
the most important record type to support.
>> that would be configured to distribute to a third party service
>> provider tier of anycast global DNS servers). One reason you may want
>> to look at the third party providers, is that by comparing their APIs,
>> we can get a common set of high priority methods to add to the
>> smartproxy API. I would be willing to help with that research piece if
>> you were interested. I am also willing to help with fleshing out the
>> specs on the DNS SmartProxy, but I personally don't have the coding
>> skills to effectively help. (Unless you think Awk scripts would be of
>> much use).
> Sounds good
Functionality Long term, we should try to support as many of the
following as is feasible:
That said I would prioritize allowing the full management of the
following common Record types (I took the superset of what we use,
what DNSMadeEasy supports, and what Route53/Amazon supports.):
A
PTR
CNAME
AAAA
TXT
SPF
SOA
MX
NS
SRV
Creating, Listing, and Deleting zones needs to be supported via the
API as well, (And hopefully the GUI eventually as well).
>> How we handle DNS is going to become more and more important as we
>> integrate Foreman with EC2, as I'd prefer to develop some pattern for
>> the community to use while we are doing it. Using smartproxy is
>> definately a win here. Mmmm. I'm wondering if supporting Amazon's
>> Route53 early, is something we should be targetting?
>
> my take on it is, if people find it useful, then yes
I think if nothing else it is useful to look at as a well thought-out
hosted DNS service with a clean API, that has a base set of
functionality we should target. I"m thinking we should match their API
feature wise, but initially make it work with Bind and then integrate
with Route53 down the road a bit. (Or not… whichever approach is
easier to code is probably the way to go).
Summary of their API: http://docs.amazonwebservices.com/Route53/latest/APIReference/ (I
highly recommend perusing this, as it's one of the better DNS APIs I
have seen to date, and it's not that long of a read. It's good enough,
that we MIGHT even want to replicate it. Well maybe not quite 100%, as
they do like their XML. In any case it's required reading if we
want to integrate.)
POST CreateHostedZone
GET GetHostedZone
DELETE DeleteHostedZone
GET ListHostedZones
POST ChangeResourceRecordSets - Use this action to create or change
your authoritative DNS information
GET ListResourceRecordSets - The action retrieves a specified number
of resource record sets in order, beginning at a position specified by
the Name and Type elements.
GET GetChange - Gets status of a change request (API is asynchronous).
-Brian
···
On Mon, May 9, 2011 at 1:45 AM, Ohad Levy wrote:
> On Sun, 2011-05-08 at 12:53 -0400, Brian Gupta wrote:
