January 2001 - Test - lists.nanog.org

Re: sorry to ruin several of your evenings...
by Paul Vixie 28 Jan '01

28 Jan '01

tkernen(a)deckpoint.ch (Thomas Kernen) writes: > > (the root name servers were all done last week, for example.) > > What about TLD managers, do/can they get the info at the same time as the > root-server admins? I don't know. ISC is considering a membership program which would allow system vendors and TLD operators to receive the same kinds of notifications that "support customers" and root name server operators receive now. But at the moment, the system vendors and TLD operators are still reached through CERT when there's something critical to announce.

1 0

Re: Proactive steps to prevent DDOS?
by Jason Legate 28 Jan '01

28 Jan '01

> I would add careful use of some rate-limiting > functionality, > (already mentioned in Richard Steenbergen's > http://www.e-gerbil.net/ras/dos.txt) > so you can rate-limit things like icmp and acks > numbered 0 and anything > else that show themselves to be obvious candidates > over time. In actuality, in a TCP SYN packet, an ack of 0 is very common. If you view legitimate syn's generated by real stacks, you will see at dword offset 7: 0x00000000. Last time I checked, this was a 0 for all intents and purposes. By rate-limiting acks of 0, you are rate-limiting most syn packets, which I don't think is the ultimate goal. -j __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/

1 0

Re: sorry to ruin several of your evenings...
by Paul A Vixie 28 Jan '01

28 Jan '01

> Without being aware of what your disclosure policies are, I'll go ahead > and ask... what are the flaws, and are they also in 8.2.2-p7? if 8.2.2-P7 were safe, you can bet that the warning ("don't run anything earlier") would have come with 8.2.2-P7. > I don't see anything at: > > http://www.isc.org/products/BIND/bind-security.html > > that mentions p7. Sure, I could diff a bunch of stuff... you can bet that dozens of kiddies all over the world are diffing stuff. maybe you'll be faster than them, find the specific problem, develop a patch that's different from "install 8.2.3", and deploy it before you're hit. > Sorry to bring this to NANOG, but it's a bit more appropriate than gabbing > about what a root server is. Also, note that Bugtraq is gone until > Monday, so there'll be no talk of this there. there are several major announcements planned for monday. ISC wanted to get the new code on the street soon enough to give people a running head start at upgrading. (the root name servers were all done last week, for example.)

2 1

How common is lack of DNS server diversity?
by Sean Donelan 28 Jan '01

28 Jan '01

Mice and Men found that 38% of the .COM domains surveyed had all their name servers on the same subnet. And 75% had one or more configuration errors. http://www.menandmice.com/dnsplace/healthsurvey.html DNS, like most databases, suffers from information entropy. In other words, it takes a lot of energy to keep information correctly updated while it is being changed. Anyone who has been Hostmaster for even a moderately sized ISP knows there is an amazing number of ways for people to mess up any of the pieces of data required to make the whole thing work. As several people pointed out, you can't really assume close IP addresses are in fact topologically close on the network. For example, if you look at the name severs for GENUITY.NET Domain servers in listed order: DNSAUTH1.SYS.GTEI.NET 4.2.49.2 DNSAUTH2.SYS.GTEI.NET 4.2.49.3 DNSAUTH3.SYS.GTEI.NET 4.2.49.4 They appear to be closely related. However, the addresses are in fact routed to very diverse locations on Genuity's network. You will find the same thing if you look at the name servers for UU.NET Domain servers in listed order: AUTH00.NS.UU.NET 198.6.1.65 AUTH60.NS.UU.NET 198.6.1.181 These servers are also geographically diverse. So I'm not sure if the 38% number is a true indication of how much diversity DNS servers have.

11 12

RE: More 6509 problems...
by Danny Snyder 28 Jan '01

28 Jan '01

I don't believe that is the case. According to Cisco, it is required to make several of the line cards installable in the FlexWAN modules work correctly. I don't know what the details of distributed CEF are, but it made my DS3s work, and that's the main thing I was looking for.... :-) --Danny -----Original Message----- From: Berger, Gary [mailto:Gary.Berger@dowjones.com] Sent: Tuesday, January 30, 2001 10:48 AM To: agudgeon(a)firstnet.co.uk; 'Danny Snyder'; nanog(a)merit.edu Subject: RE: More 6509 problems... Correct me if I am wrong but I believe Distributed CEF is only applicable to distributed line cards which need the X-Bar backplane. Gary Berger Internal Consultant, Principal Dow Jones Enterprise Network Services -----Original Message----- From: Alison Gudgeon [mailto:agudgeon@firstnet.co.uk] Sent: Tuesday, January 30, 2001 11:36 AM To: 'Danny Snyder'; nanog(a)merit.edu Subject: RE: More 6509 problems... Hi Hybrid IOS I've got IP CEF DISTRIBUTED set globally. Did you have it enabled or disabled on the T3 interface? Ali -----Original Message----- From: Danny Snyder [mailto:dsnyder@nowdocs.com] Sent: 30 January 2001 16:21 To: agudgeon(a)firstnet.co.uk; nanog(a)merit.edu Subject: RE: More 6509 problems... Alison, I've had VERY similar problems with a 6509 (Sup 1a + MSFC2) with a FlexWAN and a PA-2T3+. After spending the better part of two weeks on the phone with Cisco, we finally determined that ip cef distributed needed to be turned on in global configuration. Also, are you running native IOS or Catalyst OS on the Supervisor and IOS on the MSFC ? Danny Snyder Network Administrator NowDocs, Inc. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alison Gudgeon Sent: Tuesday, January 30, 2001 10:18 AM To: nanog(a)merit.edu Subject: More 6509 problems... Hi, Is anyone doing the following: 6509 (supervisor 1a + msfc) - with a flexWAN adapter to take a Packet Over Sonet OC-3 card. I'm having great problems getting up/up on the interface, the current situation is up/down, a hardware loop at the telco kit brings the line up/up but otherwise just up/down. Config is default I've just put IP's on. I'm running very new code - 12.1(4)E1 many thanks in advance for any help. Kind Regards Alison

1 0

Anyone from nasa.gov around?
by Jay R. Ashworth 28 Jan '01

28 Jan '01

Would someone please re-map webmaster(a)nasa.gov to an X500 address that *points* somewhere? Sheesh. Fifteen years ago today... and no tribute or nothing. All. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

1 0

Re: sorry to ruin several of your evenings...
by jrg＠blodwen.demon.co.uk 28 Jan '01

28 Jan '01

"Tony Rall" <trall(a)almaden.ibm.com> writes: > It is not clear to me what incentive there is for someone running 8.2.2P7 > to upgrade to 8.3. In particular, it does not appear (from the ISC web > site or from Paul's msgs) that 8.3 fixes any security flaws in 8.2.2P7. If you look at a source diff between 8.2.2-P7 and 8.2.3, you might be scared at some of the little things that were fixed. (There's a lot of stuff added, too, as one might expect of a release and it is obviously possible that there are problems introduced within those areas too.) I can't comment about the big changes - I don't know the code well enough - but there are a number of changes like this: - if (SPRINTF((tmp, fmt, src[0], src[1], src[2], src[3])) > size) { + if (SPRINTF((tmp, fmt, src[0], src[1], src[2], src[3])) >= size) { and - if (size < sizeof "255.") + if (size <= sizeof "255.") that make me willing to upgrade (presupposing they went the right way!) My favourite inconsequential but useful change, which someone else in this thread referred to, has to be: - "No default TTL set using SOA minimum instead"); + "No default TTL ($TTL <value>) set, using SOA minimum instead"); James.

1 0

RE: sorry to ruin several of your evenings...
by Roeland Meyer 28 Jan '01

28 Jan '01

> From: Paul Vixie [mailto:vixie@mfnx.net] > Sent: Saturday, January 27, 2001 9:55 PM > asr(a)latency.net (Adam Rothschild) writes: > > > Not to disrespect Mr. Vixie, or detract from the operational content > > of the original post, but I'd like to recommend another solution to > > these recently reported security holes in BIND: install djbdns > > <http://www.djbdns.org/>. > > No disrespect taken. The README for 8.2.3 says: > > Note that BIND 8 is in "end-of-life", having been > replaced by BIND 9. > See http://www.isc.org/ for more details. > > And indeed, BIND 9 has been in preparation for several years, > has been in an > extended test release phase for the last 6 or 8 months, and > with the release > of 9.1.0 a few weeks ago, is a far better choice than BIND > 8.2.3 for most > systems. It's also compatible with BIND 8's configuration > file syntax. Thank you Paul, the web-site wasn't clear on that. Therefor, I haven't even looked at it much.

2 1

RE: How common is lack of DNS server diversity?
by Roeland Meyer 28 Jan '01

28 Jan '01

<Root server> ::= Any DNS server that has final authority for a <domain tier/level>; <domain tier/level> ::= root, TLD, SLD, 3LD, ... nLD (0LD, 1LD, 2LD, ... ,nLD). This is not to be confused with root level servers that have specific authority for dot, at the root level (0LD). One thing missing from the RFC specs for authoritative name servers, which Kashpureff demonstrated so nicely, cache poisoning is possible at ALL levels. Ergo, I thought that it was determined as best practice that; Name Servers that were offered up, as references, should be root for that level. That is, they should be non-recursive. This includes all NS references in all zone files. What should occur is that an org setup zone level roots and then use separate resolving servers for client access to the DNS. This is a two-tier structure with the primary tier being non-resursive. Ergo, within a <domain tier> there are operational tiers for root services and resolving services, per zone authority. RFC2870 only discusses this at the 0LD and only touches it lightly at other LDs. Another thing missing is a further definition of <authoritative>. Some of us have been working with the following; <Authoritative servers> ::= <zone authority>|<domain level authority>|<authoritative resolvers> <zone authority> ::= Final authority for a zone, non recursive. <domain level authority> ::= Final authority for a DL, non recursive (ie a.root-servers.net, gtld-servers.net, etc). <authoritative resolvers> ::= recursive servers, intended for use by clients, that claim authority for their specific zones. These include stub-resolvers. BTW, I consider RFC2870 antiquated, because it presupposes an architecture which may be outmoded or becoming outmoded rapidly. Load balancing and clustering technology makes RFC2870 an unnecessary waste of resources and can even get you into trouble. Yes, some of this is from work done on the ORSC roots. Yes, one of the largest problems we have had to overcome, at ORSC, IFWP, and ICANN/DNSO discussions, were semantic problems caused by overly simplistic and generic semantics. This in some part, explains why MSFT had to develop their own semantics, the current semantics are inadequate. As we all should know, semantics constrains design concepts. However, in such a case, designers will create their own semantics to route around the problem. This happened at MSFT, ORSC, and other places that didn't join/agree/submit to namedroppers. -- ROELAND M.J. MEYER Information Technology Architect Morgan Hill Software Company, Inc. TEL: +001 925 373 3954 FAX: +001 925 373 9781 http://www.mhsc.com mailto: rmeyer(a)mhsc.com > -----Original Message----- > From: bmanning(a)vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Saturday, January 27, 2001 12:51 PM > To: rmeyer(a)mhsc.com > Cc: joshua(a)roughtrade.net; rmeyer(a)mhsc.com; nanog(a)merit.edu > Subject: Re: How common is lack of DNS server diversity? > > > > > > > More interestingly, how many root servers allow > recursive lookup? > > > > > > a quick looping probe shows that none of them do, nor the > gTLD servers > > > (phew!) although L.ROOT-SERVERS.NET and H.GTLD-SERVERS.NET > > > are unreachable > > > from my view. Preparing an accurate list of all TLD servers > > > glued in the > > > root zone will take a little longer. > > > > I was taking about root servers at ALL levels, not just the root. > > > > Perhaps you are using the term "root servers" in a different > manner than I am used to. For me: > > "Root Server" = a DNS server for the zone "." in the Internet. > > What do you mean by "root servers at ALL levels, not > just the root." > That construction just does not parse. > > --bill >

5 6

Re: sorry to ruin several of your evenings...
by Paul Vixie 28 Jan '01

28 Jan '01

asr(a)latency.net (Adam Rothschild) writes: > Not to disrespect Mr. Vixie, or detract from the operational content > of the original post, but I'd like to recommend another solution to > these recently reported security holes in BIND: install djbdns > <http://www.djbdns.org/>. No disrespect taken. The README for 8.2.3 says: Note that BIND 8 is in "end-of-life", having been replaced by BIND 9. See http://www.isc.org/ for more details. And indeed, BIND 9 has been in preparation for several years, has been in an extended test release phase for the last 6 or 8 months, and with the release of 9.1.0 a few weeks ago, is a far better choice than BIND 8.2.3 for most systems. It's also compatible with BIND 8's configuration file syntax. BIND 9's server shares not a single line of code with BIND 8's. So if genetic diversity is what's worrying anybody, please check out BIND 9.1.0. But if you just want the BIND 8 you already have (except, without certain security flaws) then BIND 8.2.3 is just what you need.

5 5