[dns-operations] Enom's name server broken?

Fan Of Network fanofnetwork at gmail.com
Mon Jan 14 17:53:18 UTC 2013


We use Enom as a registrar and provider of name server for a few of our
domains. Recently we decided to switch name servers provider to a different
company. One could say that it is easy. Yes, but with Enom name server is
seems to be a problem. Why?

Let's assume that we query for a host record in xclusivmedia.com (one of
our domains still registered at Enom). Our resolver will cache (depending
if it is parent-centric on child-centric) NS records from .com
authoritative name server (TTL of 2 days) or Enom's name server (TTL of
1h). Then, we change list of authoritative name server at Enom (here as
registrar) and within minutes .com authoritative servers will be updated.
However, our resolver will keep asking Enom's name server for our domain.
What Enom's server will reply? Let's see:

dig test1.xclusivmedia.com @dns1.name-services.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> test1.xclusivmedia.com @
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43753
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0

;test1.xclusivmedia.com.                IN      A

test1.xclusivmedia.com. 1800    IN      A
test1.xclusivmedia.com. 1800    IN      TXT     "v=spf1 -all"
test1.xclusivmedia.com. 3600    IN      NS      ns1.p28.dynect.net.
test1.xclusivmedia.com. 3600    IN      NS      ns2.p28.dynect.net.
test1.xclusivmedia.com. 3600    IN      NS      ns3.p28.dynect.net.
test1.xclusivmedia.com. 3600    IN      NS      ns4.p28.dynect.net.

;; Query time: 166 msec
;; WHEN: Mon Jan 14 18:44:41 2013
;; MSG SIZE  rcvd: 166

Yes, this the whole zone dumped into authority section...Did you see
something like that before? Any idea how to work it around?

We tried Enom's support, but they don't see the problem in this and they
are not willing to escalate.

Is anyone from Enom reading this? If so, could you please contact me off
the list?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130114/32f30283/attachment.html>

More information about the dns-operations mailing list