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
Re: [registrars] Re: panix.com hijacked
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
Re: [registrars] Re: panix.com hijacked
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
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
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]
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 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
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
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 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
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 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. 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
Re: fwd: Re: [registrars] Re: panix.com hijacked
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" <[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. 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
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
