Quote:
Originally Posted by Tom
This should be fixed now, there may be a requirement for this to propagate through the internet (24 hrs)
|
Problem will still exist because of this new behavior from Verisign. The glue records for blackberryserver.com are busted. Actually, now that I look closer, the problem is about to get much much worse from the way it was fixed.
The authoritative servers for blackberryforums.com:
Code:
# whois blackberryforums.com | grep -A2 'Name Servers:'
Name Servers:
ns1.blackberrycenter.com
ns2.blackberrycenter.com
The NS records for blackberryforums.com, querying their authoritative servers directly so there are no ttl issues:
Code:
# dig NS blackberryforums.com @ns1.blackberrycenter.com
; <<>> DiG 9.5.0-P2 <<>> NS blackberryforums.com @ns1.blackberrycenter.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6758
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;blackberryforums.com. IN NS
;; ANSWER SECTION:
blackberryforums.com. 86400 IN NS dns1.blackberryserver.com.
blackberryforums.com. 86400 IN NS dns2.blackberryserver.com.
;; ADDITIONAL SECTION:
dns1.blackberryserver.com. 14400 IN A 74.86.254.232
dns2.blackberryserver.com. 14400 IN A 74.86.254.233
;; Query time: 55 msec
;; SERVER: 74.86.254.234#53(74.86.254.234)
;; WHEN: Mon Mar 8 10:49:35 2010
;; MSG SIZE rcvd: 125
The record looks good on the surface. They kept the dns[12].blackberryserver.com NS records and ditched the rest. But dig a little deeper.
Find the authoritative servers for blackberry
server.com because the names dns[12].blackberryserver.com need to be resolved to complete the original query of looking up names for blackberry
forums.com:
Code:
# whois blackberryserver.com | grep -A2 'Name Servers:'
Name Servers:
ns1.blackberryserver.com
ns2.blackberryserver.com
So, ns[12].blackberryserver.com are authoritative for blackberryserver.com Query the NS records for blackberryserver.com, again, directly from the authoritative server so there are no ttl issues:
Code:
# dig NS blackberryserver.com @ns1.blackberryserver.com
dig: couldn't get address for 'ns1.blackberryserver.com': not found
(insert sound of screeching halt here)
This is the new behavior described by the verisign change doc. While the name servers dns[12].blackberry
center.com are configured to provide A records for dns[12].blackberry
server.com, they are now irrelevant because the blackberrycenter.com servers are not authoritative for blackberryserver.com. So, where Verisign's root name servers for all of the .com namespace used to be helpful and just grab those glue records, it will not now promote those records to be authoritative.
Because the records for blackberryforums.com on dns[12].blackberrycenter.com now only contain NS records pointing to dns[12].blackberryserver.com, this problem is about to get much worse as soon as the TTL for all the glue records expire for blackberryforums.com.
So, the glue records for blackberryserver.com need to get fixed very soon, or the blackberryserver.com name servers need to be taken completely out of the mix.