[conspire] missing rDNS for (intentionally missing) IPv6

[Tim Utschig]

On Wed, Feb 24, 2021 at 03:44:38PM -0800, Rick Moen wrote:
> 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.

I'm interested to hear how this goes. I'm curious if they've
improved...

I attempted to get Comcast ("Business") to do the exact same
thing for me years ago and failed. They instead transferred me to
someone overseas who proceeded to try to sell me Microsoft 360
(because it has a "six" in it?!). I'm not kidding. This wasn't a
fluke, it happened on two separate phone calls. I guess I found a
bug in their phone tree.

As a result of that and other incidents [1] I've been using AT&T
("Business") for ~5 years. Though the speed isn't as good, I've
been much happier with the service. (But not happy enough to stop
me from pre-ordering Starlink.)

Contrast the above incident with AT&T: After a ~30 minute phone
call my ticket was escalated and within ~1 day they had made the
precise edits I had requested to their zone file: Delegate to my
name servers control over my little /64 hanging off AT&T's 6RD
[2] service (tied to one of my AT&T-assigned static IP
addresses). Allowing me to create records as I see fit without
calling anyone or even leaving my shell.

I was a bit surprised they did it for me at all, let alone
without complaint. I was impressed, but also curious what other
sorts of edits they would allow someone like me to make to their
zone files. If I had, oops, accidentally trimmed off a dot or
two, would they still have copy/pasted what I sent them? :-)


$ dig +short -t aaaa tetro.net
2602:306:bd19:a292::2

$ dig +short -x 2602:306:bd19:a292::2
eph.tetro.net.

$ dig +trace -t ns -x 2602:306:bd19:a292::2 | awk '$4 == "NS"' | tail
0.6.2.ip6.arpa.         86400   IN      NS      u.arin.net.
0.6.2.ip6.arpa.         86400   IN      NS      r.arin.net.
0.6.2.ip6.arpa.         86400   IN      NS      y.arin.net.
0.6.2.ip6.arpa.         86400   IN      NS      arin.authdns.ripe.net.
3.0.2.0.6.2.ip6.arpa.   86400   IN      NS      ns1.swbell.net.
3.0.2.0.6.2.ip6.arpa.   86400   IN      NS      ns2.swbell.net.
3.0.2.0.6.2.ip6.arpa.   86400   IN      NS      ns3.sbcglobal.net.
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns3.tetro.net.
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns1.tetro.net.
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns2.tetro.net.

$ dig -t aaaa -x 2602:306:bd19:a292::2 @ns1.swbell.net. | grep -A3 '^;; AUTH'
;; AUTHORITY SECTION:
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns3.tetro.net.
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns1.tetro.net.
9.2.a.9.1.d.b.6.0.3.0.2.0.6.2.ip6.arpa. 86400 IN NS ns2.tetro.net.


[1] me: Can you troubleshoot this? I think it's a line issue.
        ::Provides data, including stats from the modem showing
          noise on the line::
    Comcast: Let's replace your router!
    me: Still seeing packet loss. ::more data::
    Comcast: Let's replace your router again!
    (Days later, finally fixed after a 3rd visit from a tech.)

    (AT&T fixed a similar issue same-day, even though it took the
     tech >4 hours to track down the intermittent issue.)

[2] I've been meaning to check in on the status of AT&T's native
    IPv6 rollout (if such a thing exists). Though their 6RD
    service has worked flawlessly, ~5 years and counting.

-- 
Tim Utschig <tim at tetro.net>