- NANOG - lists.nanog.org

Re: Virus uptick?
by David Lesher 18 Sep '03

18 Sep '03

I overlooked the OBVIOUS reason that someone just mentioned: > There is a new worm: > http://www.f-secure.com/v-descs/swen.shtml Damn, we need a TV-Guide type page listing all the first run and rerun M$ viruses. It's just too hard to keep them all straight.. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Contact from Verio
by Joiner, Joshua 18 Sep '03

18 Sep '03

Someone from Verio please contact me off list. We are experiencing some routing issues through/to your network. Thanks, Josh

1 0

Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 18 Sep '03

18 Sep '03

actually, i had it convincingly argued to me today that wildcards in root or top level domains were likely to be security problems, and that domains like .museum were the exception rather than the rule, and that bind's configuration should permit a knob like "don't accept anything but delegations unless it's .museum or a non-root non-tld". i guess the ietf has a lot to think about now. re: > Date: Wed, 17 Sep 2003 09:58:40 -0500 > From: Jack Bates <jbates(a)brightok.net> > User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 > To: Paul Vixie <paul(a)vix.com> > Cc: nanog(a)merit.edu > Subject: Re: Root Server Operators (Re: What *are* they smoking?) > Sender: owner-nanog(a)merit.edu > > > Paul Vixie wrote: > > no. not just because that's not how our internal hashing works, but > > because "hosted" tld's like .museum have had wildcards from day 1 and > > the registrants there are perfectly comfortable with them. there's > > no one-policy-fits-all when it comes to tld's, so we would not want > > to offer a knob that tried to follow a single policy for all tld's. > > I agree Paul. This is a policy issue and not a technical issue. TLDs that > are sponsored or setup with a specific design sometimes do and should be > allowed to use the wildcard for the tld. The issue has become that net and > com are public trusts and changes were made to them without authorization > by the public and damage was caused as a result. > > Just as root server operators are subject to operating as IANA dictates, so > should Verisign be subject to operating as IAB and ICANN dictate. The > Internet as a whole depends on the predictability of TLDs. It is impossible > to maintain a security policy based on unpredictable information. > > I would recommend that the TLDs which do utilize wildcards setup or > restrict such use in a predictable manner. While historically it has not > been an issue, such as nonexistant .museum domains being forged in email > envelopes, such practices could be exploited at a later time. The ability > to recognize that a domain is not registered and should not be used is > paramount in basic forgery detection. > > One method that might be considered for recursive servers as well as > resolvers, is the ability to specify if a wildcard entry will be accepted > or not, perhaps at any level or just at the 2nd level. Cached records which > are wildcards could be marked as such so that subsequent queries could > specify desire of accepting or not accepting the wildcard entry. A web > browser, for example, which supports its own redirections for NXDOMAIN, > might wish to ignore the wildcard records, as would smtp servers. > > While I believe that net and com should never have wildcards, the ability > to detect, cache, and override wildcards for tld's such as museum when the > application requires it is paramount. I realize that the client software > can perform the queries and detection itself, but in many cases, there > wouldn't be an effecient way to cache the information without the resolver > and recursive cache being aware of the process and performing such > detection would require two queries versus one. > > > -Jack >

4 3

Sven-Haegar Koch: Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 18 Sep '03

18 Sep '03

forwarding as requested.

1 0

RE: Worst design decisions?
by Austad, Jay 18 Sep '03

18 Sep '03

Sun Ultra Enterprise 3500. Three power supplies for redundancy, only *one* power cord. You'd think that with something that originally cost 6 figures, that this would have been thought out a bit more. Oh, and 1U patch panels with only 12 ports in them annoy me. > -----Original Message----- > From: Matt [mailto:acheron@qwest.net] > Sent: Wednesday, September 17, 2003 5:43 PM > To: nanog(a)merit.edu > Subject: Worst design decisions? > > > > Hello all, > > Was doing some upgrades on a UBR7246 (to a VXR), and I got to > thinking > about short sighted design considerations. I was curious if > any of you > had some pet peeves from a design perspective to rant about. > I'll start > with a couple. > > 1) Why did Cisco design the I/O controller on the 7246 with screws in > the corner, which are very difficult to get at? And worse than that, > why did they not include a cheap handle on the blank in this slot? > > 2) Why did Cisco not include side handles on the 12000 > chassis? It's a > heavy chassis, and I can imagine how many techs have thrown out their > back moving that chassis around. > > I've got a couple others in my head from 3Com and a couple of others, > but I thought I'd get the ball rolling. So, what do you think? > >

1 0

Re: Worst design decisions?
by Vinny Abello 18 Sep '03

18 Sep '03

How about MB chipset fans which always seem to fail! I avoid any mobo with a chipset fan if possible. This is still commonplace and I still see them fail all the time. At 09:09 AM 9/18/2003, Ryan Dobrynski wrote: >I have beef with every chasis designer that has ever left a sharp edge >hidden deep inside thier "case of doom" just waiting to gash some poor IT >guy in a most unpleasent manor.. > >also ASUS who insists on putting thier onboard sound interface at the >BOTTOM of the MB when they know that the little cable you get with the >cdrom is half the length of the board. you end up with an analog audio >cable thats stretched tight and now in the way of all your PCI slots... >/rude > >Ryan Dobrynski >Hat-Swapping Gnome >Choice Communications > > >Like the ski resort of girls looking for husbands and husbands looking >for girls, the situation is not as symmetrical as it might seem. Vinny Abello Network Engineer Server Management vinny(a)tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.

1 0

Re: DNS anycast considered harmful (was: .ORG problems this evening)
by Todd Vierling 18 Sep '03

18 Sep '03

On Thu, 18 Sep 2003, Stephane Bortzmeyer wrote: : > There's an easy fix to that particular situation: Make the first (or first : > two) listed servers anycast, and the rest unicast. : : It would require a central management (or at least a central : oversight) of the root name servers and I do not believe there is one: : each root name server anycasts at will, without a leader saying ("A : and B will anycast, the others will stay unicast"). Well, that's something for the root server operators to think about and discuss amongst themselves. I know several of them are reading this list, and may be reading this thread. 8-) Still doesn't help .ORG, which is 100% anycast and thus has no DNS-based redundancy (see my experience elsewhere in this thread). -- -- Todd Vierling <tv(a)duh.org> <tv(a)pobox.com>

2 1

Fw: Re: ICANN - Formal Complaint re Verisign
by Jerry Eyers 18 Sep '03

18 Sep '03

An interesting thought... Jerry >Jerry, > >One question - if I previously typed in an URL that was incorrect and would get the usual response from my OWN system, there would be not a real lot of data sent/received to pay for that mistake. Now that Verisign is doing their current thing, there is a lot more data being paid by ISPs across the world that shouldnt HAVE to be paid for. > >So is anyone thinking of banding together the ISPs in on this formal complaint citing loss of income >from this? The bigger the ISP - eg AOL - the bigger the new cost for Verisign advertising, paid at the >ISP's expense because of all this. A group of ISPs all complaining should get some action you would >think. > >I am posting this to you as if you can use it, feel free to post it to Nanog where I have no posting rights. > >Regards, Greg. > >.

2 1

Re: DNS anycast considered harmful (was: .ORG problems this evening)
by Iljitsch van Beijnum 18 Sep '03

18 Sep '03

On donderdag, sep 18, 2003, at 14:08 Europe/Amsterdam, Stephane Bortzmeyer wrote: >> BGP is really bad at. DNS servers on the other hand track RTTs for >> query responses > BIND does it but what about Microsoft cache/forwarder? At RIPE 45 (you > were there), Was I??? > a talk by people at CAIDA showed that A.root-servers.net > received twice as much traffic as the other root name servers since it > is just the first one listed... That's not good. But not an excuse. If MS is unable to fix this (how long did it take them to retire the FAT filesystem that was considered prehistoric by the late 1980s again?), BIND runs under Windows too... >> (but I hope they're smart enough to keep some non-anycasted root >> servers around), > Who is "they"? Not sure. :-) > Since there is no top Root Nameservers Authority, every > root nameserver manager decides for himself (I assume they coordinate > but I'm not sure and it's not the same thing). Unlike a TLD, there is > no central decision for management of the root's name servers. So they > can all decide independently to anycast. Diversity is a good thing. But who to the root operators answer to anyway? Not to ICANN, I'm told.

1 0

Just had an interesting side effect of the "V" hijack...
by Jerry Eyers 18 Sep '03

18 Sep '03

Went to register.com to register a new DNS server for someone, and when it normally asks for the IP address (new server, new domain), it didn't because when it did a query, it got a response for that name. Now, it is reporting the new DNS server as resolving to Verisign's IP address. I think register has got some tweaking to do on their web scripts to ignore wildcard responses... But, shows another side effect of "V's" unilateral action. Jerry

1 0