[Chapter-delegates] PIR and wikileaks.ORG

[Christian de Larrinaga]

They have not updated these records. It is not clear why not.

- Does wikileaks still have access to their Dynadot account so they can update them?
- Perhaps there is no point until they can find a DNS infrastructure that will agree to resolve for them. 


Christian


On 4 Dec 2010, at 19:33, Jon Zittrain wrote:

> Thanks, Peter, Marcin and Desiree -- from the sound of it, then, this has absolutely nothing to do with ICANN, PIR, Afilias, or Dynadot.  Wikileaks elected to use a nameserver that isn't working (at least for them) anymore; they can choose a new one whenever they want.  It has nothing to do with the bottlenecks found within the canonical DNS system.  Indeed, the DNS system is designed to let them fix problems like this as it comes up, and I gather there's no reason for EveryDNS to have a contract with anyone in the ICANN hierarchy and below.  It's just pointed to the way that a site at an IP address is pointed to by a domain name.  If a Web server at www.site.org goes down, and thus we type www.site.org and get nothing back, we don't blame ICANN and friends for the problem -- they have nothing to do with it.  ...JZ
> 
> At GMT-4 11:13 AM 12/4/2010, Peter Koch wrote:
>> On Sat, Dec 04, 2010 at 01:58:48AM -0500, Jon Zittrain wrote:
>>> A quick technical question: isn't (wasn't?) EveryDNS just the
>>> registrar, not the registry?  At the end of the day it's the registry
>>> -- Afilias? -- that operationally resolves a .org name, not the
>>> registrar.  The registrar just is the party authorized/expected to
>>> make any changes in the registry entries for the names it
>>> registers.  So how would a DDOS against the DNS resolution service --
>>> the reason cited by EveryDNS for its ... deregistering? changing the
>>> pointed-to site to null? ... involve EveryDNS and its customers?  ...JZ
>> 
>> there are five or more parties involved:
>> 
>> 1) the Registry - PIR, or Afilias for the operational part
>> There is no indication that anything in the registry recently changed
>> w.r.t. the domain wikileaks.org
>> 
>>      Domain ID:D130035267-LROR
>>      Domain Name:WIKILEAKS.ORG
>>      Created On:04-Oct-2006 05:54:19 UTC
>>      Last Updated On:26-Aug-2010 22:38:42 UTC
>>      Expiration Date:04-Oct-2018 05:54:19 UTC
>>      Sponsoring Registrar:Dynadot, LLC (R1266-LROR)
>>      Status:CLIENT TRANSFER PROHIBITED
>>      Registrant ID:CP-13000
>>      Registrant Name:John Shipton c/o Dynadot Privacy
>>      Registrant Street1:PO Box 701
>>      ...
>>      Name Server:NS1.EVERYDNS.NET
>>      Name Server:NS2.EVERYDNS.NET
>>      Name Server:NS3.EVERYDNS.NET
>>      Name Server:NS4.EVERYDNS.NET
>> 
>> 
>> Indeed the Registry (or their DNS service provider, respectively)
>> "resolves" the name, but only by pointing to the nameservers in
>> charge (the four named above).
>> 
>> 2) the Registrar - Dynadot
>> Is the one in charge of maintaining the domain data within the
>> registry. In this case, the registrar ofers a "privacy service",
>> see <http://www.dynadot.com/domain/privacy.html>
>> 
>> 3) the Registrant - Wikileaks
>> Due to the privacy service used, little is publicly know, but then
>> this entity is "well known".
>> 
>> 4) The Name Service Provider - EveryDNS
>> EveryDNS/DynDNS operates the name server infrastructure; the delegation
>> as shown in the whois record above goes to four of EverDNS's name servers.
>> A (successful) attack on a name server will affect all customers served
>> by that name server (mind the singular).  The four servers mentioned
>> above will not respond to any queries for names within the wikileaks.org
>> domain.  That is, they will treat this like any other query for zones
>> (domains) they are not tasked to serve.  This is very similar to what
>> is called a lame delegation, except that a more common form is to give
>> a REFUSED or a similar response instead of letting the querying resolver
>> time out.
>> 
>> 5) The Web Hosting Provider(s)
>> This is where can be found what this is all about.
>> 
>> I haven't seen any indication that entities (1) or (2) did change anything.
>> However, entity (4) obviously does not or no longer serve the domain
>> wikileaks.org.
>> 
>> Conclusions left to the reader.
>> 
>> -Peter, ISOC.DE
> 
> _______________________________________________
> Chapter-delegates mailing list
> Chapter-delegates at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/chapter-delegates