[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