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/opennetadmin/ona/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/opennetadmin/ona/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.

[mattpascoe]

Another thought I have currently on this topic.

I could add an 'override_data' column to the DNS table. Then you would add a record as usual but select the override option. This would bypass the typical checks that happen today and place either the IP or the points_to value into the override_data column. I think the major columns to deal with are interface_id and dns_id.. when overriding, these two columns would not be used and the override_data column would be.

I think this is a feasible option.. It was a quick thought I had and I wanted to capture it here. It needs much more thought put into it. I'm hoping it isn't a huge amount of effort. My fear is it will be......

[fxpottier]

Hi Matt, Overriding the checks is à good idea but i would not touch the data structure. Don't you think it would be easier to just check the existence of the A record . Could be easily done in php (gethostbyname() for instance) . I can work on that on my network. Just tell me which function(s) are to be impacted if you have that in mind.

Then ona would just need some place to store the forwarders options (seems to be quite requested)

I already one site in production on ona. I'll be migrating the 2nd soon. Works perfectly for me.

Bye

François-Xavier POTTIER Le 22 mai 2014 17:27, "mattpascoe" notifications@github.com a écrit :

Another thought I have currently on this topic.

I could add an 'override_data' column to the DNS table. Then you would add a record as usual but select the override option. This would bypass the typical checks that happen today and place either the IP or the points_to value into the override_data column. I think the major columns to deal with are interface_id and dns_id.. when overriding, these two columns would not be used and the override_data column would be.

I think this is a feasible option.. It was a quick thought I had and I wanted to capture it here. It needs much more thought put into it. I'm hoping it isn't a huge amount of effort. My fear is it will be......

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

[rdorman]

This could be a way to implement views at the same time. A tag that indicated a record type/view/disposition could then be used by the generation scripts. I.E

A Record for blah.domain.com pointing to 10.10.10.1 – Tag internalView, subnet managed by ONA A Record blah.domain.com pointing to x.x.x.x (routable IP) – tag externalView, subnet managd by ONA A record for cloud-blah.domain.com pointing to x.x.x.x (routable IP), tag noExport, subnet not managed by ONA

When the BIND generation was run you could indicate which tags on record should be included in the export.

Or is this nuts?

From: fxpottier [mailto:notifications@github.com] Sent: Thursday, May 22, 2014 2:11 PM To: opennetadmin/ona Cc: Ryan Dorman Subject: Re: [ona] Non ONA managed CNAMES (#70)

Hi Matt, Overriding the checks is à good idea but i would not touch the data structure. Don't you think it would be easier to just check the existence of the A record . Could be easily done in php (gethostbyname() for instance) . I can work on that on my network. Just tell me which function(s) are to be impacted if you have that in mind.

Then ona would just need some place to store the forwarders options (seems to be quite requested)

I already one site in production on ona. I'll be migrating the 2nd soon. Works perfectly for me.

Bye

François-Xavier POTTIER Le 22 mai 2014 17:27, "mattpascoe" notifications@github.com<mailto:notifications@github.com> a écrit :

Another thought I have currently on this topic.

I could add an 'override_data' column to the DNS table. Then you would add a record as usual but select the override option. This would bypass the typical checks that happen today and place either the IP or the points_to value into the override_data column. I think the major columns to deal with are interface_id and dns_id.. when overriding, these two columns would not be used and the override_data column would be.

I think this is a feasible option.. It was a quick thought I had and I wanted to capture it here. It needs much more thought put into it. I'm hoping it isn't a huge amount of effort. My fear is it will be......

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

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

---

This email and/or any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. This email and/or any files transmitted with this email may contain confidential and/or proprietary information. Accordingly, if you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please advise the sender by reply email and delete the message. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Borderfree Group companies. Finally, viruses and other harmful code can be transmitted by email. As such, the recipient should check this email and any attachments for the presence of viruses or malware. Borderfree Group companies disclaims any and all liability for any damage caused by any virus or malware transmitted by this email and/or any files transmitted with this email.

---

[fxpottier]

Yes, a boolean could help here. I even think my idea of checking the existence of the A record is not a good one. Since you insert a CNAME in your ONA zone pointing to a name with a suffix of another zone. We might just need to slightly modify the code : If CNAME suffix == .ona.zone and suffix of pointed to CNAME ==other.zone then just check the DB in case it already exists.

Do you think this would be acceptable from a BIND point of view ?

François-Xavier POTTIER Le 22 mai 2014 20:14, "Ryan Dorman" notifications@github.com a écrit :

This could be a way to implement views at the same time. A tag that indicated a record type/view/disposition could then be used by the generation scripts. I.E

A Record for blah.domain.com pointing to 10.10.10.1 – Tag internalView, subnet managed by ONA A Record blah.domain.com pointing to x.x.x.x (routable IP) – tag externalView, subnet managd by ONA A record for cloud-blah.domain.com pointing to x.x.x.x (routable IP), tag noExport, subnet not managed by ONA

When the BIND generation was run you could indicate which tags on record should be included in the export.

Or is this nuts?

From: fxpottier [mailto:notifications@github.com] Sent: Thursday, May 22, 2014 2:11 PM To: opennetadmin/ona Cc: Ryan Dorman Subject: Re: [ona] Non ONA managed CNAMES (#70)

Hi Matt, Overriding the checks is à good idea but i would not touch the data structure. Don't you think it would be easier to just check the existence of the A record . Could be easily done in php (gethostbyname() for instance) . I can work on that on my network. Just tell me which function(s) are to be impacted if you have that in mind.

Then ona would just need some place to store the forwarders options (seems to be quite requested)

I already one site in production on ona. I'll be migrating the 2nd soon. Works perfectly for me.

Bye

François-Xavier POTTIER Le 22 mai 2014 17:27, "mattpascoe" <notifications@github.com<mailto: notifications@github.com>> a écrit :

Another thought I have currently on this topic.

I could add an 'override_data' column to the DNS table. Then you would add a record as usual but select the override option. This would bypass the typical checks that happen today and place either the IP or the points_to value into the override_data column. I think the major columns to deal with are interface_id and dns_id.. when overriding, these two columns would not be used and the override_data column would be.

I think this is a feasible option.. It was a quick thought I had and I wanted to capture it here. It needs much more thought put into it. I'm hoping it isn't a huge amount of effort. My fear is it will be......

— Reply to this email directly or view it on GitHub< https://github.com/opennetadmin/ona/issues/70#issuecomment-43903521> .

— Reply to this email directly or view it on GitHub< https://github.com/opennetadmin/ona/issues/70#issuecomment-43923804>.

---

This email and/or any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. This email and/or any files transmitted with this email may contain confidential and/or proprietary information. Accordingly, if you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please advise the sender by reply email and delete the message. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Borderfree Group companies. Finally, viruses and other harmful code can be transmitted by email. As such, the recipient should check this email and any attachments for the presence of viruses or malware. Borderfree Group companies disclaims any and all liability for any damage caused by any virus or malware transmitted by this email and/or any files transmitted with this email.

---

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

[rdorman]

Right, I used A record as the example but I would see this as a general piece of metadata used to determine export.

From: fxpottier [mailto:notifications@github.com] Sent: Thursday, May 22, 2014 4:22 PM To: opennetadmin/ona Cc: Ryan Dorman Subject: Re: [ona] Non ONA managed CNAMES (#70)

Yes, a boolean could help here. I even think my idea of checking the existence of the A record is not a good one. Since you insert a CNAME in your ONA zone pointing to a name with a suffix of another zone. We might just need to slightly modify the code : If CNAME suffix == .ona.zone and suffix of pointed to CNAME ==other.zone then just check the DB in case it already exists.

Do you think this would be acceptable from a BIND point of view ?

François-Xavier POTTIER Le 22 mai 2014 20:14, "Ryan Dorman" notifications@github.com<mailto:notifications@github.com> a écrit :

This could be a way to implement views at the same time. A tag that indicated a record type/view/disposition could then be used by the generation scripts. I.E

A Record for blah.domain.com pointing to 10.10.10.1 – Tag internalView, subnet managed by ONA A Record blah.domain.com pointing to x.x.x.x (routable IP) – tag externalView, subnet managd by ONA A record for cloud-blah.domain.com pointing to x.x.x.x (routable IP), tag noExport, subnet not managed by ONA

When the BIND generation was run you could indicate which tags on record should be included in the export.

Or is this nuts?

From: fxpottier [mailto:notifications@github.com] Sent: Thursday, May 22, 2014 2:11 PM To: opennetadmin/ona Cc: Ryan Dorman Subject: Re: [ona] Non ONA managed CNAMES (#70)

Hi Matt, Overriding the checks is à good idea but i would not touch the data structure. Don't you think it would be easier to just check the existence of the A record . Could be easily done in php (gethostbyname() for instance) . I can work on that on my network. Just tell me which function(s) are to be impacted if you have that in mind.

Then ona would just need some place to store the forwarders options (seems to be quite requested)

I already one site in production on ona. I'll be migrating the 2nd soon. Works perfectly for me.

Bye

François-Xavier POTTIER Le 22 mai 2014 17:27, "mattpascoe" <notifications@github.com<mailto: mailto:notifications@github.com%3cmailto:%20%0b> notifications@github.commailto:notifications@github.com>> a écrit :

Another thought I have currently on this topic.

I could add an 'override_data' column to the DNS table. Then you would add a record as usual but select the override option. This would bypass the typical checks that happen today and place either the IP or the points_to value into the override_data column. I think the major columns to deal with are interface_id and dns_id.. when overriding, these two columns would not be used and the override_data column would be.

I think this is a feasible option.. It was a quick thought I had and I wanted to capture it here. It needs much more thought put into it. I'm hoping it isn't a huge amount of effort. My fear is it will be......

— Reply to this email directly or view it on GitHub< https://github.com/opennetadmin/ona/issues/70#issuecomment-43903521> .

— Reply to this email directly or view it on GitHub< https://github.com/opennetadmin/ona/issues/70#issuecomment-43923804>.

---

This email and/or any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. This email and/or any files transmitted with this email may contain confidential and/or proprietary information. Accordingly, if you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please advise the sender by reply email and delete the message. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Borderfree Group companies. Finally, viruses and other harmful code can be transmitted by email. As such, the recipient should check this email and any attachments for the presence of viruses or malware. Borderfree Group companies disclaims any and all liability for any damage caused by any virus or malware transmitted by this email and/or any files transmitted with this email.

---

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

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

---

This email and/or any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. This email and/or any files transmitted with this email may contain confidential and/or proprietary information. Accordingly, if you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please advise the sender by reply email and delete the message. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Borderfree Group companies. Finally, viruses and other harmful code can be transmitted by email. As such, the recipient should check this email and any attachments for the presence of viruses or malware. Borderfree Group companies disclaims any and all liability for any damage caused by any virus or malware transmitted by this email and/or any files transmitted with this email.

---

[mattpascoe]

@fxpottier My plan was to add a new column to the dns_records table that would store the 'external' record information. In the case of an A record it would be the IP address that did not exist in ONA. In the case of a CNAME it would be the external FQDN that it points to. This would work for MX, NS, SRV and other similar record types. The existence of data in this column would override the other data when things are built into configurations. The GUI would need a checkbox to 'override' the data integrity checks and allow you to provide the value that is placed in this new column. The idea of doing the gethostbyname is nice but ultimately I'm not sure for this its necessary. I say this because if you point to something outside of your environment there are several situations where the record may not yet exist or is transitory in some way. I'd say if you are 'overriding' things with your own data then just go for it and let things fall where they may. :)

@rdorman The ability to track DNS views already exists. Its not 100% complete but you should be able to insert all the data as needed. You must go to admin->system config and set 'dns views' to 1. This will enable the feature. Then you will need to add other views beyond the DEFAULT view. This is done under admin->manage dns views. The part that is not fully complete however is the build_bind functionality to build the various view enabled configs. More work here of course but shouldn't be too terrible.

Hope that helps explain things further.

[fxpottier]

And what about overriding (in the code) when pointing to CNAME out of ona.zone?

François-Xavier POTTIER Le 23 mai 2014 05:56, "mattpascoe" notifications@github.com a écrit :

@fxpottier https://github.com/fxpottier My plan was to add a new column to the dns_records table that would store the 'external' record information. In the case of an A record it would be the IP address that did not exist in ONA. In the case of a CNAME it would be the external FQDN that it points to. This would work for MX, NS, SRV and other similar record types. The existence of data in this column would override the other data when things are built into configurations. The GUI would need a checkbox to 'override' the data integrity checks and allow you to provide the value that is placed in this new column. The idea of doing the gethostbyname is nice but ultimately I'm not sure for this its necessary. I say this because if you point to something outside of your environment there are several situations where the record may not yet exist or is transitory in some way. I'd say if you are 'overriding' things with your own data then just go f or it and let things fall where they may. :)

@rdorman https://github.com/rdorman The ability to track DNS views already exists. Its not 100% complete but you should be able to insert all the data as needed. You must go to admin->system config and set 'dns views' to 1. This will enable the feature. Then you will need to add other views beyond the DEFAULT view. This is done under admin->manage dns views. The part that is not fully complete however is the build_bind functionality to build the various view enabled configs. More work here of course but shouldn't be too terrible.

Hope that helps explain things further.

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

[mattpascoe]

Capturing another lame workaround thought. (yes one of these days I'll actually fix this problem)

Add a host called 'header-file.example.com' (use whatever domain you have in your system).. Add an IP address that makes sense, something out of the way and un-used. I used 192.168.0.10.

Then you could add a CNAME like 'mycname.example.com' that points to header-file.example.com. MAKE sure that both of these DNS records are marked as disabled. I'd also suggest putting good notes for these hosts and dns records that indicate they are actually defined in the header file.

Basically this is a cheesy way to get records in ONA that can be searched but that are disabled and do not create DNS configurations. It helps to point you at the fact that there are magical hidden records in a file outside of ONA data. You still of course need to add the REAL records into your header file.

This is minimal stop gap until I can add the header file blob to the zone and or the override record idea.

[dmgeurts]

This is an old thread, dare I ask if there's any news on this?

Background: Just ran into this issue. I have ONA for home networking and FreeIPA for (home) business stuff. I have a firewall that crosses both domains and thus was hoping to add a CNAME into ONA (with a short local name for users (lazy me)) to an A record that resides in the DNS server on the FreeIPA server. ONA won't let me, great to have such a consistency check, but I'd love to either disable the sanity check on my ONA server or be allowed to override and accept the risk for this one CNAME record.

Pretty please?

[mattpascoe]

For sure this is a long standing issue and I've not resolved it as I had hoped to. It comes down to time and effort and this one is a bugger to do 'right'. I had started down a path that I think would be viable. It's probably in the 50% complete range. heck the name of the branch indicates that I saw it as finally addressing an old problem. (https://github.com/opennetadmin/ona/tree/feature_finaly).

I won't try and mislead you.. It's a busy time for me right now and I can't even keep up with some of my higher priority things in life. My desire is certainly to work on this and get a solution as it is probably the #1 feature to implement. These reminders keep it fresh in my mind so I say keep hounding/reminding me! ;)

This is the "workaround" using footers but it is of course not optimal either: https://github.com/opennetadmin/build_bind#fetching-zone-footers-from-remote-web-server

Hopefully that could be an option. I would also suggest possibly using the tinydns backend (https://github.com/opennetadmin/build_tinydns) as it has a much simpler footer type solution. This is actually what I use at $DAYJOB and probably why I've not been forced into fixing this mess.

Anyway, I hope this non answer might give you viable workarounds. And you are reminding me that I STILL need to address this issue.

[dmgeurts]

That's the issue with todo lists, they seem to only get longer and never shorter...! I feel your pain.

As it's a single entry, I created an A record that isn't served by ONA, but happily accepted into config, just so I can point the cname there. Dirty, but it works...