Hi and thanks for your comments. As Simon commented the name tag is just a name although KEA DDNS server also has to interpret the in-addr.arpa name in order to select correct nameserver to send updates. As of now I'm quite sure KEA doesn't understand any other syntax except standard, old non-VLSM subnets. RFC2317 actually isn't implemented here. Well, as Darren says, this is internal only so I'm in control of the setup đ. As of now I've just set up the whole 10.40 net and that works as it should.
Hopefully some KEA DDNS developers picks up on this thread and implements the VLSM/RFC2317 stuff one day. ./PerW Sensitivity: Internal > -----Original Message----- > From: Kea-users <kea-users-boun...@lists.isc.org> On Behalf Of Darren > Ankney > Sent: lørdag 18. mars 2023 11:32 > To: kea-users@lists.isc.org > Subject: Re: [Kea-users] Reverse DDNS name syntax (INTERNAL) > > This 10.140.128.0/18 is an RFC1918 zone so he shouldn't have to worry about > what his ISP does. He can set this zone up in his resolver and/or forward to > his authoritative server. He could also setup a stub zone in his resolver for > this rfc1918 zone. He can make it work since its internal only - he is in > full > control. The only question is what is supported by what. I understand why > he doesn't want to setup > 64 zones if he can help it :) > > On Fri, Mar 17, 2023 at 7:41âŻPM Simon <dh...@thehobsons.co.uk> wrote: > > > > Darren Ankney <darren.ank...@gmail.com> wrote: > > > > > AM Weisteen Per <per.weist...@telenor.no> wrote: > > > > >> I'm running a DNS server which is authoritative for an internal classless > subnet being 10.40.128.0/18 and defined in BIND as 128-191.40.10.in- > addr.arpa. > > >> Is that notation also valid for KEA 2.0.3 ? > > >> IE, may I use > > >> > > >> "reverse-ddns" : { > > >> "ddns-domains": [ > > >> { > > >> "name": "128-191.40.10.in-addr.arpa.", > > >> "key-name": "ddns-key.zone2", > > >> "dns-servers": [ > > >> { > > >> "ip-address": "10.12.14.18" > > >> }, > > >> { > > >> "ip-address": "10.12.16.36" > > >> } > > >> ] > > >> }, > > > > > the ARM doesn't say it won't. It doesn't say it will either. I > > > looked around and was not able to find an RFC that specifies setting > > > up the domain the way you did. I found this one: > > > https://www.rfc-editor.org/rfc/rfc2317 that seems to suggest that > > > 0/18.128.40.10.in-addr.arpa is a standard. I saw another non-RFC > > > that suggested 0-18.128.40.10.in-addr.arpa. Whether Kea supports any > > > of that, I don't know. I'd have to test. > > > > I wouldnât have thought any of those would work. The DHCP server is going > to create the reverse address by reversing the octets and adding .in- > addr.arpa. Thatâs a limitation of the way IPv4 addressing and reverse > addressing works. > > > > The key thing to bear in mind is that for BIND, the name of the zone really > doesnât matter - it really doesnât care what the zone is called. But, and > going > from memory and itâs been a long day (and a long time since I last look at > this), BIND wonât use that zone for reverse DNS without âoutside helpâ. > > The only time Iâve tried to use something similar was when trying to > > do reverse DNS for (IIRC) a /28. It relied on setting up a zone like > > 32-48.c.b.a.in-addr.arpa. But it only worked if âupstreamâ (typically > > your ISP) creates records (PTR ?) of the form 32.c.b.a.in-addr.arpa -> > > 32.32-48.c.b.a.in-addr.arpa and delegated 32-48.c.b.a.in-addr.arpa to > > your server(s). Needless to say, our upstream wasnât prepared to do > > this, and their promises of â!just tell us any changes and weâll do > > them turned out to be empty once past the initial setup :-( > > > > So I think easiest way to make it work is to reconfigure BIND with the 64 > > /24 > zones that make up 10.40.128.0/18 - i.e. 128.40.10.in-addr.arpa, 129.40.10.in- > addr.arpa, etc. Things will then happen automagically. Some scripting to > generate a file which you include into the config will make things a bit > easier. > > > > > > Simon > > > > -- > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > > > Kea-users mailing list > > Kea-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/kea-users > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users