One IP address but two different records in each view

[bradbendy]

Maybe I am overlooking something here but I have two views setup one for public and one for internal. Need to have a different hostname/PTR for the public vs internal. When I go to edit the IP address I can only choose one zone and one record per IP address. Am I missing something or is this not supported? I would assume this is what several people are using views for but I could be wrong.

Thanks

[peteeckel]

Hi @bradbendy, you are completely correct in your assessment.

This is exactly the reason why the IPAM coupling feature as it is now is labelled "experimental" - it has some limitations that are not recommending it for production-level use. One of the limitations is the restriction you found - the solution is limited to one view per IP address, and the current concept does not allow to extend it beyond that.

There are, however, plans and a new concept for IPAM synchronisation that does not have this limitation. If all goes according to to plan this will be addressed in the next few months. It will also make coupling IP addresses to DNS records more automated than it is now.

[bradbendy]

Hi,

Awesome, thanks so much. I will sit tight and keep my eye out for that. Been holding off on doing this manually since well it's a lot of extra work. I can at least get the public side going for now! Appreciate it!

[peteeckel]

Just so you can plan forward, here's the new concept in short words:

• There will be a mapping from IPAM Prefixes to DNS Views (many-to-many)
• When you enter a DNS name in an IP addresses "DNS Name" field, NetBox DNS will find all prefixes containing the address that have one or multiple views assigned to them. If there are multiple prefixes, the smallest one takes precedence.
• Now for each view, the longest zone label path matching the DNS name will be determined.
• For each of the resulting zones, the address record will be added.

This, unfortunately, has some limitations, too, though much less problematic ones:

• The FQDN must be the same in each view. This results from there being only one "DNS Name" field in the IP address model (and even if there were more than one it would be unclear how to map it to a view)
• The IPAM "DNS Name" field does not allow IDNs. Not a real restriction as you can enter punycode at any time, but not as comfortable as it could be.
• You always need to map a complete prefix to a view. If necessary, we could use custom fields to exclude specific IP addresses from the automatism, but I don't want to make it overly complicated before there is strong demand for such a feature
• We can do away with some of the custom fields (Name and Zone will no longer be necessary), but we still need to keep "Disable PTR" and "TTL" at least as optional fields.

If a plugin could modify core forms there would be some more options for an automatism, but after thinking about it for quite some time this is the most flexible solution I can come up with at the moment.

[bradbendy]

So I guess for what im trying to do that won't work anyways. We have a use case that the views have different DNS names, so same IP but the view then determines what actual record is shown (think hostnames on routers and you want more generic public facing but more descriptive for internal folks).

Issue with a custom field is then that field is at the bottom so from a process flow when adding a new IP it's not very clean (why I held off trying to roll something custom myself). But yes I can see how since we can't modify the native forms it does pose a challenge on how to do certain things.

If there is going to be a config variable for only having it use the "DNS Name" field on the IP address I guess I could do a custom field then have a script run and insert the internal view record via the API. That might be easiest for me, just do a webhook on update of IP address and be done with it.

[peteeckel]

Yes, that's one of the cases where any automatism faces some challenges - if you need to maintain multiple different host names per IP address (and not the same FQDN in multiple views) you'd need a couple of custom fields in the IPAddress field, and since custom fields are pretty limited, too, you'd have to create some code specific to your use case anyway. This doesn't lend itself to any kind of generic automatism at all.

How do you determine the host names (and which host name to apply in which view) for each IP address? Somewhere there must be some kind of mapping, either individually for each IP address or on a higher hierarchy level (VRF, prefix, IP range etc). I'm always looking for the most generic solution possible as it doesn't help if a solution works for one specific use case only - if you have a good idea for a more generic solution that the one I came up with above I'll be glad to adopt it.

But as you said - custom fields are nice, but limited (and placed awkwardly for any work flow), additionally you can't get rid of the "DNS Name" field, which is then bound to confuse at least some users (which is why I plan to actually use it as the source of the FQDN), and we can't change the core forms so we need to work with what we have plus custom fields.

I agree with you that if your case is so special that a generic solution (which is bound to be a compromise in most cases) doesn't fit at all a custom script that triggers on IP address creations, updates and deletions will be your best bet. Fortunately NetBox provides that option, but if I can bake in something generic that helps I'll be glad to do so.

[peteeckel]

After thinking about this a bit longer, so far the only idea i could come up with that would solve your problem in a general way is a JSON custom field that contains a mapping between views and FQDNs per IP address, such as

{
"internal": "srv08154711.example.com",
"external": "mx1.example.com"
}

With the value of "DNS Name" being used as a default if the JSON field is missing or there is no mapping for a specific view.

IMHO this is awkward and does not really provide a desirable UX. The advantages of this method in the workflow are also somewhat limited, so unless someone finds it immensely useful I'd rather not go down that road.

Another way would be to use the generic mechanism and add CNAMEs, though that would expose internal hostnames to the external view, which might not be acceptable.

[Flabenelli]

This question it's quite old so let me know if my question is not related and I'll open a new one.
I have in the same view, many zones to the same ip, but as the original issue was, you can only add one DNS Name to an IP, so how can would be the correct approach?

[peteeckel]

Actually this question was related to the old "IPAM Coupling" feature, which has been removed with NetBox DNS version 1.1 and replaced by IPAM DNSsync.

Unfortunately, one fundamental thing hasn't changed: You can only add one DNS name to an IP address. This is a property of the core NetBox IPAddress module and will probably not change. Since the whole idea of synchronising IPAM against DNS is to use the IP address as a source for generating DNS records, this limits the options you have.

The most elegant solution would be to have multiple DNS names per IP address. An option I considered earlier was to define a list of DNS names as a custom field, but that would, as I wrote earlier, involve a JSON custom field as there currently is no such thing as an "array of strings" custom field in NetBox. Using a JSON field for day-to-day configuration is not an option I would really consider - it's OK for things like zone filters that you set up once and then basically forget about them, but not for something you'd use with hundreds or thousands of IP addresses.

So we're down to one DNS name per IP address, and that probably won't change soon. Unfortunately that doesn't help you with your use case. So probably DNSsync won't be able to help you at all, and you can disable it or remove the mapping from your prefixes to your views, which almost has the same effect.

Instead you can turn on another feature (that is not used very often, but it could be useful in your case): feature_ipam_dns_info.

PLUGINS_CONFIG = {
    'netbox_dns': {
        ...
        'dnssync_disabled': True,
        'feature_ipam_dns_info': True,
        ...
    }
}

(disabling DNSsync is optional). Please remove the assignments from DNS Views to IPAM Prefixes before you disable DNSsync, or you will will be left with the managed address records in your database.

That feature will give you DNS information for your IPAM IP addresses:

Would that be more helpful? You'll have to be aware that since there isn't an actual link between the IP addresses and the DNS records in this case you might see records that are not actually related to the IP address your looking at - i.e. if you have multiple VRFs there is no way NetBox DNS can "know" which of the VRFs you're referring to.

[Flabenelli]

I just tried you propose solution and is excellent!, as you said the most elegant would be to have multiple DNS entries in DNS Name, but feature_ipam_dns_info it's really useful. I think it should have a dedicated section in the documentation.

Thank you so much for you help.

[peteeckel]

You're welcome! I added the idea to use multiple names to my long-term-planning list - sometimes new functionality in NetBox creates chances to add long-wanted stuff to the plugin as well, so it's not forgotten.