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

[Darren Ankney]

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