A crazy idea

Mon Jul 19 12:41:51 UTC 2021

What you propose is not outlandish; some ISPs have been dual stack and providing some combination of these services for years.  They already provide IPv6 ip6.arpa delegations should their business customers want them.  Some even provide at least a /56 so customers can have multiple /64 subnets.  And we, I mean they, can also provide RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.

  Mark

On 7/19/21, 8:13 AM, "NANOG on behalf of Stephen Satchell" <nanog-bounces+mark_feldman=comcast.com at nanog.org on behalf of list at satchell.net> wrote:

    First, I know this isn't the right place to propose this; need a pointer
    to where to propose an outlandish idea.

    PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
    that limits deployment of IPv6 fully:  reverse PTR records in the
    ".in6.arpa." zones.

    (Now that I think about it, this may very well be a network operator
    issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)

    I've been going 'round and 'round with AT&T about "static" IPv6
    addresses.  In particular, I can't get a PTR record in the ip6.arpa.
    zone to save my life.  Now, the problem is not really ripe yet, because
    the big reason for PTR records is for mail servers -- best practice
    calls for AAAA/PTR agreement, just like for IPv4 the best practice is
    for A/PTR agreement.

    The existing DNS providers can support delegation domains, so that I
    don't have to have DNS servers of my own if I don't want to.  It could
    be that one would need to "buy" the delegation domain, but that's a
    front-office consideration.  Personally, I use register.com for my
    domain DNS zones.  I believe strongly that other registrars that offer
    customer zone editing, plus DNS service providers, can support reverse
    delegation zones with a minimum of hassle, and without charging an arm
    and a leg for the service.

     From the customers' viewpoint, a GUI would make the maintenance
    relatively painless.

    (Keying the information below took a long time.  Any rational DNS admin
    and DNS service provider would have automation in place to take out the
    painful work.)

    What would the domain names look like?  Let's take my current IP/IPv6
    assignments from AT&T:

       2600:1700:79b0:ddc0::/64
       99.65.194.96/29

    The IPv6 delegation would be easy:

    > 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
    > 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

    because the delegation would always be on a /64 boundary. The customer
    assignments would be straightforward.  In my BIND9 zone file, it would
    look something like this:

    > $ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
    > @ IN SOA ...
    > @ NS my-DNS-server-1.
    > @ NS my-DNS-server-2.
    > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com.
    > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com.

    Delegations for the IP range, not being on an octet boundary, would be a
    little more problematic:

     > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
     > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
    IN CNAME $.96-103.194.65.99.in-addr.arpa.

    In my BIND9 zone file, it would look something like this:

    > $ORIGIN 96-103.194.65.99.in-addr.arpa.
    > @ SOA ...
    > @ NS my-dns-server-1.
    > @ NS my-dns-server-2.
    > 96 IN PTR server1.example.com.
    > 97 IN PTR server2.example.com.

    The advantage to this system to the number providers is they would have
    one administrative record per customer, instead of having to deal with
    each PTR record individually.  The advantage to customers is they don't
    have to beg and snivel to get PTR records, just beg and snivel once to
    get the delegation.  The advantage to DNS server providers is they have
    something else to sell.

    Want to encourage IPv6 adoption?  This would help.