[dns-operations] DNS continuity during registrar transfers (was Re: Enom's name server broken?)

Tue Jan 15 14:41:35 UTC 2013

On 13-01-15 8:46 AM, Mark Andrews wrote:
> 
> In message <D1AC4482BED7C04DAC43491E9A9DBEC301399413 at bkexchmbx02.blacknight.loc
> al>, "Michele Neylon :: Blacknight" writes:
>> Surely that's an issue with your resolver and not with enom? Or am I 
>> misunderstanding the question .. 
> 
> No.  Caches work like that.  There will be a period where the losing
> servers continue to get queries after the delegation has been changed.
> 

I think he did misunderstand the question (as per Stefan Schmidt's
response).

But in reply to what you said below (sorry for the thread drift):

> For clean transfers of zones from one provider to the next the
> losing provide should slave the zones from the new provider.  This
> ensures that caches only see current content regardless of whether
> they are talking to the new or old servers.
>

I think this almost never happens in the real world when domains move
from one set of auth nameservers to another. What the losing servers can
do is continue to serve the data they have, especially in the case of a
registrar transfer because in a lot of cases the zone data will be the
same for an overlapping period of time.

But...

> I expect losing providers to do the right thing while the zone's
> delegation is in a state of flux. 

Most do, some don't *cough* Netsol *cough* Godaddy *cough* Some will
preemptively drop all DNS as soon as they see that a domain is
transferring out effectively knocking a domain offline for a few hours
(or however long it takes for the operators to update their zone
delegation).

I personally think they do it on purpose because it makes the gaining
registrar look like a schmuck.

- mark

>> (or maybe I need more coffee)
>>
>> Or are you expecting eNom to purge DNS records for domains for which they 
>> aren't currently authoritative?
> 
> I expect losing providers to do the right thing while the zone's
> delegation is in a state of flux.  The answer below is self
> inconsistent.  It says there are no address records but stuffs a
> address record in the authority section along with a TXT record.
> The servers are clearly *broken*.
> 
> Now one can argue about what "the right thing" is.  Old zone contents,
> new zone contents or return responses as if the zone is removed.
> This answer matches none of those.  No instruction, in any RFC,
> results in that response.
> 
> Mark
> 
>> On 14 Jan 2013, at 17:53, Fan Of Network <fanofnetwork at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> 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 @dns1.name-services.com
>>> ;; global options:  printcmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43753
>>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;test1.xclusivmedia.com.                IN      A
>>>
>>> ;; AUTHORITY SECTION:
>>> test1.xclusivmedia.com. 1800    IN      A       91.102.91.61
>>> 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
>>> ;; SERVER: 98.124.192.1#53(98.124.192.1)
>>> ;; 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? 
>>>
>>> Thanks.
>>> _______________________________________________
>>> dns-operations mailing list
>>> dns-operations at lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>> dns-jobs mailing list
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>>
>> Mr Michele Neylon
>> Blacknight Solutions 
>> Hosting & Domains
>> ICANN Accredited Registrar
>> http://www.blacknight.co
>> http://blog.blacknight.com/
>> Intl. +353 (0) 59  9183072
>> US: 213-233-1612 
>> Locall: 1850 929 929
>> Direct Dial: +353 (0)59 9183090
>> Facebook: http://fb.me/blacknight
>> Twitter: http://twitter.com/mneylon
>> -------------------------------
>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business 
>> Park,Sleaty
>> Road,Graiguecullen,Carlow,Ireland  Company No.: 370845
>>
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-jobs mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 

-- 
Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
Company Website: http://easydns.com
Read My Blog:    http://markable.com
+1-416-535-8672 ext 225