How should one declare reverse zones which don't fall on octet, or /24 boundaries?

[wolfspyre]

so.... declaring of reverse zones is a little wonky...

Netbox DNS, right now, works fantastically for /8 /16 and /24 scoped reverse zones.

If you declare the reverse zones:

• 10.in-addr.arpa (/8 boundary)
• 1.10.in-addr.arpa (/16 boundary)
• 1.128.10.in-addr.arpa (/24 boundary)
• 254.10.in-addr.arpa (/16 boundary)

and add A records for:

• foo.example.com -> 10.128.1.1
• bacon.example.com -> 10.128.200.1
• bar.example.com -> 10.1.1.1
• baz.example.com -> 10.254.1.1

foo.example.com gets an entry in the 1.128.10.in-addr.arpa zone.
bar.example.com gets an entry in the 1.10.in-addr.arpa zone.
baz.example.com gets an entry in the 254.10.in-addr.arpa zone.
bacon.example.com gets an entry in the 10.in-addr.arpa zone.

with, for example, a /23, I think the pattern of declaring the adjacent /24 reverse zone makes sense....
ie

10.100.0/23 = ( 10.100.0/24 10.100.1/24 ... or 1.100.10.in-addr.arpa and 0.100.10.in-addr.arpa)

but what to do about, for example:

172.16/12
doing that by obvious bounds would require declaring 16 /16 arpa zones:

• 16.172.in-addr.arpa
• 17.172.in-addr.arpa
• 18.172.in-addr.arpa
• 19.172.in-addr.arpa
• 20.172.in-addr.arpa
• 21.172.in-addr.arpa
• 22.172.in-addr.arpa
• 23.172.in-addr.arpa
• 24.172.in-addr.arpa
• 25.172.in-addr.arpa
• 26.172.in-addr.arpa
• 27.172.in-addr.arpa
• 28.172.in-addr.arpa
• 29.172.in-addr.arpa
• 30.172.in-addr.arpa
• 31.172.in-addr.arpa

Which is totally doable....

a bit of a pain, but.... doable...

I wanted to ask what one aught do, because when looking at the LEAST SPECIFIC reverse zone (10.in-addr.arpa) .... it contains any fall-through records which don't fit into any existing smaller-subnet containers (reverse zones declared).... However there's no obvious reference or awareness of the smaller subcontainers.... IE: no NS records pointing to the other zone(s), or links to 'child reverse zones'... IE no way of indicating that there are reverse-zones-of-greater-specificity within this dns "view" (or also lacking a view)

This leads me to believe that I'm doing something wrong in that the 'parent prefix reverse zone' doesn't seem to have awareness of the child-prefix reverse zones... an I figured it'd prolly be better to ask how to model this relationship, rather than just assuming I understood how it was supposed to be done... :)

[peteeckel]

Hi @wolfspyre, actually the 'official' way for declaring non-octet delegations is to declare a bunch of octet-delegated zones (except for the RFC2317 case, which is, as you know, an entirely different beast. And no, I haven't forgotten about it, there just were other priorities such as NetBox 3.4 :-)).

Almost everything about IPv4 is a pain, and non-octet delegations are no exception to this rule. If I have to do it I usually create a small CSV or JSON file with all the zones I need and import it - that works pretty quickly (in most cases, see below) and doesn't hurt nearly as much as clicking through the UI several (potentialy many) times. Or you can hope that someone(TM) finds the time to implement something like the mechanism that can be found in other places in NetBox, where you can, for example, define network interfaces by using a syntax like eth[0-16] for the interfaces eth0, eth1, eth2 ... eth16. It's somewhere on my list :-)

BUT (here comes the catch): It can be quite slow to do bulk creations like that. That is currently a design issue with the way new .arpa zones are created: For each zone that gets created, NetBox DNS needs to check whether there are records that need to be moved from a higher-level zone down to a more specific zone (and vice versa when a zone is deleted). That process is currently not extremely fast, and it needs to be done for potentially many records. There have been a couple of changes recently (based on commit 8ebb011, which lays ground for offloading some of the slow operations to PostgreSQL), and there will be some more to improve the performance of that kind of operation, but it's still work in progress. The RFC2317 stuff is also a case where this comes in handy (read: you're up a certain creek without it).

As for the reference to the less specific containers (a.k.a. 'subdomains', or, more strictly speaking, 'more specific zones' as there might be the exotic case of a zone between 10.in-addr.arpa and 1.0.10.in-addr.arpa that's not being controlled by NetBox DNS (don't ask!)): In #275 you suggested some enhancements that at least visually show zones that refer to subdomains of a given domain, and, thanks to the changes in NetBox 3.4, that can and eventually wil be done. The result would be a tab that shows all zones in NetBox DNS that are hierarchically under any given zone.

And the good news is: The commit mentioned above makes that enhancement pretty easy and fast to implement. Provided I find the time ... currently customers are threatening me with financial clubs to do different things instead, but that will not last forever :-)

[wolfspyre]

ohai @peteeckel !!

Firstly:

FRAKKIN THANK YOU

Seriously, I don't EVER intend to seem unappreciative, or be more annoying than I am intrinsically :)

Secondly:

Yeah, I was figuring that creating the octet-bounded-subnets was the right call; but as it isn't clearly articulated anywhere, I wanted to make sure that I wasn't missing some cleverly nuanced naming "standard" which allowed one to more elegantly encompass sub octet-bounded-address-space in a single container-construct.
SIDE NOTE: Wow... describing shite gets hard when almost every word conveying the concept of encompassing a blob of related things together into a single entity has multiple existing technical context-domain-specific meanings....

RE: extrapolating and magically creating / populating arpa-sub-zones

Can the existing Netbox IPAM RIR/Aggregate/Prefix logic / tooling / scaffolding be leveraged? or is it not the right tool for the job here?

I think it might be semi-not-crazy to have this be a configurable-at-a-netbox-instance-wide behavior...

(perhaps overridable at a per-cidrblock/arpazone declaration level?)

I'd imagine different use cases are likely to be organization specific,
So the 95% / 5% breakdown will likely be the same desired behavior for all reverse zones declared within a single netbox rig....

That would allow one to have a something like:

AUTOMAGIC_ARPAZONE_CREATION: True
ALL_THE_TURTLES_DEPTH_POPULATION: [ 'child-only','parental-delegation-reference','pedantically-delegated','pedantically-present','child-ancestor']
DEFAULT_ARPAZONE_BOUNDARY: octet
ARPAZONE_MASKSIZE_SLICE_INDICATOR: '✂'

• Child-only
  : When set to child-only the PTR record will be added to the most specific .arpa zone present in the relevant view of the forward zone

• Parental-delegation-reference
  : When set to parent-delegation-reference a shim-ptr record will be maintained in the next-less-specific-arpazone declared within the relevant view containing the forward zone. This shim-ptr record will point to the most-specific-arpazone declared within the relevant view containing the forward zone. The existence of any less-specific-arpazones between the most and least specific arpazones will be overlooked.

• Pedantically-delegated
  : When set to pedantically-delegated upon creation of any arpa zone, Netbox-DNS will review all currently declared arpa-zones within the new-arpa-zone's view-scoped-context and will explicitly create and manage NS records for each address belonging to the most granularly-defined-arpa-zone, within each of the least-granularly-defined-arpa-zones.

bad.example.com:

@                                                                      NS ns1.bad.example.com.
frostbitten.cold-miserable-and-regretting-our-previous-decisions-panda IN A 10.0.1.27
frozen-solid-and.not-so-pretty-anymore-panda                           IN A 10.0.1.28
# subzone delegated to another NS
honeybadger                                                            IN NS ns1.honeybadger.bad.example.com.
its-really-getting-cold.prettypanda                                    IN A 10.0.1.25
# forward record for subdomain NS
ns1.honeybadger                                                        IN A 10.0.1.29
ns                                                                     IN A 10.0.0.10
# subzone delegated to another NS
prettyprettypanda                                                      IN NS ns1.honeybadger.bad.example.com.
prettypanda                                                            IN NS ns1.honeybadger.bad.example.com. 
router                                                                 IN A 10.0.1.1

28✂16.1.0.10.in-addr.arpa:

@      NS ns1.honeybadger.bad.example.com.
16 IN PTR prettyprettypanda.bad.example.com.
17 IN PTR snowflake.prettyprettypanda.bad.example.com.
18 IN PTR rainbows.prettyprettypanda.bad.example.com.
19 IN PTR snowstorm.prettyprettypanda.bad.example.com.
20 IN PTR slush.prettyprettypanda.bad.example.com.
21 IN PTR sleet.prettyprettypanda.bad.example.com.
...
25 IN PTR its-really-getting-cold.prettypanda.bad.example.com.
...
27 IN PTR frostbitten.cold-miserable-and-regretting-our-previous-decisions-panda.bad.example.com.
28 IN PTR frozen-solid-and.not-so-pretty-anymore-panda.bad.example.com.
29 IN PTR ns1.honeybadger.bad.example.com.

1.0.10.in-addr.arpa:

@      NS ns.bad.example.com.
1  IN PTR router.bad.example.com.
...
10 IN PTR ns.bad.example.com
...
16 IN NS ns1.honeybadger.bad.example.com.
17 IN NS ns1.honeybadger.bad.example.com.
18 IN NS ns1.honeybadger.bad.example.com.
...
29 IN NS ns1.honeybadger.bad.example.com.
30 IN NS ns1.honeybadger.bad.example.com.
...

0.10.in-addr.arpa:

@           NS ns.bad.example.com.
1.0      IN NS ns.bad.example.com.
2.0      IN NS ns.bad.example.com.
3.0      IN NS ns.bad.example.com.
...
10.0     IN PTR ns.bad.example.com.
...
255.0    IN NS ns.bad.example.com.
0.1      IN NS ns.bad.example.com.
1.1      IN NS ns.bad.example.com.
2.1      IN NS ns.bad.example.com.
...
15.1     IN NS ns.bad.example.com.
16.1     IN NS ns1.honeybadger.bad.example.com.
17.1     IN NS ns1.honeybadger.bad.example.com.
...
30.1     IN NS ns1.honeybadger.bad.example.com.
31.1     IN NS ns.bad.example.com.
...
255.1    IN NS ns.bad.example.com.
...
255.255  IN NS ns.bad.example.com.

I could explicitly type out examples of the other behaviors, but I think the point is sufficiently conveyed?

I'm trying to be explicit enough to convey the concept, and whimsical enough to make the reader giggle... but I think any further elucidation will be counterproductive....

[peteeckel]

Hi @wolfspyre!

I wouldn't call your contributions annoying, I find them, though not always feasible in their full scale, very inspiring and a lot of things on my ever-growing agenda are derived from them - so don't stop annoying, please! :-)

The idea if somehow linking IPAM structures such as prefixes etc. to DNS data is something I've been mulling over for a while now. There are, however (as usual) some obstacles to a generic solution - and I always try to find a generic solution when it comes to integrating it into any general-purpose tool, as you now. NetBox provides some means that one can use for less-generic cases. However, the relation between IPAM data and DNS data is really something that seems obvious.

Some issues that make it non-trivial:

• IPAM prefixes are not limited to 8 bit boundaries for IPv4 and 4 bit boundaries for IPv6, DNS data are. While this is generally not a problem with IPv6 because generally delegation occurs at 8 bit boundaries, it is for IPv4 where the scarety of addresses and CIDR as the 'answer' to that (I quote the word 'answer' because the real answer is IPv6 and has been for years now) make it necessary to delegate virtually on every boundary you can imagine. DNS can only delegate on labels, which means 8 bit boundaries for IPv4 and 4 bit boundaries for IPv6. This results, among other things, in the scheme you came up with.
• IPAM subnetting does not generally have any relation to DNS zone delegation. While it may seem obvious at first, one actually doesn't have much to do with the other. You can very well have 256 prefixes to a /16 and still just use one in-addr.arpa zone relating to the containing /16, and vice versa. It's possible to relate prefixes to ARPA zones that are defined (as it is currently implemented in the experimental NetBox DNS feature ipam_integration, but an automatism for creating them would not be able to cover the general case.
• DNS zone hierarchies may be totally non-contiguous, while subnets can't. I already mentioned the (somewhat constructed, but possible case of 10.in-addr.arpa being under control of NetBox DNS, 1.10.in-addr.arpa by some other mechanism (such as AD) and then 1.1.10.in-addr.arpa again being in NetBox DNS ... yes, this is not necessarily sensible, but possible, and we're looking for the general case ... (I know you are cringing right now :-)).
• IPAM subnets might be non-unique. I have at least one customer where every customer of theirs has exactly the same set of subnets, while (obviously) not the same set of DNS hostnames. That's what VRFs are for in IPAM, and a potential generic solution for NetBox DNS would be to associate VRFs with zones to disambiguate. On the other hand there might be scenarios in which VRFs are used in IPAM and still no zones in DNS. At least this needs some more thought.
• Inserting automatisms for NetBox core models isn't trivial either - we would need to use a webhook for automatically creating stuff in NetBox DNS when something happens to a prefix, and that webhook would then trigger the appropriate action in NetBox DNS. That's clumsy at the very least ... not sure if there's a better way.
• Then we would need to think about referential integrity. It's fairly easy to link an automatically created DNS reverse zone object back to the IPAM prefix it relates to, but what do we want to do when the prefix goes away? Delete the reverse zone? Keep it in place? And what mechanism to use for it - database-based referential integrity is not an option as that needs to be statically defined in the model, so it's webhook-time all over again, or cron-based scripts (which is really ugly. Both, actually.).
• Probably some other things I didn't think of ... as always. And which anyone implementing the stuff will stumble over sooner or later.
• It doesn't really help that we can't touch the NetBox core models ... but that's a given fact and it's totally understandable and absolutely correct and I hate it anyway. Maybe they come up with a way to add hooks to attach to so a plugin can inject code sooner or later, things are moving quickly sometimes.

OK, enough of the whimsical 'why this is a very stupid idea and will never ever work, boohoo'-lament. What can we do?

For the time being, and actually right now with the current release, the solution is (as in many cases) 'custom scripts'.

You can quite easily create a custom script 'Create Reverse Zones' for IPAM prefixes that does almost what you want. Given the fact that this is a) not an everyday task and b) tedious, scripting seems to be a good option to me. That script would work along the lines of

• Get the prefix for the object it was called for,
• determine all 8-bit (IPv4) or 4-bit (IPv6) boundary prefixes contained in it,
• loop over the resulting prefixes and create the matching reverse zones.
• that's it.

Some parameters for the script are required: The view (may be null) for the zones to create, the name servers (may be an empty list, though providing them is easier), SOA_MNAME and SOA_RNAME. And when I really get bored over the weekend I might actually write it (or help you writing it if you want to give it a go yourself) :-)

And, by the way, another item on my agenda: Optional per-view default NS/SOA_MNAME/SOA_RNAME for new zones. Sigh ... thanks!

As for your example (by the way, I really love your host names!) ... quick question: How do you get your (and the rest of the world's) DNS resolvers to look up names in 28✂16.1.0.10.in-addr.arpa? There is the 'RFC2317' way of using CNAMEs to PTRs, but that would not really work automatically right now ... RFC2317 is bad enough as it is :-)

[wolfspyre]

heya @peteeckel !

As for your example (by the way, I really love your host names!) ... quick question: How do you get your (and the rest of the world's) DNS resolvers to look up names in 28✂16.1.0.10.in-addr.arpa? There is the 'RFC2317' way of using CNAMEs to PTRs, but that would not really work automatically right now ... RFC2317 is bad enough as it is :-)

YAY! The entire reason I put that together was to make you laugh. I'm glad it worked.
There's too little joy in life these days it feels... so I try to inject it wherever I can... because it matters. Your happiness matters.

The IDEA there was that

AUTOMAGIC_ARPAZONE_CREATION: True
ALL_THE_TURTLES_DEPTH_POPULATION: [ 'child-only','parental-delegation-reference','pedantically-delegated','pedantically-present','child-ancestor']
DEFAULT_ARPAZONE_BOUNDARY: octet
ARPAZONE_MASKSIZE_SLICE_INDICATOR: '✂'

was a configuration preference... IE the netbox instance admin is telling netbox-dns how to treat the data fed to it.
the intent was to allow one to more easily convey intent because there's so many overlapping/conflicting standards, terms, data-representation-styles, etc that it's easy for a contextual reference to be misinterpreted.

IE: the characters:
8/10.in-addr.arpa depending on who you are talking to at the moment could mean

" The range of addresses beginning at 8.0.0.0 and ending at 10.255.255.255"

Or it could mean

" The class-A network beginning at 10.0.0.0 and ending at 10.255.255.255 "

I AGREE with you that one is more likely (and arguably more "correct") than the other, however I was attempting to describe a way that the person declaring a hunk of arpaspace could provide a bitmask separator character explicitly.

The subsequent/later rendering of zonefiles/reverse zones in a DNS-Server-consumable-fashion is a RELATED, but separate problem....

This was more intended as a way to inform netbox-dns

This SPECIFIC /28 SLICE of the 10/8 arpa-space is controlled/managed in this zonefile-context here.

from the perspective of the relationships with OTHER arpazones that either contain
( IE: 10.in-addr.arpa )
or are contained within
( IE: 29✂24.1.0.10.in-addr.arpa )
( which could potentially subsequently be re-declared within 30✂28.1.0.10.in-addr.arpa )
the specified zone's address claim.

RE: IPAM

---

I think I was too inspecific wrt words around the IPAM tooling re-use.

If one were to assume that a user of netbox ipam, AND netbox-dns, likely wants to model both.... you could potentially use the ipam object as an anchor/collective-relationship-object so as to be able to quickly look up other zonefiles that may be involved....

IE:

"select arpazone from netbox-dns-datastore where related-ipam-object-id in ['a','b','q']"

as a way of optimizing the related zonefile lookup, or hinting to netbox where the user might want to slice this newly-minted arpafile

(something like if the ipam-subnet-object is a /25 you could infer that there's a high liklihood that the user might want to also declare the subsequent /24 arpafile )

• Non-contiguous is fine... all the arpazonefiles don't NEED to be declared in netbox dns.... However they do LIKELY relate to the same addresses...
• When an IPAM object is deleted, the object ID is not reused, iirc... so the relationship amongst the dns-objects is still valid, even if the original objectID no longer exists.... ((admittedly that's an ugly situation to have to navigate... I don't think there's an OSFA behavior that will work.))

but yeah... I don't know if the concept introduces more pain than it alleviates.... and I'm IN NO WAY SHAPE OR FORM deeply attached to the notion.... rather I'm trying to ideate on how to improve something.... and tossing possibilities into the wind to see what tickles the brains into thought paths not previously meandered...

[peteeckel]

Hi @wolfspyre, it's been a while :-)

RFC2317 support has finally arrived, not here in the morgue of the early NetBox DNS plugin, though.

Have a look at NetBox DNS 0.22.1. Today's release has RFC2317 support and should be fairly usable right now.