Re: fwd: Re: [registrars] Re: panix.com hijacked
In message [EMAIL PROTECTED], william( at)elan.net writes: On Sun, 16 Jan 2005, Joe Maimon wrote: Thus justifying those who load their NS and corresponding NS's A records with nice long TTL Although this wasn't a problem in this case (hijacker did not appear to have been interested in controlling dns since it points to default domain registration and under construction page), but long TTL trick could be used by hijackers - i.e. he gets some very popular domain, changes dns to the one he controls and purposely sets long TTL. Now even if registrars are able to act quickly and change registration back, those who cached new dns data would keep it for quite long in their cache. Many versions of bind have a parameter that caps TTLs to some rational maximum value -- by default in bind9, 3 hours. Unfortunately, the documentation suggests that the purpose of the max-ncache-ttl parameter is to let you increase the cap, in order to improve performance and decrease network traffic. The suggestion that someone made the other day -- that the TTL on zones be ramped up gradually by the registries after creation or transfer -- is, I think, a good one. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: fwd: Re: [registrars] Re: panix.com hijacked
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], william( at)elan.net writes: On Sun, 16 Jan 2005, Joe Maimon wrote: Thus justifying those who load their NS and corresponding NS's A records with nice long TTL Although this wasn't a problem in this case (hijacker did not appear to have been interested in controlling dns since it points to default domain registration and under construction page), but long TTL trick could be used by hijackers - i.e. he gets some very popular domain, changes dns to the one he controls and purposely sets long TTL. Now even if registrars are able to act quickly and change registration back, those who cached new dns data would keep it for quite long in their cache. Many versions of bind have a parameter that caps TTLs to some rational maximum value -- by default in bind9, 3 hours. Unfortunately, the documentation suggests that the purpose of the max-ncache-ttl parameter is to let you increase the cap, in order to improve performance and decrease network traffic. The suggestion that someone made the other day -- that the TTL on zones be ramped up gradually by the registries after creation or transfer -- is, I think, a good one. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From bv9ARM *max-ncache-ttl* To reduce network traffic and increase performance the server stores negative answers. *max-ncache-ttl* is used to set a maximum retention time for these answers in the server in seconds. The default *max-ncache-ttl* is 10800 seconds (3 hours). *max-ncache-ttl* cannot exceed 7 days and will be silently truncated to 7 days if set to a greater value. *max-cache-ttl* *max-cache-ttl* sets the maximum time for which the server will cache ordinary (positive) answers. The default is one week (7 days). So loading TTL's to longer than 7 days will have diminishing returns. Is this really such a good thing? Joe
fwd: Re: [registrars] Re: panix.com hijacked
Oki all, Delivery of RC mail to me is fairly desultory. Apparently there is an earlier thread. Post-Rome the very purpose of the RC seems to me to be doubtful (advocacy for registrars other than NetSol+4), and post-Elana the process of the RC left me disinterested. I'm particularly enamored by Ross' notion of what is going on on NANOG. Cheers, Eric --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivery-Date: Sun Jan 16 11:14:04 2005 Return-Path: [EMAIL PROTECTED] Received: from greenriver.icann.org (greenriver.icann.org [192.0.35.121]) by nic-naa.net (8.13.1/8.13.1) with ESMTP id j0GBDxgx036293 for [EMAIL PROTECTED]; Sun, 16 Jan 2005 11:14:04 GMT (envelope-from [EMAIL PROTECTED]) Received: from greenriver.icann.org (greenriver [127.0.0.1]) by greenriver.icann.org (8.12.11/8.12.11) with ESMTP id j0GEx1Qg006202; Sun, 16 Jan 2005 06:59:01 -0800 Received: (from [EMAIL PROTECTED]) by greenriver.icann.org (8.12.11/8.12.11/Submit) id j0GEx0hJ006201; Sun, 16 Jan 2005 06:59:01 -0800 X-Authentication-Warning: greenriver.icann.org: majordomo set sender to [EMAIL PROTECTED] using -f Received: from pechora.icann.org (pechora.icann.org [192.0.34.35]) by greenriver.icann.org (8.12.11/8.12.11) with ESMTP id j0GEwxrw006198 for [EMAIL PROTECTED]; Sun, 16 Jan 2005 06:59:00 -0800 Received: from tomts16-srv.bellnexxia.net (tomts16-srv.bellnexxia.net [209.226.175.4]) by pechora.icann.org (8.11.6/8.11.6) with ESMTP id j0GEwBA16293 for [EMAIL PROTECTED]; Sun, 16 Jan 2005 06:58:11 -0800 Received: from [192.168.2.101] ([67.71.54.206]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id [EMAIL PROTECTED]; Sun, 16 Jan 2005 09:58:57 -0500 Message-ID: [EMAIL PROTECTED] Date: Sun, 16 Jan 2005 09:57:03 -0500 From: Ross Wm. Rader [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: Tucows Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Jeftovic [EMAIL PROTECTED] CC: Registrars Constituency [EMAIL PROTECTED] Subject: Re: [registrars] Re: panix.com hijacked References: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Precedence: bulk On 1/16/2005 12:29 AM Mark Jeftovic noted that: There's a thread on NANOG to the effect that panix.com has been hijacked from Dotster over to MelbourneIT and it has pretty well taken panix.com and its customers offline, see http://www.panix.net/ I don't see what you are looking at - .net and .com point to the same place with no indication of anything awry...of course, I'm late to the game and the DNS probably tells a different story... Looks like this may be among the first high-profile unauthorized transfer under the new transfer policy. Looks like a bunch of guys on the NANOG list engaging in a lot of conjecture without the benefit of a lot of facts. Maybe there needs to some sort of emergency reversion where at least the nameservers can be rolled back immediately while the contesting parties sort it out. Might be interesting - what criteria would trigger the process? - -- Regards, -rwr In the modern world the intelligence of public opinion is the one indispensable condition for social progress. - Charles W. Eliot (1834 - 1926) --- End of Forwarded Message
Re: fwd: Re: [registrars] Re: panix.com hijacked
Is there anything that us folks out in the peanut gallery can do to help, other than locally serving the panix.net zone for panix.com? -- -=[L]=-
Re: fwd: Re: [registrars] Re: panix.com hijacked
On 16.01 10:25, Lou Katz wrote: Is there anything that us folks out in the peanut gallery can do to help, other than locally serving the panix.net zone for panix.com? Avoid being caught by an IPR lawyer while helping; ;-) Then organise operators to insert operational clue into the various policy processes. Daniel
Re: fwd: Re: [registrars] Re: panix.com hijacked
Don't panic ? ;) Lou Katz wrote: Is there anything that us folks out in the peanut gallery can do to help, other than locally serving the panix.net zone for panix.com?
Re: fwd: Re: [registrars] Re: panix.com hijacked
On Sun, Jan 16, 2005 at 07:21:55PM +0100, Daniel Karrenberg wrote: On 16.01 12:46, William Allen Simpson wrote: --- Forwarded Message From: Ross Wm. Rader [EMAIL PROTECTED] I don't see what you are looking at - .net and .com point to the same place with no indication of anything awry...of course, I'm late to the game and the DNS probably tells a different story... This fellow is pretty confused, as from here (Michigan via Merit) the DNS has pointed to different places since yesterday. A quick survey of some caching servers in my neighborhood reveals that some of them return old/correct A RRs for panix.com at this time. presumably they have cached ns records from before the switch in the com tld zone. Following the DNS delegation chain from the root name servers provides new/hijacked answers at this time. So I assume some operators of caching servers now choose to provide data that is inconsistent with the authoritative data in the DNS tree. So depending on where you ask, your answer may vary. they're not choosing to do so, they're probably operating ~normally. try asking them for the ns records for panix.com. the age should give you an idea of how long ago they were fetched from *.gtld-servers.net. they probably got them before the switch, they'll time out soon enough, and then they'll restart from the wrong servers. -- |- CODE WARRIOR -| [EMAIL PROTECTED] * ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*! [EMAIL PROTECTED] * information is power -- share the wealth.
Re: fwd: Re: [registrars] Re: panix.com hijacked
On 16 Jan 2005 at 10:25, Lou Katz wrote: Is there anything that us folks out in the peanut gallery can do to help, other than locally serving the panix.net zone for panix.com? -- -=[L]=- actually this is amazingly helpful. in fact encouraging more ISPs to do the same thing is, IMHO, the best way to route around hierarchical problems like this. imagine . . . The Association of Trustworthy ISPs these ISPs watch out for each other. in the case of a member's domain being hijacked all other members serve the correct zone info. this provides for a decentralized solution to the problem. this association only admits members based on strict criterion and drops members immediately upon discovery of unethical behavior. as more ISPs join the association end users will look for the association's seal of approval when shopping for an ISP. peace
Re: fwd: Re: [registrars] Re: panix.com hijacked
Andrew Brown wrote: On Sun, Jan 16, 2005 at 07:21:55PM +0100, Daniel Karrenberg wrote: On 16.01 12:46, William Allen Simpson wrote: --- Forwarded Message From: Ross Wm. Rader [EMAIL PROTECTED] I don't see what you are looking at - .net and .com point to the same place with no indication of anything awry...of course, I'm late to the game and the DNS probably tells a different story... This fellow is pretty confused, as from here (Michigan via Merit) the DNS has pointed to different places since yesterday. A quick survey of some caching servers in my neighborhood reveals that some of them return old/correct A RRs for panix.com at this time. presumably they have cached ns records from before the switch in the com tld zone. Thus justifying those who load their NS and corresponding NS's A records with nice long TTL At least those whose caches' your still in will still talk to you after your registrar screws you. (OT Limiting named cache size could have an adverse effect for people hoping to cash into this inusurance. Shouldnt cache limiting kill low priority records such as A's which do not correspond to cached NS first )
Re: fwd: Re: [registrars] Re: panix.com hijacked
On Sun, 16 Jan 2005, Joe Maimon wrote: Thus justifying those who load their NS and corresponding NS's A records with nice long TTL Although this wasn't a problem in this case (hijacker did not appear to have been interested in controlling dns since it points to default domain registration and under construction page), but long TTL trick could be used by hijackers - i.e. he gets some very popular domain, changes dns to the one he controls and purposely sets long TTL. Now even if registrars are able to act quickly and change registration back, those who cached new dns data would keep it for quite long in their cache. P.S. Just in case I chose not to send this info until panix.com had been restored, but we really do need to deal with how it occurred in the first place - even short term damage is bad so we need to have policies at ICANN that do no allow unauthorized transfers or else all domains can be LOCKED by default by registrars which effectively does the same. -- William Leibzon Elan Networks [EMAIL PROTECTED]
