[Kea-users] Reverse DDNS name syntax (OPEN)

Weisteen Per per.weisteen at telenor.no
Mon Mar 20 10:02:31 UTC 2023


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-bounces at lists.isc.org> On Behalf Of Darren
> Ankney
> Sent: lørdag 18. mars 2023 11:32
> To: kea-users at 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 <dhcp1 at thehobsons.co.uk> wrote:
> >
> > Darren Ankney <darren.ankney at gmail.com> wrote:
> >
> > > AM Weisteen Per <per.weisteen at 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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users


More information about the Kea-users mailing list