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: owner-registrars@gnso.icann.org Delivery-Date: Sun Jan 16 11:14:04 2005 Return-Path: <owner-registrars@gnso.icann.org> 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 <brunner@nic-naa.net>; Sun, 16 Jan 2005 11:14:04 GMT (envelope-from owner-registrars@gnso.icann.org) 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 majordomo@localhost) 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 owner-registrars@gnso.icann.org 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 <registrars@greenriver.icann.org>; 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 <registrars@dnso.org>; 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 <20050116145857.SKGA1836.tomts16-srv.bellnexxia.net@[192.168.2.101]>; Sun, 16 Jan 2005 09:58:57 -0500 Message-ID: <41EA80BF.7020608@tucows.com> Date: Sun, 16 Jan 2005 09:57:03 -0500 From: "Ross Wm. Rader" <ross@tucows.com> Reply-To: ross@tucows.com Organization: Tucows Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Jeftovic <markjr@easydns.com> CC: Registrars Constituency <registrars@dnso.org> Subject: Re: [registrars] Re: panix.com hijacked References: <Pine.LNX.4.58L0.0501160024320.11253@c3po.easydns.com> In-Reply-To: <Pine.LNX.4.58L0.0501160024320.11253@c3po.easydns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-registrars@gnso.icann.org 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
Eric Brunner-Williams in Portland Maine wrote:
... I'm particularly enamored by Ross' notion of what is going on on NANOG.
------- Forwarded Message
From: "Ross Wm. Rader" <ross@tucows.com>
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.
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.
Ah yes, those pesky facts. Hard to get many facts without cooperation of the offending parties, now isn't it? All we have to go on are the actual DNS and whois responses returned on the 'net. Facts enough for most of us. Maybe the only facts that matter operationally, as a matter of fact. Since he somehow missed the fact that the DNS changed (what was *he* looking at), upon what did he base his opinion?
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?
Unauthorized change in the DNS asserted by any previous registrant. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On 16.01 12:46, William Allen Simpson wrote:
------- Forwarded Message
From: "Ross Wm. Rader" <ross@tucows.com>
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. 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. Daniel
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]=-
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
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
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" <ross@tucows.com>
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" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" werdna@squooshy.com * "information is power -- share the wealth."
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" <ross@tucows.com>
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.... )
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 william@elan.net
In message <Pine.LNX.4.44.0501161225210.11207-100000@sokol.elan.net>, "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
On 17 Jan 2005, at 13:08, Steven M. Bellovin wrote:
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.
Records in the control of the registry are the NS records in the parent zone (the "com" zone in this case). Those are non-authoritative and are going to get replaced in caches with data from the authority servers for the delegated zones (ns[12].access.net, in this case), once those servers are reached. So the TTLs of records in the registry-operated zones will likely have no impact on how long NS records for delegated zones remain in caches. If panix (or anybody else) wants to increase the time that their NS records stay in caches, the way to do it is to increase the TTLs on the authoritative NS records in their own zones. For panix.com, these appear to be set to 72 hours (the non-authoritative NS records for PANIX.COM in the COM zone have 48-hour TTLs). I will now sit back wait for Mark Andrews to appear and flame me to death for my inadequate understanding of the DNS. This is, of course, a subtle ploy to help reduce my Ontario winter heating costs, and to avoid having to spend the rest of the afternoon chipping ice off the driveway with a shovel. Joe
At 13:54 -0500 1/17/05, Joe Abley wrote:
So the TTLs of records in the registry-operated zones will likely have no impact on how long NS records for delegated zones remain in caches.
If panix (or anybody else) wants to increase the time that their NS records stay in caches, the way to do it is to increase the TTLs on the authoritative NS records in their own zones. For panix.com, these appear to be set to 72 hours (the non-authoritative NS records for PANIX.COM in the COM zone have 48-hour TTLs).
That's provided that the panix.com authoritative NS's are seen in the cache. Not all name servers return the authoritative NS's in an answer. (BIND has an option 'minimal-responses yes_or_no;' that control this. The default is no, but I know of one "yes" user.) The registrant's copy of the NS set is more credible (RFC 2181 speak) than the registry's copy, so if a cache sees both, the cache tosses the registry copy. But there's no guarantee that the cache will see both. Usually it does though. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield
Steven M. Bellovin wrote:
In message <Pine.LNX.4.44.0501161225210.11207-100000@sokol.elan.net>, "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
participants (12)
-
Andrew Brown -
Daniel Karrenberg -
Edward Lewis -
Eric Brunner-Williams in Portland Maine -
gnulinuxï¼ pacinfo.com -
Joe Abley -
Joe Maimon -
Lou Katz -
Richard Irving -
Steven M. Bellovin -
William Allen Simpson -
william(at)elan.net