I currently have a rDNS delegation for my /29 but I need to update the DNS servers that point to that zone (I'm migrating to a different secondary DNS provider)
I also would like to set up rDNS delegation for my IPv6 subnet (either the /64 I'm using or the /56 that the cable modem gets, whatever I can get). I'm migrating away from a tunnel to the native IPv6 provided with my service, but need reverse records to match the forward lookups that I can change at my whims.
Hello, I hope your day is going well. I will be happy to help with your request and I can get these records for you. Can you please send a private message so I can assist you further? Please include your Comcast Business account number, the phone number listed on your account, and your entire service address. (with the city, state, and zip code)
Thanks so much for that information! I have created a ticket to have your addresses delegated and will be checking in to verify with you once that is complete.
I have 0.0.7.a.0.0.1.1.0.0.0.3.220.127.116.11.ip6.arpa and 7.a.0.0.1.1.0.0.0.3.18.104.22.168.ip6.arpa zones already set up if either of those are the ones to be delegated so that y'all can test if you want, otherwise I'll set up whatever zone(s) I need to.
I did notice a missed call, but unfortunately I can't bring my phone with me into my day-job and I don't particularly care to give out that number for non-day-job related stuff. because... y'kno.. they're listening... *shhh*
So I'm posting an update for anyone who's curious (the system wanted to know if my problem was solved)
I'm in an ongoing email conversation with someone from Comcast Executive Customer Relations to look into this. As of right now, to answer the system's question, no my problem isn't solved yet, but someone is apparently working on it.
As far as my request goes, it's not a technically difficult problem to resolve as it should only require modifying/adding a couple of things to a couple of the .arpa zones in Comcast's DNS servers, but my sneaking suspicion is that it *is* difficult in a bureaucratic sense.
In any case, I'm doing what I can to work with the support team to sort out who's going to handle reverse lookups for my static addresses.
The latest update on this is that now my IPv4 reverse lookups are no longer delegated to my DNS servers (even the old ones!) and there are no PTR records for my static block. We've gone from outdated but functional to completely nonexistant and broken and is definitely a step in the wrong direction....
So...I'm posting this in the public thread because I think it's important for other visitors to see what's going on. To the best of my knowledge, the mods that have been doing their best to try and help me should be all up to speed on the situation, and I commend the support staff here on the forums for their efforts, but your employer is not making life easy for any of us. Seriously..
Also, this kinda serves as the ominous sign above the cave that leads to reverse DNS delegation that reads "Abandon all hope, ye who enter here." For now, just get your PTR requests and save yourself the trouble of trying to get DNS delegation set up.
Three and a half weeks later and it is apparent that the reverse DNS delegation that Comcast set up for me in 2013 for my IPv4 addresses is not something Comcast is capable of doing anymore as evidenced by the fact that asking them to update the NS records resulted in the complete removal of the delegation records. Meanwhile, reverse DNS delegation in my IPv6 Prefix, which is actually easier to do as it just requires the NS records, is apparently also impossible for Comcast. From what I can gather, the Corporate Overlords don't provide the tools to the engineers/techs/support staff to provide these basic services to the customers that are paying extra for static IP addresses, especially considering that this is something they've done in the past. Worse is that because reverse DNS delegation is a trivial thing to set up - so trivial that it could (and should!) be automated with a simple form within the account management console similar to what you might see in a domain registrar account management console for manaing forward lookups with custom DNS servers - that Comcast's refusal to provide that option ends up creating more work for everyone. I mean, I can't be the only one who has a need for proper reverse delegation, can I?
I have resigned myself for now to having PTR records managed by Comcast on their DNS servers, and I have been assured by someone in Executive Customer Relations that the request for my IPv4 PTR records has been completed, however I still do not get PTR records for any of my IP addresses from Comcast DNS servers. When I do the full trace from the root servers, it get's to Comcast's DNS servers and there are no records. Just to make sure it's not something I'm doing wrong, I checked an IP in the /29 block right above mine and Comcast is serving up PTR records for those addresses.
I'm told the request for PTR records for a handful of my IPv6 addresses has been submitted but not yet completed.
By the way, just as an example, here is the full trace lookup for one of my IP addresses:
ns1:~ # dig -x 22.214.171.124 +trace ; <<>> DiG 9.11.2 <<>> -x 126.96.36.199 +trace ;; global options: +cmd . 82898 IN NS f.root-servers.net. . 82898 IN NS g.root-servers.net. . 82898 IN NS a.root-servers.net. . 82898 IN NS d.root-servers.net. . 82898 IN NS h.root-servers.net. . 82898 IN NS j.root-servers.net. . 82898 IN NS k.root-servers.net. . 82898 IN NS l.root-servers.net. . 82898 IN NS e.root-servers.net. . 82898 IN NS c.root-servers.net. . 82898 IN NS m.root-servers.net. . 82898 IN NS i.root-servers.net. . 82898 IN NS b.root-servers.net. ;; Received 253 bytes from 192.168.12.10#53(192.168.12.10) in 0 ms in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. ;; Received 457 bytes from 2001:500:200::b#53(b.root-servers.net) in 44 ms 74.in-addr.arpa. 86400 IN NS y.arin.net. 74.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net. 74.in-addr.arpa. 86400 IN NS x.arin.net. 74.in-addr.arpa. 86400 IN NS z.arin.net. 74.in-addr.arpa. 86400 IN NS u.arin.net. 74.in-addr.arpa. 86400 IN NS r.arin.net. ;; Received 219 bytes from 2001:dd8:6::101#53(e.in-addr-servers.arpa) in 194 ms 92.74.in-addr.arpa. 86400 IN NS dns103.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns104.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns102.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns101.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns105.comcast.net. ;; Received 197 bytes from 2001:500:f0::63#53(r.arin.net) in 69 ms 206.92.74.in-addr.arpa. 7200 IN SOA ns1.comcastbusiness.net. domreg-tech.comcastbusiness.net. 2019021401 3600 7200 604800 7200 ;; Received 124 bytes from 188.8.131.52#53(dns102.comcast.net) in 39 ms
I get an SOA record back because there's no PTR. It's serial number suggests that the zone was updated yesterday after I was assured that the PTR records had been added, but.... *chirping crickets*
For an IP in the next /29 block up from mine:
ns1:~ # dig -x 184.108.40.206 +trace ; <<>> DiG 9.11.2 <<>> -x 220.127.116.11 +trace ;; global options: +cmd . 82708 IN NS f.root-servers.net. . 82708 IN NS g.root-servers.net. . 82708 IN NS j.root-servers.net. . 82708 IN NS h.root-servers.net. . 82708 IN NS i.root-servers.net. . 82708 IN NS a.root-servers.net. . 82708 IN NS k.root-servers.net. . 82708 IN NS m.root-servers.net. . 82708 IN NS c.root-servers.net. . 82708 IN NS l.root-servers.net. . 82708 IN NS b.root-servers.net. . 82708 IN NS d.root-servers.net. . 82708 IN NS e.root-servers.net. ;; Received 253 bytes from 192.168.12.10#53(192.168.12.10) in 0 ms in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. ;; Received 458 bytes from 2001:500:200::b#53(b.root-servers.net) in 45 ms 74.in-addr.arpa. 86400 IN NS u.arin.net. 74.in-addr.arpa. 86400 IN NS y.arin.net. 74.in-addr.arpa. 86400 IN NS x.arin.net. 74.in-addr.arpa. 86400 IN NS r.arin.net. 74.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net. 74.in-addr.arpa. 86400 IN NS z.arin.net. ;; Received 202 bytes from 2620:37:e000::53#53(a.in-addr-servers.arpa) in 79 ms 92.74.in-addr.arpa. 86400 IN NS dns103.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns105.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns101.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns104.comcast.net. 92.74.in-addr.arpa. 86400 IN NS dns102.comcast.net. ;; Received 170 bytes from 2001:500:127::30#53(y.arin.net) in 46 ms 10.206.92.74.in-addr.arpa. 3600 IN PTR 74-92-206-10-Albuquerque.hfc.comcastbusiness.net. ;; Received 116 bytes from 2001:558:100e:5:68:87:72:244#53(dns105.comcast.net) in 49 ms
Hey, look! there's a PTR record! Just... y'kno.. not for me. Why must Comcast torment me so?!
The bottom line (down here at the bottom of this post) is that things are broken. still. worse than they were when I started this.