[conspire] missing rDNS for (intentionally missing) IPv6

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] missing rDNS for (intentionally missing) IPv6
> Date: Wed, 24 Feb 2021 15:44:38 -0800

> 2603:3024:182f:d100:220:edff:fe13:ba89 , but there is no reverse-DNS

So, yes, Comcast Business, default setup, the device they provide,
it will use IPv6 autoconfiguration to generally give IPv6 IP addresses to
client devices on the subnet/vLAN.

$ whois 2603:3024:182f:d100:220:edff:fe13:ba89
...
NetRange:       2603:3000:: - 2603:30FF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR:           2603:3000::/24
NetName:        COMCAST6NET
NetHandle:      NET6-2603-3000-1
Parent:         NET6-2600 (NET6-2600-1)
NetType:        Direct Allocation
OriginAS:       AS7922
Organization:   Comcast Cable Communications, LLC (CCCS)
RegDate:        2015-05-13
Updated:        2021-01-25
Ref:            https://rdap.arin.net/registry/ip/2603:3000::
...

> I've actually tried pretty hard to _not_ have an IPv6 address associated
> with my server, because it wasn't obligatory and my life was kept
> simpler.  Except, now somehow...
>
> linuxmafia:~# ifconfig eth2
> eth2      Link encap:Ethernet  HWaddr 00:20:ed:13:ba:89
>           inet addr:96.95.217.99  Bcast:96.95.217.103  Mask:255.255.255.248
>           inet6 addr: 2603:3024:182f:d100:220:edff:fe13:ba89/64 Scope:Global
>           inet6 addr: fe80::220:edff:fe13:ba89/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:543847 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:540860 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:88174897 (84.0 MiB)  TX bytes:211598341 (201.7 MiB)
>
> linuxmafia:~#
>
> Which implies that Comcast Business needs to add this to its rDNS:
>
> 9.8.a.b.3.1.e.f.f.f.d.e.0.2.2.0.0.0.1.d.f.2.8.1.4.2.0.3.3.0.6.2.ip6.arpa. 1h  
> IN PTR linuxmafia.com.
>
>
> (Ten minutes later:)
>
> Talked to Comcast Business Support, and they created an escalated
> trouble ticket to create the PTR record.

Ah, good they acted reasonably promptly (presumably) on that.
When I had 'em put in "reverse" (PTR) for IPv4 ... wasn't exactly super
urgent at the time/moment, ... but also did take 'em a while to get it
in there ... over 24 (but less than 48) hours.

And, though I do have Comcast Business's IPv6 very available to me,
I'm mostly not using that and instead still using he.net's
tunnelbroker.net IPv6 tunneling.  Maybe I'll change that some
day(/month/year/...), but I'd probably retain the he.net's
tunnelbroker.net IPv6 as fallback, if nothing else.
Haven't checked into Comcast Business being able to delegate IPv6 DNS,
hopefully/presumably they'd be able and willing to do that.  And that
is what I have with tunnelbroker.net.http
Alas, Comcast Business - at least last I checked, was unwilling to do
RFC-2317 delegation on IPv4 - as I had with Raw Bandwidth.
Likewise they don't have a portal or the like where one can manage one's
own "reverse" DNS (larger ISPs would typically provide such).

> As it happens, a houseguest did something yesterday that brought down
> power to my server (plugging a high-amperage device into the 1956
> AC feed in the garage), ergo linuxmafia.com's host had an unplanned
> restart.  I _thought_ I had disabled IPv6 in the config.  Is it
> possible I was so frazzled that I didn't add

Drats - power "oops".

> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1

Uhm, ya know, at this point in time, (outright) disabling IPv6 in general
isn't a good idea.  However, if for whatever reasons, one doesn't want,
e.g. routable IPv6 addresses or having such automatically assigned, then
why yes, certainly disable *that* part of it.
E.g. I've got at least 2 hosts set up that way ... notably so they don't
automagically get and use Compcast's IPv6.  Hmmm, I'm trying to recall where
in the config that bit is ... let's see ...
Ah, here we go:
# tail -n 7 /etc/sysctl.conf
########################################################################
# for now, disable autoconf and accept_ra for IPv6 on ens3
# (not yet expected for SMTP SPF, etc.)
# grep . /proc/sys/net/ipv6/conf/ens3/accept_ra  
/proc/sys/net/ipv6/conf/ens3/autoconf
net.ipv6.conf.ens3.accept_ra=0
net.ipv6.conf.ens3.autoconf=0
########################################################################
#
That basically says, as far as IPv6 goes on that host for that
interface (the only network interface besides lo and tunnel interfaces)
not going to accept/honor router advertisements (hence won't alter
routing based on what IPv6 router(s) on subnet/vLAN put out),
nor will we accept/honor autoconfiguration of the interface based on
similar.  With those two for that device (or one could do it likewise for
all), no automagic IPv6 configurion ... yet we haven't otherwise disabled
IPv6 at all.  Anyway, "nowadays", that's probably how one should mostly do
it if one still really wants to (mostly) avoid IPv6 (or key portions thereof).

And outright disabling the IPv6 stack entirely becomes increasingly
problematic.  Note also that in many cases 4to6 mapping is extensively used,
so that all IPv4 addresses can be used as if they were IPv6 addresses.  So,
may just be a matter of time, for many OSes, that outright disabling the IPv6
stack may generally cease to be feasible (at least independent of IPv4).

> ...to /etc/sysctl.conf?
>
> (RM checks /etc/sysctl.conf.)
>
> Nothing in there to de-IPv6 the server.  I _vaguely_ recall that
> I just manually re-IPed the machine from the command line when Raw Bandwidth
> went away and then checked /etc/network/interfaces and /etc/hosts to
> reflect the re-IPing.  And put only IPv4 into those.

Yeah, likely the IPv6 has been there for a while, as Raw Bandwidth's
DSL didn't offer it, but Comcast Business is by default fully
available.  So, probably unless it were manually disabled earlier,
or done so and not persistently, the host probably picked it up.
And, probably mostly a non-issue, well, ... until at least some
MTAs (notably Google's gmail) started being more persnickety about
"reverse" DNS (PTR records) for IPv6.

> Yes, I _will_ consider lightening up on IPv6, after I've verified
> that Comcast Business implemented that DNS addition, and after
> I've amended my own SPF record to add the IPv6.  For now, I am
> just stopping at the point where the dominant SMTP player in the
> entire world was suddenly rejecting everything from my domain/server,
> and count my blessings.

Oh, yeah, don't forget SPF and the like before pressing IPv6 into
intended globally routable address use (e.g. for SMTP).

Ah yes, IPv6 - *mostly* a good thing ... but a different kind'a animal.
(and with those words, about instantly, O'Reilly book covers jump to mind).

Semi-random IPv6/DNS bits:
$ dig +noall +answer +nottl balug.org. AAAA
balug.org.              IN      AAAA    2001:470:1f05:19e::2
$ (n=2; while [ "$n" -le 4 ]; do i=2001:470:1f05:19e::"$n"; echo "$i"  
"$(dig +short -x "$i")"; n="$(expr "$n" + 1)"; done)
2001:470:1f05:19e::2 balug.org.
2001:470:1f05:19e::3 sf-lug.org.
2001:470:1f05:19e::4 berkeleylug.com.
$ dig +trace -x 2001:470:1f05:19e::2
...
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900  
IN PTR balug.org.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns0.balug.org.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns1.linuxmafia.com.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns1.svlug.org.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS nsy.sunnysidex.com.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS nsx.sunnyside.com.
;; Received 697 bytes from 96.95.217.99#53(ns1.linuxmafia.com) in 33 ms

$