Classless IN-ADDR.ARPA delegation (RFC 2317) support

[micush]

Hi Shreyas,

Greetings to you and I hope this finds you well. I know others have asked about RFC 2317 support and you've offered indirect suggestions on workarounds, but I believe a more formal solution is required.

The RFC itself doesn't offer a definitive answer on how to implement it and gives a couple of suggestions on how to do it, but other platforms have done things like '255-128.10.in-addr.arpa' or '9/128.10.in-addr.arpa for an example of a 10.128.0.0/9 network. Those platforms that have implemented it do it a bit differently between them, but some sort of solution for reverse CIDR authoritative primary/secondary zones and forwarding zones is a necessity for me at this point. My DNS configs get pretty ugly having to create 128 different forwarding zones to point back to my authoritative servers just to get classless reverse DNS functioning properly.

Any insight or help would be appreciated.

Thanks and regards,

Michael

[ShreyasZare]

Thanks for the post. The problem with finding a solution to this is that there are several solutions possible and those depend on the scenarios. Which is why its kind if tough to generalize a solution that would fit all use-cases. Some scenarios may like to use CNAME entries like suggested in the RFC while some may need to have NS records to delegate to another name server. In your case, you are using conditional forwarders which is a proprietary option available on this DNS server.

The problem with having zone like 255-128.10.in-addr.arpa or 9/128.10.in-addr.arpa is that they are not queryable since they do not follow the reverse lookup request's pattern and thus become unresolvable unless some reverse zone has NS records or CNAME for them.

With forwarder zone setup, you do not really need to create several forwarder zones, you can just have one large scoped forwarder zone with a default FWD record that forwards to "This Server" to allow resolving things normally when there is no answer available. Then add FWD records for specific reverse entries in the same zone which would forward to the required name server.

[mbevc1]

Hm, interesting observation here - not sure if this was further worked on or not, but I managed to create zone x/x.y.z.in-addr-arpa and add records to it - works fine with upstream having CNAME records.

But when doing import it doesn't quite works and imports incorrect PTR records, e.g. picks @ asa domain stub and adds it to TTL :) Also noticed when deleting zone I got an error saying path doesn't exists (I'm assuming in DB or file system).

[ShreyasZare]

Hm, interesting observation here - not sure if this was further worked on or not, but I managed to create zone x/x.y.z.in-addr-arpa and add records to it - works fine with upstream having CNAME records.

But when doing import it doesn't quite works and imports incorrect PTR records, e.g. picks @ asa domain stub and adds it to TTL :) Also noticed when deleting zone I got an error saying path doesn't exists (I'm assuming in DB or file system).

@mbevc1 thanks for the feedback. The zone file name on disk uses the exact same name as that of the zone so the / char is causing issue when saving file to disk. So the zone gets created in memory but fails to save it on disk. I am adding validation for such chars to avoid such issues.

The import parsing issue is probably related to the same zone file parsing issue that we had discussed earlier in another issue. If you can give an example text entry then I can confirm if it works with the fix done in code.

Another thing to add here: I am planning to implement the $GENERATE directive for this issue so that it can be used to generate all the required records without need to write a custom script. But this will be taken up after a few other tasks that are planned.

[mbevc1]

@ShreyasZare thanks, yeah it's a bit annoying as I've got this format from the provider so if we could filter for those and adjust file names that would be great!

Yeah, import might be a weird one, possibly related to that. I need to double check next week.

[mbevc1]

Hey @ShreyasZare 👋 . Hope everything is well, do you have any updated on the new release?

[ShreyasZare]

Hey @ShreyasZare 👋 . Hope everything is well, do you have any updated on the new release?

Thanks for asking. The core clustering feature is in final implementation stages along with some ongoing testing. There is however another task pending after that which is to implement clustering support for all API calls so that when you login to one of the node's admin portal, you will be able to see aggregate data for the entire cluster and will be able to manage settings for all nodes via the node that you logged on to. This make take a few weeks or so I guess. Hoping to get it done soon.

[mbevc1]

Not trying to rush you, but I was just wondering about the next release and if perhaps this might be also affecting current release: https://arstechnica.com/security/2025/10/bind-warns-of-bugs-that-could-bring-dns-cache-attack-back-from-the-dead/ ?

[ShreyasZare]

Not trying to rush you, but I was just wondering about the next release and if perhaps this might be also affecting current release: https://arstechnica.com/security/2025/10/bind-warns-of-bugs-that-could-bring-dns-cache-attack-back-from-the-dead/ ?

@mbevc1 Thanks for asking. The next release should be done in a couple of weeks. The DNS server is not affected by vulnerabilities that the article mentions. The DNS server implements techniques to detect attempts to spoofed UDP response and will immediately switch to TCP transport to mitigate such attacks. It also uses cryptographically secure random number generator so that's not an issue too.

[mbevc1]

Cool, thanks for the quick response mate!