Fixing .com DNS glue records - who to contact?

Mailman List Mirror (Read Only)
1

A glue record for a .com domain (nextbus.com) is wrong, and I'm running into a brick wall trying to get it fixed.
Do I need to switch to a more clueful registrar than GoDaddy**? Contact Network Solutions?
Have I screwed up the domain's bind config? Everything looks right when I _dig_ around the authoritative NS*...
I futzed with the record (deleted and re-added ns.nextbus.com as an authoritative NS (nameserver(s))), and the glue became correct for several days (dnsreport.com even reported all was well) AND THEN WENT BACK TO BEING BROKEN AGAIN.

http://www.dnsreport.com/tools/dnsreport.ch?domain=nextbus.com
currently says: ns.nextbus.com.:
   Parent server (f.gtld-servers.net) says A record is 64.164.28.194, but
   authoritative DNS server (209.204.159.20) says it is 64.142.39.200
ns.nextbus.com.:
   Parent server (f.gtld-servers.net) says A record is 64.164.28.194, but
   authoritative DNS server (64.142.88.72) says it is 64.142.39.200
ns.nextbus.com.:
   Parent server (f.gtld-servers.net) says A record is 64.164.28.194, but
   authoritative DNS server (69.9.186.104) says it is 64.142.39.200

ALSO: Since 3 of the 4 NS don't have the wrong glue, and 4 of the 4 NS are answering appropriately, and there's no NS at the IP indicated by the wrong glue, this problem shouldn't have any user-visible impact, right? I think there are many ISPs (I've found Earthlink and SBC to be guilty of this in the past) who have broken their resolver configurations so that they sometimes don't work if one, but not all of a domain's NS don't answer. Anyway, I'm getting complaints (from a gov't agency) of mail bouncing with '450 Client host rejected: cannot find your hostname' errors.

TIA. This is my first post here; please be gentle.

Oh, and if I do need a new registrar, I'm taking suggestions here or here:
http://wiki.fastmail.fm/index.php/GoodRegistrarSearch

*dig nextbus.com MX
dig nextbus.com MX @ns.nextbus.com.
dig nextbus.com MX @a.auth-ns.sonic.net.
dig nextbus.com MX @b.auth-ns.sonic.net.
dig nextbus.com MX @c.auth-ns.sonic.net.

**edited to conform to normal attribution. WARNING: C&C.
nextbus.com [Incident: 050729-000962]]
Me:
> Go Daddy:
>> Me:

Please fix this Mismatched glue problem for domain nextbus.com:

ERROR: Your nameservers report glue that is different from what the
parent servers report. This will cause DNS servers to get confused; some
may go to the IP provided by the parent servers, while others may get to
the ones provided by your authoritative DNS servers. Problem record(s) are:

ns.nextbus.com.:
Parent server (m.gtld-servers.net) says A record is 64.164.28.194, but
authoritative DNS server (208.201.224.11) says it is 64.142.39.200
ns.nextbus.com.:
Parent server (m.gtld-servers.net) says A record is 64.164.28.194, but
authoritative DNS server (208.201.224.33) says it is 64.142.39.200

The glue in the parent servers is wrong.

Thank you for contacting customer support.

I have tested your site and everything is resolving properly. This error message you are getting is not on our end.

Please let us know if we can help you in any other way.

<Advertisement for GoDaddy services removed>

Sincerely,

Beth P.
GoDaddy.com
Customer Service Representative

Please have this issue reviewed by someone technical - someone who knows
what DNS glue is, so they can understand the error in my initial email.
See
http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm?glue.record.htm

or http://www.centralnic.com/support/glossary

http://www.dnsreport.com/tools/dnsreport.ch?domain=nextbus.com
shows quite clearly IN RED that there is something seriously wrong.
The problem exists. It is NOT my imagination.
Just because you're able to bring up www.nextbus.com does NOT mean
there's nothing wrong.

Thank you for contacting customer support. I have looked into this situation and found that the domain name in question is not hosted with us. This being the case you may wish to speak with your hosting provider regarding the "glue" situation.

Please let us know if we can help you in any other way.

<Advertisement for GoDaddy services removed>
<https://www.godaddy.com/gdshop/hosting/landing.asp?isc=webxpf>
Sincerely,

Kade P.

2

A glue record for a .com domain (nextbus.com) is wrong, and I'm running
into a brick wall trying to get it fixed.

The problem is that the A and PTR records for your domain servers don't
match up. See the "Mismatched glue" section of your dnsreport.

I've got the same issue with some domains hosted over at Register.com's
GPN (Global Partner Network) division. GPN outsources DNS to eNom
(which is an excellent thing), but the default GPN DNS settings use
dnsXX.gpn.register.com which has a PTR to dns1.name-services.com. I
*think* that this is OK per RFC, would really like to hear some expert
opinions on this however.

-Jim P.

3

> A glue record for a .com domain (nextbus.com) is wrong, and I'm running
> into a brick wall trying to get it fixed.

The problem is that the A and PTR records for your domain servers don't
match up. See the "Mismatched glue" section of your dnsreport.

Err, scratch that. I misread your post.

$host 64.164.28.194
  194.28.164.64.in-addr.arpa is an alias for \
     194.192.28.164.64.in-addr.arpa.
  194.192.28.164.64.in-addr.arpa domain name pointer ns.nextbus.com.

Is "194.192.28.164.64.in-addr.arpa" valid?

I've got the same issue with some domains hosted over at Register.com's
GPN (Global Partner Network) division. GPN outsources DNS to eNom
(which is an excellent thing), but the default GPN DNS settings use
dnsXX.gpn.register.com which has a PTR to dns1.name-services.com. I
*think* that this is OK per RFC, would really like to hear some expert
opinions on this however.

I still would like to understand this validity of this however. ;-_

-Jim P.

4

A glue record for a .com domain (nextbus.com) is wrong, and I'm running into a brick wall trying to get it fixed.
Do I need to switch to a more clueful registrar than GoDaddy**? Contact Network Solutions?
Have I screwed up the domain's bind config? Everything looks right when I _dig_ around the authoritative NS*..
I futzed with the record (deleted and re-added ns.nextbus.com as an authoritative NS (nameserver(s))), and the glue became correct for several days (dnsreport.com even reported all was well) AND THEN WENT BACK TO BEING BROKEN AGAIN.

$ dig nextbus.com @ns.nextbus.com
;; AUTHORITY SECTION:
nextbus.com. 14400 IN NS b.auth-ns.sonic.net.
nextbus.com. 14400 IN NS c.auth-ns.sonic.net.
nextbus.com. 14400 IN NS ns.nextbus.com.
nextbus.com. 14400 IN NS a.auth-ns.sonic.net.

;; ADDITIONAL SECTION:
a.auth-ns.sonic.net. 38814 IN A 209.204.159.20
b.auth-ns.sonic.net. 38814 IN A 64.142.88.72
c.auth-ns.sonic.net. 38814 IN A 69.9.186.104
ns.nextbus.com. 14400 IN A 64.142.39.200
             ^
             from your dns server

$ dig +norecurse ns.nextbus.com @a.gtld-servers.net

;; ANSWER SECTION:
ns.nextbus.com. 172800 IN A 64.164.28.194

;; AUTHORITY SECTION:
nextbus.com. 172800 IN NS a.auth-ns.sonic.net.
nextbus.com. 172800 IN NS b.auth-ns.sonic.net.
nextbus.com. 172800 IN NS c.auth-ns.sonic.net.
nextbus.com. 172800 IN NS ns.nextbus.com.

;; ADDITIONAL SECTION:
a.auth-ns.sonic.net. 172800 IN A 209.204.159.20
b.auth-ns.sonic.net. 172800 IN A 64.142.88.72
c.auth-ns.sonic.net. 172800 IN A 69.9.186.104
ns.nextbus.com. 172800 IN A 64.164.28.194
             ^
             from .COM glue record

$ dig +nssearch nextbus.com @a.gtld-servers.net
SOA ns.nextbus.com. noc.nextbus.com. 2005072902 28800 3600 604800 86400 from server a.auth-ns.sonic.net in 43 ms.
SOA ns.nextbus.com. noc.nextbus.com. 2005072902 28800 3600 604800 86400 from server b.auth-ns.sonic.net in 25 ms.
SOA ns.nextbus.com. noc.nextbus.com. 2005072902 28800 3600 604800 86400 from server ns.nextbus.com in 24 ms.
SOA ns.nextbus.com. noc.nextbus.com. 2005072902 28800 3600 604800 86400 from server c.auth-ns.sonic.net in 85 ms.

So the answer is that you need to make sure your own dns server "A"
record for "ns.nextbus.com" matches glue record entered with registrar.
As far as what is going to be used by global dns, it would be glue
record that you set with registrar (ok - its supposed to, but its
not always true depending how caching dns server is written).

BTW - when doing check make certain to use "+norecurse"

I have tested your site and everything is resolving properly. This error message you are getting is not on our end.

If the record you wanted for glue is 64.142.39.200 and godaddy did not
fix it, then I suggest you find more cluefull registrar support person.

Thank you for contacting customer support. I have looked into this situation and found that the domain name in question is not hosted with us. This being the case you may wish to speak with your hosting provider regarding the "glue" situation.

The above is a red flag that the godaddy's "customer service representative"
has no idea what "glue" means. Escalate to the real tech support.

5

Ok, I think the glue record will stay correct now. I finally got someone at GoDaddy ('Chad') who understood the problem and seems to have fixed it.

BTW: RP emailed me privately with info on how to change a domain's authoritative name servers using GoDaddy's interface. I don't know why; I know how to do this, and there's been nothing wrong with the domain's authoritative name servers, per se, but Thanks.
Also, MH from Verisign offered to take my call. Thanks for the offer. Thanks especially to William Leibzon, for giving just the right advice.
I still have no understanding of what was causing the glue in the gTLD server to switch back and forth between correct and incorrect IPs, but Chad assured me things would be OK now.

I'm tempted to try making one of the authoritative name servers for a toy domain www.<domain> to see what happens. Anyone tried it? I imagine this would result in slightly faster lookups, though the high TTL and propagation make it risky, and not appropriate for high availability sites. (I'm assuming the result would be that the query to the gTLD for the NS would also provide the answer for www, so no query to the domain's NS would be needed for the oh-so-common www lookup.)

6

I'm tempted to try making one of the authoritative name servers for a
toy domain www.<domain> to see what happens. Anyone tried it?

$ dnsqr ns abuse.net
2 abuse.net:
78 bytes, 1+2+0+0 records, response, noerror
query: 2 abuse.net
answer: abuse.net 251793 NS light.lightlink.com
answer: abuse.net 251793 NS www.abuse.net

I imagine this would result in slightly faster lookups, though the
high TTL and propagation make it risky, and not appropriate for high
availability sites.

Hasn't made much difference that I can see. I did it to avoid burning
another IP address from my /24.

R's,
John

7

Argh Argh Argh. We ran into that rather extensively and finally ended
up moving a bunch of domains that we run mail for to ultradns.

8

Should be -- this is standard practice for rDNS delegation when the rDNS
responsible entity is not using an even octet-bounded network (/8, /16, or
/24). In this case, it indicates a subnet of /27 or /26 (as the network
boundary *seems* to be .192, though that's just thanks to the naming
convention used by the upstream, and the customer in question has .200 as
well).