- Test - lists.nanog.org

NANOG via RSS
by Mike Callahan 19 Jan '05

19 Jan '05

By any chance is this list available via xml/rss? Thanks, Mike

9 11

RE: NANOG via RSS
by Hannigan, Martin 19 Jan '05

19 Jan '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Paul Vixie > Sent: Wednesday, January 19, 2005 11:59 AM > To: nanog(a)merit.edu > Subject: Re: NANOG via RSS > > > > rs(a)seastrom.com (Robert E.Seastrom) writes: > > > > By any chance is this list available via xml/rss? > > ... > > Due to different ways of looking at data than one would > usually think > > of when designing a mail or usenet reader, all RSS readers of my > > admittedly fairly narrow acquaintance are lacking in one critical > > (imnsho) feature for reading NANOG-L: "kill thread". > > we gateway nanog@ (it's not called NANOG-L, really, plz stop > saying that) > into a local usenet newsgroup here. the netnews feature i > use most often > isn't actually "kill by thread", but rather "kill by author". i can't > imagine how any of you read this forum using a normal e-mail tool. Merit could treat the mailing list as an asset and not allow redistribution and instead offer multiple formats for readers to "peruse" or "react in near real time". RSS, NNTP, and SMTP are all options in my mind. It's about choices. More is better. -M<

1 0

209.225.34.161 (vsc.gsa.gov)
by Richard J. Sears 19 Jan '05

19 Jan '05

Can someone from this network contact me offlist - we are having routing issues with your network. Thanks ****************************************** Richard J. Sears Vice President American Internet Services ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

1 0

NYTimes: Purloined Domain Name Is an Unsolved Mystery
by Hank Nussbacher 19 Jan '05

19 Jan '05

http://www.nytimes.com/2005/01/18/technology/18domain.html -Hank

6 6

Gtld transfer process
by Bruce Tonkin 19 Jan '05

19 Jan '05

Hello All, Given the recent panix.com hijacking, I will give an outline of the current ICANN transfers process for gtlds. In the case of panix.com, evidence so far indicates that a third party that holds an account with a reseller of Melbourne IT, fraudulently initiated the transfer. The third party appears to have used stolen credit cards to establish this account and pay for the transfer. That reseller is analysing its logs and cooperating with law enforcement. There was an error in the checking process prior to initiating the transfer, and thus the transfer should never have been initiated. The loophole that led to this error has been closed. The transfer process has several checks and balances that are described below. It seems that in this case none of these worked. I can only comment on those from our end. Note also that panix.com was held in the .com registry, that does not use the new EPP protocol which incorporates the facility to store a separate password (called auth_info) for each domain name that must be checked before completing a transfer. Transfers process ================= (see http://www.icann.org/transfers/policy-12jul04.htm for full details) (1) A person initiates a transfer for a domain name via a reseller or registrar (1a) For registries (e.g org, biz, info, name) that use the EPP protocol, the person also needs a password that is held in the registry for each domain name (called auth_info in EPP protocol) (2) The gaining registrar is responsible for obtaining approval from the registrant (using the contact details available in the WHOIS of the losing registrar) using a standardised form (http://www.icann.org/transfers/foa-auth-12jul04.htm) In some cases registrars delegate the obtaining of the approval from a reseller that has direct contact with the registrant. A gaining registrar is not permitted by the policy to initiate a transfer without approval from the registrant. (3) The registrar initiates the transfer. (4) The registry checks to see if the name is on Registrar-LOCK, if so, the transfer request is rejected. Registrants may choose to put domain names on registrar-lock. Many registrars now put names on lock by default, and give the registrant the opportunity to remove a lock prior to transfer. (4a) For registries (e.g org, biz, info, name) that use the EPP protocol, the registry checks the auth_info supplied by the gaining registrar against the record in the registry. If there is no match, the transfer request is rejected. (5) The registry will send a message to the losing registrar confirming that a transfer has been initiated. (6) [OPTIONAL] A losing registrar may send a standard confirmation message (http://www.icann.org/transfers/foa-conf-12jul04.htm) to the registrant. A registrant may cancel a transfer at this point. A registrant may also immediately confirm a transfer at this point and the transfer will be immediately completed. (7) If the registry receives no response from the losing registrar after a 5 day period, the transfer will be completed. (8) A registrant may not further transfer a name for a period of 60 days (apart from back to the original registrar). (9) If the losing registrar believes that a transfer was unauthorised, the losing registrar may contact the gaining registrar for a copy of the authorisation in step 2 to arrange for the transfer to be reversed. (10) If the registrars cannot resolve a dispute, the losing registrar may initiate a dispute process with the registry operator. (11) If the registry operator cannot resolve a dispute, the losing registrar may initiate a dispute process with an external dispute resolution provider (http://www.icann.org/dndr/tdrp/approved-providers.htm) In the case of panix.com, the step (2) failed at the gaining registrar. I can't comment on steps taken by the losing registrar. The principle of the process, is that a registrant can move to another domain name provider (registrar or reseller) at any time, and can initiate a transfer from the new provider. This relies on the new provider authenticating the request. Losing registrars can incorporate registrar lock and transfer confirmation messages to minimise the risk in this process. The integrity of the process is greatly improved through the use of the auth_info password in the EPP protocol. This has been operating effectively in .org, .info., .biz and .name. The alternative to the process could be for the losing registrar to authenticate and initiate a transfer away. This may be more secure, but has a downside in that a losing registrar has an incentive to make this process as difficult and slow as possible. The current transfers policy was a result of over 2 years of work, but can always be improved. Thus ICANN is currently conducting a review of the policy http://www.icann.org/announcements/announcement-12jan05.htm. My personal view is that the current transfers policy WITH the use of auth_info and WITH the use of registrar-LOCK is a reasonable balance between security and allowing registrants to easily move their name. Areas for further improvement include having an expedited process for managing a fraudulent transfer - including the ability to quickly revert back to the previous DNS information while a dispute is investigated, and having mechanisms to ensure that 24/7 emergency contacts are available for all registrars at the registry. I am interested to hear what members of the NANOG list believe would be a better transfers process. Regards, Bruce Tonkin

10 11

Re: EPP minutia (was: Re: Gtld transfer process)
by George William Herbert 19 Jan '05

19 Jan '05

>I want a "transfer process" that is inherently difficult, if not >broken, for domain names that are business assets. I don't care about >"competition" between registrars, or how much I get soaked for by the >registrar and registry, or how evil and/or retarded one or both are. The problem that got us here was that registrars have historically been not flexible enough at releasing domains when the owners *did* want to transfer them. What you are saying, is that you want to have either a level of service at registrars, or a new registrar with the additional level of service, that instead of being easy to deal with in moves, is designed to maximally ensure safe handling of your important corporate identity. I think this is a clear and wonderful business opportunity. Just expect to pay more for it... -george william herbert gherbert(a)retro.com

3 2

Was panix.com in registrar-lock?
by Richard Parker 19 Jan '05

19 Jan '05

Does anyone know if the panix.com domain did, in fact, have an RRP status of registrar-lock in the .com registry sometime before it was hijacked? According to a couple of articles Panix officials insist that the panix.com domain had been registrar locked while George DeCarlo, vice president of marketing at Dotster (Panix's registrar), is reported saying that Panix did not sign onto Dotster's domain-locking service. If we ignore the serious issue of potential notification failures and look at just the registrar-lock issue, there are several possible scenarios: 1) Panix never requested that the panix.com domain be locked. 2) Panix requested the lock, but their registrar did not pass this request to the .com registry. 3) Panix's registrar requested the lock, but the .com registry failed to set the lock status. 4) The registrar-lock status was set at the registry, but it was fraudulently cleared prior to the domain transfer. 5) The registrar-lock status was set at the registry, but the domain was transferred despite the lock. Did I miss a scenario? I'd like to know which scenario occurred in the panix.com hijack, hence my interest in whether the .com registry was reporting the status of panix.com as registrar-lock prior to the hijack. -Richard

3 3

RE: Gtld transfer process
by Bruce Tonkin 19 Jan '05

19 Jan '05

Hello William, Thanks for your suggestions. Comments below. > > I would propose the following: > > 1. Keep existing model but make it "SHOULD" for old registrar > to inform > of upcoming transfer (I still don't understand how that failed in > panix.com case BTW, because I'm pretty certain dotster does it, the > only thing I can think of is that they did but answer was > lost among > all the spam that hostmaster account received). Sounds reasonable. > > 2. Allow for fast way to reverse the domain transfer for old register. > I'd propose the following: > a. Old registrar can use special registry function to request > reversal within 5 days of the transfer and that is immediatly > granted (no questions asked at that time) with > immediate restoration > of old NS servers Might be better to simply revert the NS records at the request of the original registrar, and then place the name on registry lock until the dispute is resolved. Note for URDP disputes a name is typically locked by a registrar (although the current NS record state is retained). Most of the other steps regarding provision of evidence and full-rollback to the original registrar are covered under the existing transfer dispute policies. The detailed process is documented here: http://www.icann.org/transfers/dispute-policy-12jul04.htm Regards, Bruce

1 0

RE: EPP minutia (was: Re: Gtld transfer process)
by Bruce Tonkin 19 Jan '05

19 Jan '05

Hello Eric, Thanks for your descriptions from an operator and web-hosting company perspective. Essentially different customers have different needs. Some that value price higher than reliability/security are likely to want to easily move names around depending on renewal prices and the prices of other services. Others value reliability/security very highly, and prefer to stay with one reliable provider, and will pay a premium for that provider to put in place strict change management procedures. In terms of the second category many registrars (including Melbourne IT) offer services tailored to the corporate market that incorporate change management processes, often with dedicated staff that are trained in such procedures. The transfers policy therefore needs to be able to support both types of registrant, and in particular allows the registrant to control the choice of processes. In the past some registrars have imposed their own strict processes (for example requiring a judge to approve any changes of registrar) that are not in accordance with the wishes of the registrant. Often these processes for registrar change are not in proportion to the processes for change of delegation etc. Generally a corporate wanting high security/stability will want strict change management across all processes, rather than a registrar accepting a delegation change over the phone without authentication, but requiring a judge to approve a transfer. A registrar wishing to offer a customer a high level of protection must be able to set a flag in the registry that prevents a transfer. This is the Registrar-LOCK function. Now I agree this still requires the registrar to have strict process control on how this flag can be set/cleared. The policy requires that a registrar provide a mechanism for a registrant to unlock a name that is consistent with other processes - e.g delegation for that name/registrant. Regards, Bruce

1 0

Re: The entire mechanism is Wrong!
by Eric Brunner-Williams in Portland Maine 19 Jan '05

19 Jan '05

Gentlemen and Ladies, I concur with the view expressed by Bob Fox (IANA-134), that the "current method only favours Verisign and crooks." The hijacking of panix.com, and the post-hijacking response of VGRS, which could unilaterally act, but choses not to, for its own reasons, and MelburneIT, which could unilaterally act, but choses to not act until 72 hours after being noticed, if then, is a counter-example to any claim that the current method has any rational application to domain names that are "mission critical", that is, used for something other than proping up some shoddy trademark claim by some party that doesn't even use the dns for core operational practice. It doesn't reflect very well on the registries and registrars either. Eric Brunner-Williams CTO Wampumpeag, LLC Operator, USA Webhost, IANA-439, CORE-124

17 18