[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, 3 Mar 2021 13:41:28 -0800

> $ dig -t PTR  
> 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.  
> +short
> $

I realize it was probably a copy/paste or the like, but also ...

$ dig +noall +question +answer +comments -x  
2603:3024:182f:d100:220:edff:fe13:ba89
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44761
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 638a5b2bb1856e5a4aff73f960400c30d18c251fd1594794 (good)
;; QUESTION SECTION:
;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. IN  
PTR

$

At least for the IPv6 related bit, that might be a fair bit less to
copy/paste, or, heaven forbid, type.  Probably also more human-friendly
to do it with -x - works quite like IPv4, and dig automagically translates
the query.

> At the same time, given that the IPv6 address had been autoassigned
> to my server when the crisis arose from that and caught my attention,
> what guarantee is there that it would be the same IPv6 address if the
> server got one again?  Or, to reframe the question, how do I make sure
> the autoconfigured IPv6 assignment is deterministic?  This may require
> mucking about in the details of my shiny new gateway box to get a better
> grasp of this... stuff.  I see that Michael has posted separately
> something about "IPv6 bits", which I appreciate.
Not to worry, can also always also add that IPv6, in addition to any
autoconfigured, or just configure it to be static with that IPv6.

Also, might want to seriously consider seeing if you can get 'em to DNS
delegate the whole ip6.arpa. /64 to you.  I mean you sure as heck do know
how to wrangle DNS, and in fact you already have ip6.arpa. slave zone(s), so
not too hard to do/pick up (Comcast Business willing).  And there are various
folks that can easily provide you with slave servers.  Anyway, if one goes
that route, once it's in place, you get to then fully control your own  
"reverse"
DNS.

Oh, forgot to mention on the "IPv6 ... some bits" (well, whatever, it was
getting kind of long anyway)
http://linuxmafia.com/pipermail/conspire/2021-March/011537.html
You don't have to have the complication/inefficiency of RFC-2317
https://tools.ietf.org/html/rfc2317
with IPv6 "reverse" DNS, as ip6.arpa. can be split at any 4-bit
boundary, so, from ISP, they'll generally give you "your" (delegated)
own entire /64 (at the smallest) or larger, and none of the
RFC-2317 CNAME --> PTR goop/inefficiencies.
Haven't rechecked recently, but last I checked, Comcast Business won't do
RFC-2317 for IPv4.  :-/  Instead it's the long slow put-in-the-request and
they get around to implementing it (and alas, they don't let customers
self-configure that in their "portal" or the like) ... but I think I'd
also mentioned that before.

> I'm sure with adequate preparation, IPv6 would cease biting me in the
> tochis and motivating me every time to hit it with a big hammer to make
> it go away for the time being.  I have a _reasonable_ grasp of the
> topic, but even on that am a bit rusty because I just haven't worked
> with it frequently.

Sort'a fun to, uh, "play" with ... and *lots and lots* of IP addresses
to play with.  ;-)

>> Seems like BIND, but it's a seekrit cause the version number is
>> redacted.
>>
>>   $ dig +short -c chaos -t txt version.bind. @dns101.comcast.net.
>>   "[SECURED]"
>>   $ dig +short -c chaos -t txt version.bind. @ns1-205.azure-dns.com.
>>   $
>
> Admittedly, I also mess with people who query that RR:
>
> $ dig -c chaos -t txt version.bind @ns1.linuxmafia.com +short
> "Shirley, you're joking"
> $
>
> No point in helping remote strangers doing resource discovery against my
> attack surface.  (I'd let them get a serious answer if there were some
> benefit to the public from that information, but the malicious uses
> outweigh plausible benefits I can see.)

I remember reconfiguring a web server to answer that it was (running on)
some version of ENIAC.

Yeah, various fingerprinting kind of stuff can often figure it out ... but
defaulting to telling 'em exactly what it is (and not fibbing about it)
does mean exploits are more likely to succeed on first attempt (notably
not being a version mismatch - often such exploits are sort'a one-shot -
guess wrong and the service/host is or may be crashed/hung, rather than
actually compromised (other than DoS, anyway).