Non ONA managed CNAMES (external DNS references)

[rdorman]

I need to be able to create a CNAME from one of my domains to an Internet domain (in this case an AWS EC2 Elastic IP). I cannot do that because it has to be an "existing A record" that is within the ONA database. Adding amazonaws.com or something of that nature just wont scale.

[mattpascoe]

I understand the desire to have this ability. I'd like to dialog a bit about specific requirements here just to understand some scope (not that I don't get the basic desire to add CNAMES to external things).

Is the desire to add a CNAME to an AWS resource because the IP changes? I.E. wouldnt adding A records work as well here?

The reality is that this will take a fair amount of work to update the current behavior.

[rdorman]

The use case at the moment is AWS but it applies to a lot of other cloud services that we use (Heroku, SFDC etc). For one, yes the IP can change. One of my favorite parts of an AWS elastic IP is that even though the IP is in the name, the name wont change but the IP potentially could. Yes, an A record could be used for this but when diagnosing and documenting the network there is value from a systems administration perspective from when doing a lookup seeing exactly where it goes.. with an IP it can be confusing for a junior admin to understand where something actually is.

[justinkarabegovic]

This may also be a good feature for MX records to servers that are outside of our control. i.e. Email hosted on Google Apps.
Perhaps an idea is to continue to have the check for an internal host, but provide an 'override' or 'force' flag.

[DotSlashNatalie]

I would like this feature because I am currently trying to import BIND config file and some of the records point to non-ONA managed sources.

I took at look at the database schema and I agree with @mattpascoe . I think solving this would mean decoupling DNS from ONA (basically having a table just for DNS records that ONA just happens to update).

[fxpottier]

Do you mean a new table, beside the existing view, for DNS entries such as
non-ONA managed zones ?

2014-05-01 23:33 GMT+02:00 nadams810 notifications@github.com:

I would like this feature because I am currently trying to import BIND
config file and some of the records point to non-ONA managed sources.

I took at look at the database schema and I agree with @mattpascoehttps://github.com/mattpascoe. I think solving this would mean decoupling DNS from ONA (basically having
a table just for DNS records that ONA just happens to update).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/70#issuecomment-41959598
.

François-Xavier POTTIER
06 62 77 07 78

[DotSlashNatalie]

Well right now in order for you to put an A record in - it has to be associated with a host in ONA. There is no way around this in the current design. So, let me point out an example:

Let's say I manage github.com, but my active directory domain is github.local. github.com is the external DNS and should, in theory, have fewer records than github.local. I do want ONA to manage DNS for both github.local and github.com. One can easily import all the records for github.local assuming that all the correct subnets are added. However, adding (all) github.com records is really impossible right now. So lets say I have an A record of a.github.com that points to 176.24.23.3 - this is a problem because I don't manage the 176.24.23.0 subnet (let's assume it's a third party like godaddy). My only recourse is to add 176.24.23.0 as a subnet simply because ONA wants to create an A record that points to host on a subnet vs having a schema like:

id
node
ttl
data
host_id

Another example is actually OP's problem:

Let's say I want to add a CNAME of g.github.com => hosted.googleapps.com
Not only do I have to add a domain for googleapps.com, but I also have to add a host for hosted.googleapps.com because ONA wants to make sure the CNAME is pointing to something. I completely understand why - but this should overridable by an admin. Or at the very least put up a message saying "hey - are you sure you really want to do this? if yes - enter a justification so other admins know why this exists". Like what @node-jkarabeg suggests.

After looking at the schema for the dns table - it definitely will need a overhaul to accommodate this feature.

However - I think I should pause there before I keep going and propose a question - ONA is an IPAM solution - does it want to be in the business of actually being a web management frontend for DNS? After digging around in ONA a little bit I completely agree with @mattpascoe that modifying ONA to support what a couple of us want would be a huge undertaking to do it right.

Perhaps what might be better is an ONA plugin rather than modifying the core of ONA? Ideally what I would want is to be able to, optionally, associate github.com records to an ONA host but not being able to edit them unless you have the right permissions in the plugin. Going into the plugin page would show me all of github.com and ability to modify every DNS record freely without restriction.

I think it would be awesome to have the ability to delegate zones such that admin1 manages zone1.github.com and admin2 manages *.github.com rather than just having a blanket permission of editing DNS. Adding on to that you could do some tricks like generating separate bind zone files (let's say I want a zone file for github.com and a seperate file for zone1.github.com). I've had success with doing this in the past and using the MPTT algorithm.

[fxpottier]

Hi,

The fact that ONA prevents us from adding a CNAME pointing to another CNAME
without the corresponding A record in the database is totally
understandable in that it keeps your DNS coherent.

But i think it should be allowed if and only if the A record can be
resolved by ONA.

This verification would be a minor change in the interface that would help
a lot.

How do you use ona for your bind ? Do you generate a zone file or do you
use DLZ ?

2014-05-04 19:07 GMT+02:00 nadams810 notifications@github.com:

Well right now in order for you to put an A record in - it has to be
associated with a host in ONA. There is no way around this in the current
design. So, let me point out an example:

Let's say I manage github.com, but my active directory domain is
github.local. github.com is the external DNS and should, in theory, have
fewer records than github.local. I do want ONA to manage DNS for both
github.local and github.com. One can easily import all the records for
github.local assuming that all the correct subnets are added. However,
adding (all) github.com records is really impossible right now. So lets
say I have an A record of a.github.com that points to 176.24.23.3 - this
is a problem because I don't manage the 176.24.23.0 subnet (let's assume
it's a third party like godaddy). My only recourse is to add 176.24.23.0 as
a subnet simply because ONA wants to create an A record that points to host
on a subnet vs having a schema like:

id
node
ttl
data
host_id

Another example is actually OP's problem:

Let's say I want to add a CNAME of g.github.com => hosted.googleapps.com
Not only do I have to add a domain for googleapps.com, but I also have to
add a host for hosted.googleapps.com because ONA wants to make sure the
CNAME is pointing to something. I completely understand why - but this
should overridable by an admin. Or at the very least put up a message
saying "hey - are you sure you really want to do this? if yes - enter a
justification so other admins know why this exists". Like what
@node-jkarabeg https://github.com/node-jkarabeg suggests.

After looking at the schema for the dns table - it definitely will need a
overhaul to accommodate this feature.

However - I think I should pause there before I keep going and propose a
question - ONA is an IPAM solution - does it want to be in the business of
actually being a web management frontend for DNS? After digging around in
ONA a little bit I completely agree with @mattpascoehttps://github.com/mattpascoethat modifying ONA to support what a couple of us want would be a huge
undertaking to do it right.

Perhaps what might be better is an ONA plugin rather than modifying the
core of ONA? Ideally what I would want is to be able to, optionally,
associate github.com records to an ONA host but not being able to edit
them unless you have the right permissions in the plugin. Going into the
plugin page would show me all of github.com and ability to modify every
DNS record freely without restriction.

I think it would be awesome to have the ability to delegate zones such
that admin1 manages zone1.github.com and admin2 manages *.github.comrather than just having a blanket permission of editing DNS. Adding on to
that you could do some tricks like generating separate bind zone files
(let's say I want a zone file for github.com and a seperate file for
zone1.github.com). I've had success with doing this in the past and using
the MPTT algorithm.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/70#issuecomment-42138162
.

François-Xavier POTTIER
06 62 77 07 78

[DotSlashNatalie]

I would like for ONA to generate both forward and reverse zone files but I can't use it for forwards because ONA won't accept it - well technically it can but I would have to add a domain and/or subnets that I don't control/own. I can use it for our reverse zones though.

[mattpascoe]

I've finally had a few seconds to read and comment on the posts here. This is certainly a long standing issue that many have brought up before. It is also one I can sympathize with from many sides.

As has been pointed out here, to do this the 'right' way will require quite a bit of work to the core of ONA. The reality is that this will likely not be done any time soon.

I can offer the following statements from my position on this.

• as @nadams810 eluded to, ONA was intended to manage your own space and not third party space. This is for many a requirement however, especially when it comes to cloud activities. A primary goal was to keep data integrity, thus the rigid table design.
• one way this could be dealt with is to actually add domains and subnets that are 'owned' by someone else into ONA so it can attach as it requires. This works perfectly well and is a legit way of solving this issue. In this case you would not build forward domains for say github.com as those should resolve via root resolvers. You would only need entries required to add CNAMEs and A records etc. The drawbacks here are obviously that you have to duplicate someone elses managed information in your own copy. Not ideal but is a form of what is done now in a zone file, we just store it in a table.
• The notion of creating another table to store these bits of data and allowing for less restriction is something I'm not keen on doing. I think it adds a set of complexities that do not fully solve for all situations.
• having an option like @fxpottier suggests that would relax the rules a bit and do a lookup or some other validation, but still store the data in the current tables would be more appealing. This however does need some adjustment to tables where a table ID is expected. I think this one is in the realm of possibility, but certainly needs more thought put into it on a design.
• Lastly, I think my preferred method at the moment is this. In the past I have for both the bind and tinydns (text based methods) have toyed with the ability to do include files. This was tied to the build process such that zone data was extracted from ONA and then a seperate static file, outside of ONA was maintained and included in the resulting build output. This allowed the various records that could not be put into ONA, or were not supported by ONA (like NAPTR) to be part of the overall outcome. Another form of this was to add a simple open text blob to the domains table. Each domain/zone would have a text blob editable in the GUI that would simply be included in the zone file that was generated. This would allow an admin to just type in whatever native format (bind/tinydns etc) the specific records they wanted. This would let users see the configuration via ONA but not have to enter it directly.. thats much better than a file in the filesystem that is not visible in the GUI. Another benefit of this method is that it might be possible then to manage several of the other zone options in this open text field. Bind has a ton of options, many of which would be very difficult to manage from ONA with out a lot of work in GUI and tables. This simple open text field allows for several possibilities. Another issue this would have is that the DLZ may not be able to use it? not sure on that since I dont use the DLZ code myself.

Anyway, I hope that helps here. What do you think? Again, my vote is the last option that uses the open text field.

[DotSlashNatalie]

I do agree with that - and I think that using a text blob is an acceptable middle ground. The problem is that really we are talking about features that ONA should not do. Projects that try to do everything and the kitchen sink - usually suffer.

If this text blob was searchable - then maybe. Also what might help is to see a report of all of these records on a single page with their corresponding host record. My use case is for people that are not Linux admins but still want to be able to manage DNS. And it makes sense that a system like ONA does that - as it keeps things sane and managed.

For me storing records in a static file will not do. While the records probably won't change that often - it's still has the possibility for typos.

I think if the text blob is put in - it should come with some regular expressions that the system can test against the blob to ensure that it's at least in the right format. It might not make sense - but at least if it's in the right format BIND or whatever system you have won't crash.

[mattpascoe]

I agree that the do everything projects suffer. I certainly dont want to compromise. I generally want to leave the extraneous things to plugins. That way if you want it you could add it but it would not directly impact the core system. In this case a plugin may not work well just because it does not integrate to the core.

The text blob would not allow for true integration in searches or other typical views of data. That is one of its drawbacks. It should however be visible to the domain view in ONA that shows the resultant zone file that would be created from the data. Its a 'report' of sorts. Bind zone files are generally readable by even the non linux admin but is certainly not for everyone.

Sane and managed is certainly a primary goal of ONA. So is managing DNS. But I have always known that ONA would never control the 100s of BIND options. I'm shooting for the %80/20 at least.

The issue of typos is certainly a concern. To me even with the data entegrity that ONA provides I always expect it could break in some way. This is why the build_bind and build_tinydns processes always do a syntax check on the output prior to restarting the service. In the event it fails an email alert is sent and it keeps running with the last copy.

It might be possible to let the text blob be syntax checked when it is saved, in a similar way. More to explore there if its appealing. I'm the first to suggest a departure from hand editing zone files and or spreadsheets but I'm also lazy and strapped for time quite often. This seemed the best compromise. :)

Thanks for all the feedback. Its always good to have more than just my brain thinking about this, cuz I'm sure I'll miss something.