Both Iraqi state provider Uruklink.net name servers offline
Despite very old recommendations, the Iraqi state provider Uruklink.net kept all of its name servers on the same subnet. Although this is recognized as a poor design, many domain name server operators worldwide do the same thing. nic1.baghdadlink.net. 2D IN A 62.145.94.1 nic2.baghdadlink.net. 2D IN A 62.145.94.2 The nic2 (62.145.94.2) has been offline for over a week. Yesterday the remaining name server nic1 (62.145.94.1) was running an old version of bind (8.1.2). It was returning obviously bogus answers to queries. In the last 24 hours, the name server application on nic1 (62.145.94.1) went offline. The server is online (responds to pings), but neither tcp or udp port 53 responds. The name server application may have crashed, been trashed, or shutdown by the system administrator.
Classified
Please refrain from discussing anything! http://news.com.com/2100-1028-994216.html sigh.
Re: summary (Re: how to get people to upgrade?)
This got me to thinking... there's no reason a centralized, automated database would need to be "yea/nay". Perhaps it's time for a "vulnerability info" RRTYPE. Of course, DNS might not be the protocol of choice; focus on concept and ignore details. ;-) One of the fields could be severity. Let minor things be logged, moderate troubles cause nagging, and major issues (e.g., worm spreading via known exploit) trigger a shutdown. Note that BIND could be written so any given instantiation knows what subsystems (TSIG, recursive queries, etc.) it's actually using. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
summary (Re: how to get people to upgrade?)
in addition to many public comments (cc'd to nanog or just sent there), i received a number of private replies. here's a representative sample: > problem is if the default is off you will probably not catch the > clueless folk that you want to target, better would be default on and > the clueful world can choose to ignore it... > > btw, my impression of the vulns in earlier binds was that everyone who > mattered had upgraded and perhaps only corporates were left on old > version, of course you prolly know more than me on that. pv: (the roots and most tld servers always update, and the vendors always have patches, but by no means everyone who matters always upgrades.) > I'd certainly consider using a service offered by ISC on this basis for any > servers for which I have any responsibility. pv: (four other people said the same; thanks for your enthusiasm! one added:) > ... However, since the problem applies to multiple software packages, > perhaps it is worth the effort developing a unified standard for this > kind of purpose (RFC, something similar) and passing it on to package > maintainers, distribution maintainers, etc? Creating a universal > "versioning system" would solve a lot of problems with keeping software > updated. i think that's true, but beyond the scope of ISC's resources, and also likely to take a very long time to settle. interestingly, since it's a protocol, the ietf should care, but since it's about software, the ietf probably won't care. > In my experience people are perfectly capable of shutting their eyes for > the need to upgrade. Harrassment by e-mail won't change much there. pv: (this is interesting, since it represents the prevalent view here that just because people want the functionality that some software provides, does not imply any commitment to keeping it from being used as an entry point for an attack nor launch point for attacks on others. this should have been obvious but i'd never thought about it that way before today.) > 1. I have another idea though, during setup of the server ask for email > address of list administrator, but keep that on the server itself. > 2. Setup some dns server that provides dns record if there are necessary > updates (here is one example in reverse dns notation...: > 1.2.9.bind.updates.isc.org and set it to particular ip or > particular MX or whatever to show if update is needed). > Possibly have this special update dns recorb be HINFO to url where more > information on update is available. > 3. When bind starts if the record in #2 exists and shows that update is > necessary, have bind server email to address entered in 1 and with > abscense of that have it email to [EMAIL PROTECTED] and if HINFO > exists, it can take that and enter this as custome email. pv: (alas, in most bind installations, there is no script that's run to install the software or generate a config, and where this is done, it's platform/vendor specific, i.e., not written by ISC even if we had one. as to #2, there's a lot more value in MIM'ing the response to a query than there is in MIM'ing the reporting of a version:hostname:email tuple, and i don't thing we should create new attack vectors. as to #3, not every bind server host has the ability to send e-mail at all.) > This idea could be taken further, with a service offering that vendors > and/or users support. Instead of having the server only answer for BIND, it > could answer for any number of products. Vendors would have to supply the > details on the latest software versions and patches, hopefully funding the > listings (in the case of software sold for dollars, open source would have > to be supported in another way, such as by user subscription). pv: (i love this idea, and if somebody else leads, ISC would try to follow.) > I think the key to getting people to upgrade may be one of: > > 1) provide an automated audit tool which can look at an existing > installation and flag known issues, and do pre-installation checks > for required supporting packages which may also need to be > installed -- sort of an automated mentoring system. Given the problems > with misconfigured software in some remote parts of the world, it > would probably be worth building that code in a way that facilitates > internationalization from the get go... > > 2) have the application periodically check for updated versions, > and nag/nudge admins when appropriate (or possibly even auto-update) > > Yes, I know, neither of these should be necessary, and yes, I know > that automation of installation tasks poses its own set of problems > but we live in the time of Windows Update and "system admins" > who aren't what they used to be, I'm afraid. pv: (i suspect that something like this, as an outboard tool capable of running on a NOC machine, is the right short term approach. it'll need the ability to scan for BIND instances in the local address space, keep
Re: how to get people to upgrade? (Re: The weak link? DNS)
Charles Sprickman wrote: On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: One obvious problem with this would be that certain vendors prefer to backport security fixes to older versions rather than test and release new versions...so an insecure-looking version string may actually have had fixes applied. I think you're talking about RedHat, right? What other vendors take this approach? I know that at a recent job I set out to scan for what versions of things were running on a bunch of boxes, and all the RedHat boxes were showing as running vulnerable versions of OpenSSH. Debian does as well. Since they run 3 different primary release branches (stable, testing, unstable), they often backport security fixes onto the stable branch without introducing additional functionality from later revisions that would be introduced via the unstable and then testing branches. For example, I'm running sendmail 8.12.3/Debian-5 which is security patched up to sendmail version 8.12.8. However, the current testing version is 8.12.6/Debian-7 and the unstable version is 8.12.8/Debian-2. While personally I think this is a bogus way to manage security fixes, there are probably many many RedHat boxes out there running BIND. Short of pointing out the error of their ways or expecting them to roll something into their own patches to fix the notification system, how would you handle that? I mean, at least on the ssh thing, they didn't even change the version string one bit, not even a 'rh-p1' or something. So as far as your scanner knows, and as far as the script kiddies know, you're running a vulnerable version. Actually, it's a very good way to run a stable environment and still get the benefit of fixes that address security or severe operational issues. In fact, the packages with the fixes were available the morning after sendmail 8.12.8 was posted and the CERT advisory went out. I had it installed by the afternoon. Can't speak for how RH handles their versioning, but as you can see above, Debian includes the source version on which a package is based plus a revision to indicate additional changes specifically added for Debian. It makes it very easy to keep track of what I have installed even if kiddie scripts think I'm running downrev versions (which I'm not). == bep
RE: Odd DNS Traffic
Michael, Do you have a packet sniff of the traffic? Possibly a sniff of at least 1 packets? HMMM.. I have seen some increase at our Corp DNS, but not that much... drop me a note offlist with the sniff.. I would like to look at this.. Jim > -Original Message- > From: Support Team [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2003 4:01 PM > To: [EMAIL PROTECTED] > Subject: Odd DNS Traffic > > > > First I would like to note I am new to the list and group. > It's nice to > be here. > > Second, since Monday, March 24th at approx 1am we have been suffering > from "odd" DNS traffic to our two primary DNS servers. The > odd traffic > has increased our bandwidth utilization by about 20 Mbps, which is > obviously putting a hurting on our network and our DNS servers. > > I know this must also be affecting other networks, and if anything the > root servers. If anyone has any suggestions, etc, they would be much > appreciated. > > Thank you, > Michael Mannella > Support Team > Synergy Networks, Inc. > > Here are the symptoms: > > > The odd traffic started with the root servers, namely > (a-m).gtld-servers.net . Most of the traffic is still coming > from them, > but other servers have also started sending us this odd traffic. > > We have 3 dns servers, only two are being affected, they are > our Primary > and Secondary servers that are listed with Network Solutions. > The third > server (that is not being affected) is not listed with NetSol > and has no > DNS records setup in it. It is strictly being used for lookups. > > The odd traffic is listed as a "DNS Spoof attempt" on our firewall. > > The odd traffic looks like this: > > Rcv 192.48.79.300cbb R Q [0084 A NOERROR] > (8)Îҵĵ绰(3)COM(0) > UDP response info at 01ADC8BC > Socket = 380 > Remote addr 192.48.79.30, port 53 > Time Query=147367, Queued=0, Expire=0 > Buf length = 0x0200 (512) > Msg length = 0x010e (270) > Message: > XID 0x0cbb > Flags 0x8400 > QR1 (response) > OPCODE0 (QUERY) > AA1 > TC0 > RD0 > RA0 > Z 0 > RCODE 0 (NOERROR) > QCOUNT0x1 > ACOUNT0x1 > NSCOUNT 0xd > ARCOUNT 0x0 > Offset = 0x000c, RR count = 0 > Name "(8)Îҵĵ绰(3)COM(0)" > QTYPE A (1) > QCLASS 1 > ANSWER SECTION: > Offset = 0x001e, RR count = 0 > Name "[C00C](8)Îҵĵ绰(3)COM(0)" > TYPE A (1) > CLASS 1 > TTL300 > DLEN 4 > DATA 198.41.1.35 > AUTHORITY SECTION: > Offset = 0x002e, RR count = 0 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 20 > DATA (1)g(12)gtld-servers(3)net(0) > Offset = 0x004e, RR count = 1 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)h[C03C](12)gtld-servers(3)net(0) > Offset = 0x005e, RR count = 2 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)d[C03C](12)gtld-servers(3)net(0) > Offset = 0x006e, RR count = 3 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)j[C03C](12)gtld-servers(3)net(0) > Offset = 0x007e, RR count = 4 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)i[C03C](12)gtld-servers(3)net(0) > Offset = 0x008e, RR count = 5 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)l[C03C](12)gtld-servers(3)net(0) > Offset = 0x009e, RR count = 6 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)b[C03C](12)gtld-servers(3)net(0) > Offset = 0x00ae, RR count = 7 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)e[C03C](12)gtld-servers(3)net(0) > Offset = 0x00be, RR count = 8 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)a[C03C](12)gtld-servers(3)net(0) > Offset = 0x00ce, RR count = 9 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)k[C03C](12)gtld-servers(3)net(0) > Offset = 0x00de, RR count = 10 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 > TTL172800 > DLEN 4 > DATA (1)f[C03C](12)gtld-servers(3)net(0) > Offset = 0x00ee, RR count = 11 > Name "[C015](3)COM(0)" > TYPE NS (2) > CLASS 1 >
Re: how to get people to upgrade? (Re: The weak link? DNS)
SL> Date: Thu, 27 Mar 2003 09:55:08 +1200 (NZST) SL> From: Simon Lyall SL> I'm also worried about any concept of trying to "force" SL> people to upgrade, even with bind I use some features (namely SL> an external named-xfer program) of bind v8 that arn't SL> available in bind v9 . For the servers which I need this on I I'm curious... why not use "dig @wherever zone.example axfr" instead? SL> run bind 8.3.3 (Vendor backported with the 8.3.4 fixes) of SL> copy the named-xfer program over to the bind 9 box. Agreed re the hazards of being heavy-handed. However, I'm sure there would be those who disabled the automated checkup... the question is, would they be the crowd for whom the approach in question was intended? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Contact with Clue at XO?
Very big thanks to Dennis over at XO for his fast reply. It's getting taken care of now. -Eric On Wed, 26 Mar 2003, Eric Whitehill wrote: > Date: Wed, 26 Mar 2003 16:41:08 -0500 (EST) > From: Eric Whitehill <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Contact with Clue at XO? > > > Sorry to populate the list with traffic like this... > > Extended IP access list 120 > deny ip 216.156.98.0 0.0.0.255 any (31607418 matches) > permit ip any any (43284187 matches) > > (this is under 2 hours) > > Which is a very, very bad thing. > > Can someone from XO, please contact me about this? > > 15:33:51 pfe R ge-0/0/0.0 ICMP 216.156.98.x 206.xx.xx.xx > 15:33:51 pfe R ge-0/0/0.0 UDP 216.156.98.x 206.xx.xx.xx > > Apparently emails to their abuse dept with contact info and such do not > generate responses. > > Thanks! > > -Eric >
RE: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > One obvious problem with this would be that certain vendors prefer to > backport security fixes to older versions rather than test and release > new versions...so an insecure-looking version string may actually have > had fixes applied. I think you're talking about RedHat, right? What other vendors take this approach? I know that at a recent job I set out to scan for what versions of things were running on a bunch of boxes, and all the RedHat boxes were showing as running vulnerable versions of OpenSSH. While personally I think this is a bogus way to manage security fixes, there are probably many many RedHat boxes out there running BIND. Short of pointing out the error of their ways or expecting them to roll something into their own patches to fix the notification system, how would you handle that? I mean, at least on the ssh thing, they didn't even change the version string one bit, not even a 'rh-p1' or something. So as far as your scanner knows, and as far as the script kiddies know, you're running a vulnerable version. Charles > -- > Jon Lewis [EMAIL PROTECTED]| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003, E.B. Dreger wrote: > PV> From: Paul Vixie > PV> appealing, but i'm more concerned about MIM when fetching > PV> update information than i am with simply registering package > PV> version numbers, hosts, and e-mail addresses. > > Distribute BIND with public key. Updates are encrypted or signed > with its counterpart. But don't distributors already provide this service? Several Linux distributions (at least Redhat and Debian) and Unix companies (Sun at least) already provide [semi-]automatic updates of packages like bind. Just look at the vendor list in the average CERT notice. Someone who downloads, compiles and installs bind directly from the ISC is already indicating that they want to go beyond the safe vendor supplied version thats good-enough for 99% of people. I'm also worried about any concept of trying to "force" people to upgrade, even with bind I use some features (namely an external named-xfer program) of bind v8 that arn't available in bind v9 . For the servers which I need this on I run bind 8.3.3 (Vendor backported with the 8.3.4 fixes) of copy the named-xfer program over to the bind 9 box. -- Simon Lyall.| Newsmaster | Work: [EMAIL PROTECTED] Senior Network/System Admin | Postmaster | Home: [EMAIL PROTECTED] Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Contact with Clue at XO?
Sorry to populate the list with traffic like this... Extended IP access list 120 deny ip 216.156.98.0 0.0.0.255 any (31607418 matches) permit ip any any (43284187 matches) (this is under 2 hours) Which is a very, very bad thing. Can someone from XO, please contact me about this? 15:33:51 pfe R ge-0/0/0.0 ICMP 216.156.98.x 206.xx.xx.xx 15:33:51 pfe R ge-0/0/0.0 UDP 216.156.98.x 206.xx.xx.xx Apparently emails to their abuse dept with contact info and such do not generate responses. Thanks! -Eric
Re: how to get people to upgrade? (Re: The weak link? DNS)
PV> Date: 26 Mar 2003 21:22:59 + PV> From: Paul Vixie PV> having the server check for updates and issue local mail is This assumes the configured notification email address remains valid, and the recipient doesn't sort them into a "I'll get around to it" folder. PV> appealing, but i'm more concerned about MIM when fetching PV> update information than i am with simply registering package PV> version numbers, hosts, and e-mail addresses. Distribute BIND with public key. Updates are encrypted or signed with its counterpart. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: how to get people to upgrade? (Re: The weak link? DNS)
i see that a lot of folks are responding publically. sorry to spawn a thread.
[EMAIL PROTECTED] (Niels Bakker) writes:
> So how much would this differ from `make install' running this shell script?
most bind installations are prefab -- the come with the operating system and
there's no "make install" done after the host has a name.
[EMAIL PROTECTED] ("Kuhtz, Christian") writes:
> Administrator inertia is the root cause. I don't see how an automatism such
> as the one described changes human behavior. And unless you change that
> inertia, no amount of notification, databases, registries, yada yada yada
> will make any difference.
this argues for time bombs, where the software will stop working after it
detects some condition (too much time has passed, or an advertisement for
newer software is seen, or a vulnerability notice is seen). this would be
wildly unpopular, contrary to the open source philosophy, and never adopted.
[EMAIL PROTECTED] (Pedro R Marques) writes:
> If you want to address this issue my suggestion would be to make BIND
> automatically update itself... and option that needs to default to ON
> and that can be disabled in managed systems where admins are expected
> to read CERT and act upon it.
this solution implies a trust relationship between a server operator and the
software provider which in fact never exists in reality. even my microsoft
sysadmin friends carefully eyeball any "software update" patch before they'll
put it on production iron. then there's the local customization issue -- and
the binary problem, since many name server hosts do not have compilers. again
this would be contrary to the open source philosophy.
***
i don't want to have this be bimodal (run binaries from someone you're
required to trust, or else run source and be out of date most of the time)
since neither mode is interesting or useful.
i do agree that other open source packages (openssl for example, or apache)
would benefit from a good answer to the "how to get folks to upgrade"
question. however, i'm not sure a single answer will fit all packages.
having the server check for updates and issue local mail is appealing, but
i'm more concerned about MIM when fetching update information than i am with
simply registering package version numbers, hosts, and e-mail addresses.
--
Paul Vixie
Re: suggestion for IBX in Washington DC
talk with Level3 Communication. They have excellent collo environment and interconnection with different providers. Email me offline if you need a contact person. Cheers, Moe On Wed, 26 Mar 2003, K. Scott Bethke wrote: > > I need a recommendation for an IBX/colo environment located in the city of > Washington DC itself.. I know Tyson/McLean is Paradise but looking for a > good solution actually IN the DC portion of lata 236 > > Our main goals are Transit availability from good providers (Worldcom is a > must) and good peering options > > -Scotty >
Re: The weak link? DNS
On Wed, 26 Mar 2003, Matt Buford wrote: > I can not go into details, but suffice it to say DNS was just a symptom of > other events, not the problem itself. DNS TTL on the global load balancing > system was at 5 seconds and DNS load never rose above trivial. Al Jazeera's main problem looks like its web site or upstream decided to drop them as a customer.
Odd DNS Traffic
First I would like to note I am new to the list and group. It's nice to be here. Second, since Monday, March 24th at approx 1am we have been suffering from "odd" DNS traffic to our two primary DNS servers. The odd traffic has increased our bandwidth utilization by about 20 Mbps, which is obviously putting a hurting on our network and our DNS servers. I know this must also be affecting other networks, and if anything the root servers. If anyone has any suggestions, etc, they would be much appreciated. Thank you, Michael Mannella Support Team Synergy Networks, Inc. Here are the symptoms: The odd traffic started with the root servers, namely (a-m).gtld-servers.net . Most of the traffic is still coming from them, but other servers have also started sending us this odd traffic. We have 3 dns servers, only two are being affected, they are our Primary and Secondary servers that are listed with Network Solutions. The third server (that is not being affected) is not listed with NetSol and has no DNS records setup in it. It is strictly being used for lookups. The odd traffic is listed as a "DNS Spoof attempt" on our firewall. The odd traffic looks like this: Rcv 192.48.79.300cbb R Q [0084 A NOERROR] (8)Îҵĵ绰(3)COM(0) UDP response info at 01ADC8BC Socket = 380 Remote addr 192.48.79.30, port 53 Time Query=147367, Queued=0, Expire=0 Buf length = 0x0200 (512) Msg length = 0x010e (270) Message: XID 0x0cbb Flags 0x8400 QR1 (response) OPCODE0 (QUERY) AA1 TC0 RD0 RA0 Z 0 RCODE 0 (NOERROR) QCOUNT0x1 ACOUNT0x1 NSCOUNT 0xd ARCOUNT 0x0 Offset = 0x000c, RR count = 0 Name "(8)Îҵĵ绰(3)COM(0)" QTYPE A (1) QCLASS 1 ANSWER SECTION: Offset = 0x001e, RR count = 0 Name "[C00C](8)Îҵĵ绰(3)COM(0)" TYPE A (1) CLASS 1 TTL300 DLEN 4 DATA 198.41.1.35 AUTHORITY SECTION: Offset = 0x002e, RR count = 0 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 20 DATA (1)g(12)gtld-servers(3)net(0) Offset = 0x004e, RR count = 1 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)h[C03C](12)gtld-servers(3)net(0) Offset = 0x005e, RR count = 2 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)d[C03C](12)gtld-servers(3)net(0) Offset = 0x006e, RR count = 3 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)j[C03C](12)gtld-servers(3)net(0) Offset = 0x007e, RR count = 4 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)i[C03C](12)gtld-servers(3)net(0) Offset = 0x008e, RR count = 5 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)l[C03C](12)gtld-servers(3)net(0) Offset = 0x009e, RR count = 6 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)b[C03C](12)gtld-servers(3)net(0) Offset = 0x00ae, RR count = 7 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)e[C03C](12)gtld-servers(3)net(0) Offset = 0x00be, RR count = 8 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)a[C03C](12)gtld-servers(3)net(0) Offset = 0x00ce, RR count = 9 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)k[C03C](12)gtld-servers(3)net(0) Offset = 0x00de, RR count = 10 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)f[C03C](12)gtld-servers(3)net(0) Offset = 0x00ee, RR count = 11 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)c[C03C](12)gtld-servers(3)net(0) Offset = 0x00fe, RR count = 12 Name "[C015](3)COM(0)" TYPE NS (2) CLASS 1 TTL172800 DLEN 4 DATA (1)m[C03C](12)gtld-servers(3)net(0) ADDITIONAL SECTION: The DNS server encountered an invalid domain name in a packet from 192.48.79.30. The packet is rejected.
Re: The weak link? DNS
I can not go into details, but suffice it to say DNS was just a symptom of other events, not the problem itself. DNS TTL on the global load balancing system was at 5 seconds and DNS load never rose above trivial. - Original Message - From: "Sean Donelan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 26, 2003 4:09 AM Subject: The weak link? DNS > > Watching the Iraqi Ururklink and Al Jazeera over the weekend what struck > me is how many different ways network administrators can mess up. > Although malicious actors have been trying (and succeeding) to exploit > vulnerabilities, the worst problems seem to be self-inflicted. > > Administrators had used firewalls and locked down their web sites, > sometimes so well they couldn't handle the traffic load. > > But the real weak link was their DNS servers. > > For example, Al Jazeera had time-to-live set of their domain records set > to 15 minutes, making them even more vulnerable to increasing the load > on their systems. Of course, Al Jazeera had other problems too. > > What even stranger about the Iraqi state provider Uruklink.net is the DNS > servers are now self-identifying with earlier (with known bugs) versions > of BIND. Last week the Uruklink name server 62.145.94.1 was running > 8.2.2-P5, but now is running 8.1.2. Although the web site for > www.uruklink.net is up, DNS lookups for www.uruklink.net return various > other IP addresses (not in 62.145.94.0/24). Including some addresses > running web sites claiming the site is "owned." In reality, the site > isn't owned, you are being redirected to a unrelated web site. > >
Florida
Hi folks, Anybody seen/heard of major outages/jams in Florida today ? I'm having some pockets of resistance making it impossible for me to get to Verisign, Sun, Reuters and AP from 65.87.x.x Appreciate any insights on or off list. thanks Bert
how to get people to upgrade? (Re: The weak link? DNS)
> what i really want to talk > about is: how to get people to upgrade their software when defects > are found. > > sending out announcements through CERT and the bind-announce m/l > isn't working. Paul, I seems to me that you are assuming that the problem is not enought information gets to system admins... that may be the case in some instances, but it is my belief that the majority of the cases have to do with the fact that systems are not administered. i.e. they where setup once and there are assumed to be running without need for maintenance. imho, this is a very reasonable expectation... unfortunatly most software is not really up to what people expect in this regard. If you want to address this issue my suggestion would be to make BIND automatically update itself... and option that needs to default to ON and that can be disabled in managed systems where admins are expected to read CERT and act upon it. This is sort of the direction other systems are taking... microsoft, which is quite competent on the consumer market, tends to have this automated update tools that can be turned off but are a pain to do so. The result is imperfect but imho better than what would be without such tools. I'm afraid that BIND is currently a consumer tool also and that you should not expect an administrator to be present, even if someone was around to initialy setup the system. Pedro.
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003 08:14:45 PST, [EMAIL PROTECTED] said: > > What are you talking about, DNS check option will work great for BIND, > I mean if BIND can not get to the root server and thereafter to ISC, you > don't have to worry about it getting hacked, its probably not connected to Keep in mind that the *really* damaging security incidents tend to be the ones with skilled and/or insider attackers. And if you've scored some secretary's PC inside the corporate net, a DNS server inside the net (and unable to contact the outside world) makes a GREAT way to leverage the foothold pgp0.pgp Description: PGP signature
RE: how to get people to upgrade? (Re: The weak link? DNS)
> CK> The way I see it, the issue isn't that there aren't enough > CK> notifications of BIND vulnerabilities. > > Perhaps. But how much is enough? Current notification levels > certainly get a fair number of admins to upgrade. Feel free to elaborate on where you think gaps exist.. > CK> Administrator inertia is the root cause. I don't see how an > CK> automatism such as the one described changes human behavior. > CK> And unless you change that inertia, no amount of > CK> notification, databases, registries, yada yada yada will make > CK> any difference. > > Correct. Human behavior won't change. The pain must exceed the > inertia. I'm always open to suggestions. Let's just suppose for a moment that pain is in fact the right approach. How do you create such 'pain'? Spamming admins with (even more) emails is a bad idea, IMHO. I'm sure it'll catch some of those who enable the feature it, but will it really make that much of a difference? For example, I can't think of a precedent for self-updating software that works (well), especially with the high degree of customization available in BIND. Until we find that holy grail, IMHO, the most you can do is make an update readily available and tell people about it. Thanks, Christian * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
Re: [Re: how to get people to upgrade? (Re: The weak link? DNS)]
On Wed, 2003-03-26 at 10:52, Joshua Smith wrote: > > don't foget to include some useful/helpful comments regarding where to > look for more info Yes, the TXT record would inlcude the entire text of the security notice (hmm... how big can TXT records be?) or at least a URL. > i like this idea better, and every little bit helps, but i still have > some reservations: > for the install-and-forget crowd (it is runnning right - well then why > would i want to mess with it), i don't know that they would see the > periodic messages, know how to act on them (although i am sure that very > detailed instructions could be included in each email), or care to act on > them. unless there is a blinking icon in the 'taskbar' that they click > on, and then magically when the machine has rebooted, they are up2date > with everything, i have doubts that it would work for a lot of the > servers out there Ideally, you would get a mild electric shock from your keyboard if you were running software that had known security problems. Not enough of a shock that would numb your hands (you need them to upgrade!) or send you into cardiac arrest, but just enough that using a computer would be uncomfortable enough so that you would apply security patches in a timely manner. However, the technical and legal issues are unsolvable (I'm fine with the moral/ethical issues here) so I didn't mention it before. Seriously, you can do only so much to *force* people to apply security patches. Basically, when it comes to security patches, there are two classes of admins, the kind that do hear about security advisories and the kind that don't. For those admins that do hear about security advisories there are going to be some admins that don't apply security patches because they just don't care. There are also going to be some that don't apply security patches because they don't know how and don't care enough to learn how. There's not much we can do about those people. What we CAN so is to reduce the number of people that don't hear about security advisories. Web pages, CERT mailing lists, etc. don't reach enough people partly because people don't know about them or don't have the time to check a bazillion web pages or read a bazillion mailing list posts that talk about software that they don't even use. However, if MY DNS server started emailing ME, I'd be a little more likely to sit up and take notice and maybe do something about it. > (besides, how will any of this prompt those whom are > currently out of date to upgrade?) Unfortunately, any proposal like this can only affect future versions of software. Fortunately, most systems get upgraded eventually (although it could take years, maybe decades). Jeff
RE: how to get people to upgrade? (Re: The weak link? DNS)
JL> Date: Wed, 26 Mar 2003 13:00:57 -0500 (EST) JL> From: Jon Lewis JL> How hard would it be to have bind do some sort of secure.bind.isc.org JL> query at start-up or perhaps even periodically and have it log lots of JL> warnings or refuse to run if the query comes back and tells it the local JL> version has been deferred due to security updates? One obvious problem Not hard. Again, I'm in favor of refusing to run... I've encountered waaay too many "I click and it works" people. JL> with this would be that certain vendors prefer to backport security fixes JL> to older versions rather than test and release new versions...so an If they're backporting, they can add their own checks. If they break the version checking, then they become the vendor with the broken software. JL> insecure-looking version string may actually have had fixes applied. JL> Perhaps the query could be for a timestamp that's defined in the source JL> with the assumption that any code older than the most recent security JL> update must be insecure. This would make a good second/additional/whatever check. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: how to get people to upgrade? (Re: The weak link? DNS)
: Correct. Human behavior won't change. The pain must exceed the : inertia. : : Sounds familiar. Have we seen this before? : : Outdated bogon filters... old software... spam... needless route : deaggregation... broken smurf filters... ingress/egress : filtering... router> en Password: router# conf t router(config)# force-conformity-or-else-great-pain router(config)#^Z router# wr mem router#.Write startup-config in progress. .Write startup-config done. router#exit router>exit It truly is the only answer. It's how I handle things on my network. Make it painful and they remember. Otherwise they don't. Period. ;-) scott
Re: how to get people to upgrade? (Re: The weak link? DNS)
What are you talking about, DNS check option will work great for BIND, I mean if BIND can not get to the root server and thereafter to ISC, you don't have to worry about it getting hacked, its probably not connected to internet. And dns already provides ability for ISC to have multiple diverse dns servers in different parts of the world in case you can't get to one of them, so access to these TXT records is assured. And I really do like how Jeff finished with good example what I had in mind in my original email. I still think it might be worth it to ask for email administrator email address during setup and have that added to named.conf as its own special parameter and when its not present then email can go to root or postmaster or possibly hostmaster address from the first zone listed (I'm not sure which is better...) and this system also has to be presented to the user (possibly as default on option), but they must also know what the sytem would be doing (i.e. that you for example will have list of their ips) as some already expressed privacy concerns on this being done automaticly without turn-off option. On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > > > The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I have a better idea. > > ISC could set up a web page that would contain security/bug advisories for > every version. In order to make it easier for people to find this web > page, it could be listed in various directories such as CERT. And it could > also be put into search engines so that someone could go to Google, type > in "BIND bug site:isc.org" and click "I'm Feeling Lucky". > > > yadda yadda yadda... > > Indeed! > > Let's face it folks, DNS is not the tool of choice for publishing anything > other than the mapping between hostnames and IP addresses. > > For some things the web is better. For others LDAP is better. And for the > problem that Paul mentioned at the beginning there is only one solution; > the press. > > The fact is that Paul wants to catch the attention of people who aren't > paying attention right now. He has stated that email notices don't work > and we can assume that the BIND security web page, and CERT's web pages > also don't work. No, there is only one thing Paul can do right now. > > a. Collect some realistic numbers as to the number of DNS servers that are > vulnerable to the various exploits. Ask people who do network scanning to > provide some statistics on what they see and scale them up according to > the number of hosts in the host-count database. For example, assume that > someone has scanned N hosts and discovers that N/10 are running BIND and > that 40% of those are vulnerable. Also assume that the hostcount shows 20 > million hosts in the world. Infer from this that there are 2 million BIND > servers and that there are 800,000 vulnerable ones. But do the > calculations with some real data, not my example figures. > > b. Write a press release with the following headline: > > N Thousand Internet Servers Suffer Same Fate as Iraqi Server > > Or maybe write some variation on this but keep it scary and keep Iraq in > the headline. The body of the press release should explain the attacks > that the Iraqi server was suffering from, then point out how many other > servers are also vulnerable and then point out how terrorists could use > these vulnerabilities against us. If you can, name some specific > organizations where you know the vulnerability exists. Pick a large > organization or two that has many nameservers and the vulnerability exists > in some obscure corner of the organization, not on their main nameservers. > They really can't sue over this because you haven't damaged them by > disclosing enough detail for an attacker to use. > > c. release to both the national press and the computer/network trade > press. > > That's how you get people's attention and that's also how the clueful > technical people get the authority and funding to go in and fix the > vulnerable boxes. As long as we continue to play games and pretend that > Internet operations is still the old boys club that it once was, we will > continue to suffer from these nagging issues. > > People on the NANOG mailing list do not run the Internet anymore. NANOG's > market share of network operations people has been steadily shrinking as > the Internet has grown. This may still be the moist clueful gathering > place, but there are an awful lot of people out there today designing, > building and operating networks, who have never heard of NANOG. > > There is no universal forum anymore. The Internet isn't special anymore. > > --Michael Dillon
RE: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 26 Mar 2003, E.B. Dreger wrote: > CK> The way I see it, the issue isn't that there aren't enough > CK> notifications of BIND vulnerabilities. > > Perhaps. But how much is enough? Current notification levels > certainly get a fair number of admins to upgrade. The majority of those who don't keep up with security releases won't unless their systems break or you personally notify them and explain the problem to them...much like equipment with unmaintained bogon filters go unfixed until you track down the responsible parties and thwap them on the head. Short of designing some kind of time bomb (make it possible to turn it off in the config for those who simply can't upgrade and don't intend to) such that after a certain age or other trigger, the code simply refuses to run, the unmaintained systems simply aren't going to get upgraded How hard would it be to have bind do some sort of secure.bind.isc.org query at start-up or perhaps even periodically and have it log lots of warnings or refuse to run if the query comes back and tells it the local version has been deferred due to security updates? One obvious problem with this would be that certain vendors prefer to backport security fixes to older versions rather than test and release new versions...so an insecure-looking version string may actually have had fixes applied. Perhaps the query could be for a timestamp that's defined in the source with the assumption that any code older than the most recent security update must be insecure. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: how to get people to upgrade? (Re: The weak link? DNS)
CK> Date: Wed, 26 Mar 2003 11:59:02 -0500 CK> From: "Kuhtz, Christian" CK> The way I see it, the issue isn't that there aren't enough CK> notifications of BIND vulnerabilities. Perhaps. But how much is enough? Current notification levels certainly get a fair number of admins to upgrade. CK> Administrator inertia is the root cause. I don't see how an CK> automatism such as the one described changes human behavior. CK> And unless you change that inertia, no amount of CK> notification, databases, registries, yada yada yada will make CK> any difference. Correct. Human behavior won't change. The pain must exceed the inertia. Sounds familiar. Have we seen this before? Outdated bogon filters... old software... spam... needless route deaggregation... broken smurf filters... ingress/egress filtering... Anything relying on widespread human responsibility is foredoomed to failure. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: how to get people to upgrade? (Re: The weak link? DNS)
Perhaps nameservers could periodically poll dig @?.root-servers.net 2.2.9.is-vuln.bind. txt chaos or something similar; I suggest using roots because DNS queries to them are far less likely to be filtered. If corresponding RR is valid (see below), shut down BIND, thus forcing admins to look into the problem. Harsh? Yes. Sadly, "it runs, so it must be correct" is far more common an attitude than "it must be correct before it's allowed to run". Worried about spoofing? Distribute the public key with BIND, and let the TXT response be encoded. Of course, the clueless generally don't compile from source. I wonder how long it would be before some vendor circumvented such controls so their userbase wouldn't be hassled with such silliness as forced critical upgrades. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: how to get people to upgrade? (Re: The weak link? DNS)
> On 26 Mar 2003, Jeffrey C. Ollie wrote: > > What I would like to see is somewhat of the idea in > > reverse. The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I really like this solution. It seems clean and unobjectionable, while > getting the job done. What's the job, though? The way I see it, the issue isn't that there aren't enough notifications of BIND vulnerabilities. Administrator inertia is the root cause. I don't see how an automatism such as the one described changes human behavior. And unless you change that inertia, no amount of notification, databases, registries, yada yada yada will make any difference. Thanks, Christian * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
Re: [Re: how to get people to upgrade? (Re: The weak link? DNS)]
"Jeffrey C. Ollie" <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2003-03-26 at 09:24, Paul Vixie wrote:
> > so here's a proposal. we (speaking for ISC here) could add a config
> > option
> > (default to OFF) to make bind send some kind of registration packet
> > at boot
> > time, containing an e-mail address for a technical contact for that
> > server,
> > and perhaps its hostname as well.
> >
options {
...
...
// this option is here to remind you when it is time to be a
// responsible netizen - choices are on or off, default is on
fetch-clue on
...
}
> > [...]
> >
> > given such a feature, whose default was OFF, would anyone here who
> > uses
> > BIND stop using it out of protest? if so plz answer publically (on
> > nanog).
>
> I would not use such a feature, and I suspect that most people who would
> use such a feature would not have a clue that it was there or how to
> turn it on. What I would like to see is somewhat of the idea in
> reverse. The ISC would host a zone that would contain TXT records with
> security/bug advisories for every version:
>
> $ORIGIN .
>
> security-notice.bind IN SOA ns.isc.org. postmaster.isc.org. 1
> 72003600
604800 3600
>
> $ORIGIN security-notice.bind.
>
> 8.3.3 IN TXT "Name: BIND: Multiple Denial of Service [yadda
> yadda
yadda...]"
> 4.9.10IN TXT "Name: LIBRESOLV: buffer overrun
> [yadda yadda yadda...]"
>
> yadda yadda yadda...
>
> Ideally the zone would be DNSSEC signed as well.
>
don't foget to include some useful/helpful comments regarding where to
look for more info
> Then, by default, BIND would query the zone periodically (perhaps every
> 24 hours or so) for it's version. If any records are found it would log
> a message and/or send email to [EMAIL PROTECTED], which would be repeated
> periodically (I'd log a message every time that a check was performed,
> but I'd only email once a week). There would be config options so that
> the clueful admin could customize/disable this behavior to his or her
> liking.
i like this idea better, and every little bit helps, but i still have
some reservations:
for the install-and-forget crowd (it is runnning right - well then why
would i want to mess with it), i don't know that they would see the
periodic messages, know how to act on them (although i am sure that very
detailed instructions could be included in each email), or care to act on
them. unless there is a blinking icon in the 'taskbar' that they click
on, and then magically when the machine has rebooted, they are up2date
with everything, i have doubts that it would work for a lot of the
servers out there (besides, how will any of this prompt those whom are
currently out of date to upgrade?)
>
> This way no one would be collecting a central database of email
> addresses, but everyone would get notified of security advisories in a
> timely manner.
>
> Jeff
>
>
my $0.02
joshua
"Walk with me through the Universe,
And along the way see how all of us are Connected.
Feast the eyes of your Soul,
On the Love that abounds.
In all places at once, seemingly endless,
Like your own existence."
- Stephen Hawking -
Re: how to get people to upgrade? (Re: The weak link? DNS)
> The ISC would host a zone that would contain TXT records with > security/bug advisories for every version: I have a better idea. ISC could set up a web page that would contain security/bug advisories for every version. In order to make it easier for people to find this web page, it could be listed in various directories such as CERT. And it could also be put into search engines so that someone could go to Google, type in "BIND bug site:isc.org" and click "I'm Feeling Lucky". > yadda yadda yadda... Indeed! Let's face it folks, DNS is not the tool of choice for publishing anything other than the mapping between hostnames and IP addresses. For some things the web is better. For others LDAP is better. And for the problem that Paul mentioned at the beginning there is only one solution; the press. The fact is that Paul wants to catch the attention of people who aren't paying attention right now. He has stated that email notices don't work and we can assume that the BIND security web page, and CERT's web pages also don't work. No, there is only one thing Paul can do right now. a. Collect some realistic numbers as to the number of DNS servers that are vulnerable to the various exploits. Ask people who do network scanning to provide some statistics on what they see and scale them up according to the number of hosts in the host-count database. For example, assume that someone has scanned N hosts and discovers that N/10 are running BIND and that 40% of those are vulnerable. Also assume that the hostcount shows 20 million hosts in the world. Infer from this that there are 2 million BIND servers and that there are 800,000 vulnerable ones. But do the calculations with some real data, not my example figures. b. Write a press release with the following headline: N Thousand Internet Servers Suffer Same Fate as Iraqi Server Or maybe write some variation on this but keep it scary and keep Iraq in the headline. The body of the press release should explain the attacks that the Iraqi server was suffering from, then point out how many other servers are also vulnerable and then point out how terrorists could use these vulnerabilities against us. If you can, name some specific organizations where you know the vulnerability exists. Pick a large organization or two that has many nameservers and the vulnerability exists in some obscure corner of the organization, not on their main nameservers. They really can't sue over this because you haven't damaged them by disclosing enough detail for an attacker to use. c. release to both the national press and the computer/network trade press. That's how you get people's attention and that's also how the clueful technical people get the authority and funding to go in and fix the vulnerable boxes. As long as we continue to play games and pretend that Internet operations is still the old boys club that it once was, we will continue to suffer from these nagging issues. People on the NANOG mailing list do not run the Internet anymore. NANOG's market share of network operations people has been steadily shrinking as the Internet has grown. This may still be the moist clueful gathering place, but there are an awful lot of people out there today designing, building and operating networks, who have never heard of NANOG. There is no universal forum anymore. The Internet isn't special anymore. --Michael Dillon
Re: how to get people to upgrade? (Re: The weak link? DNS)
* [EMAIL PROTECTED] (Paul Vixie) [Wed 26 Mar 2003, 16:24 CET]: > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). So how much would this differ from `make install' running this shell script? --- cat
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 08:31:40 -0800, Bill Woodcock said: > > On 26 Mar 2003, Jeffrey C. Ollie wrote: > > What I would like to see is somewhat of the idea in > > reverse. The ISC would host a zone that would contain TXT records with > > security/bug advisories for every version: > > I really like this solution. It seems clean and unobjectionable, while > getting the job done. Plus, it is expandable to other common services that might want this service, like sendmail or OpenSSH.
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 26 Mar 2003, Jeffrey C. Ollie wrote: > What I would like to see is somewhat of the idea in > reverse. The ISC would host a zone that would contain TXT records with > security/bug advisories for every version: I really like this solution. It seems clean and unobjectionable, while getting the job done. -Bill
opentrasit.net problem?
we are AS 16592 (168.243.224.0/20) and are having problem reaching 168.234.136.0/24 the problem is very erratic, sometime we can reach them sometimes not (for a 10-30 seconds period). problem arise from an opentransit.net hop as seen in the following trace: 1<1 ms<1 ms<1 ms 205.235.28.65 2<1 ms<1 ms<1 ms 205.235.28.34 3 1 ms 1 ms 1 ms 205.235.28.45 4 1 ms 1 ms 1 ms 168.243.227.165 5 3 ms 3 ms 3 ms 168.243.227.135 612 ms 6 ms10 ms 200.12.61.193 7 195 ms 150 ms90 ms 200.30.154.29 8 185 ms 186 ms 241 ms 200.30.154.41 9 291 ms 200 ms 109 ms 144.223.244.5 1056 ms54 ms42 ms 144.232.20.17 11 125 ms85 ms82 ms 193.251.252.25 12 *** Request timed out. 13 *** Request timed out. 14 ** 146 ms 168.234.181.6 15 347 ms ^C hop 11 is So5-0-0.MIABB1.Miami.opentransit.net and hop 12 is TelecomElSalvador-OsiGuat.GW.opentransit.net is opentransit.net present on NANOG? please contact me off-list. -- Miguel Mata-Cardona Intercom El Salvador [EMAIL PROTECTED]
Re: how to get people to upgrade? (Re: The weak link? DNS)
On Wed, 2003-03-26 at 09:24, Paul Vixie wrote: > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. > > [...] > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). I would not use such a feature, and I suspect that most people who would use such a feature would not have a clue that it was there or how to turn it on. What I would like to see is somewhat of the idea in reverse. The ISC would host a zone that would contain TXT records with security/bug advisories for every version: $ORIGIN . security-notice.bindIN SOA ns.isc.org. postmaster.isc.org. 1 72003600604800 3600 $ORIGIN security-notice.bind. 8.3.3 IN TXT "Name: BIND: Multiple Denial of Service [yadda yadda yadda...]" 4.9.10 IN TXT "Name: LIBRESOLV: buffer overrun [yadda yadda yadda...]" yadda yadda yadda... Ideally the zone would be DNSSEC signed as well. Then, by default, BIND would query the zone periodically (perhaps every 24 hours or so) for it's version. If any records are found it would log a message and/or send email to [EMAIL PROTECTED], which would be repeated periodically (I'd log a message every time that a check was performed, but I'd only email once a week). There would be config options so that the clueful admin could customize/disable this behavior to his or her liking. This way no one would be collecting a central database of email addresses, but everyone would get notified of security advisories in a timely manner. Jeff
suggestion for IBX in Washington DC
I need a recommendation for an IBX/colo environment located in the city of Washington DC itself.. I know Tyson/McLean is Paradise but looking for a good solution actually IN the DC portion of lata 236 Our main goals are Transit availability from good providers (Worldcom is a must) and good peering options -Scotty
Re: Domain oddity - possibly early warning...
On Tue, 25 Mar 2003, Rodney Joffe wrote: > We've noticed something we've never noticed before that became evident > at 14:00 today... and which could be an isolated glitch at > Verisign/Netsol, or it could be a sign of a larger problem looming. Or perhaps it could be the result of perfectly normal operations. > The domain utclassifieds.com is answered as NXDOMAIN in the > gtld-servers. [dig output deleted] > However it has a whois record at networksolutions, but it has no > nameservers in the whois record. And the domain is valid and expires in > July 2003. This behavior is normal. The owning registrar for this domain, Network Solutions, removed both name servers during the evening (EST) of 24 March. A domain with no name servers is a legal state in the com/net registry database. In such a case, however, the domain does not appear in the com/net zones. (How could it--it has no name servers.) The domain was again modified during the evening (EST) of 25 March, when two name servers were added. It was therefore included in the com zone with SOA serial 2003032600. This is a good opportunity to point out the separation between VeriSign Global Registry Services (VGRS), the registry for com/net, and the various ICANN-accredited registrars, including Network Solutions. VGRS makes whatever changes requested by registrars to domains they own. In this case, we just see that the name servers were removed and re-added a day later. Presumably Network Solutions took this action based on customer instructions, but you'd have to ask them. Matt -- Matt Larson <[EMAIL PROTECTED]> VeriSign Global Registry Services
Re: how to get people to upgrade? (Re: The weak link? DNS)
Thinking about it again, this would have additional advantage of collecting statistics at where bind is being used (you get ips of the servers) and what versions they are running. So even if they did not update the software, you can still find out where they are by ip address and if situation is very very serious, some kind of proactive contact option would still be available. On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote: > Personaly I'v not looked favorably at given my email to various lists, > although its probably way too late and everyone by now has it... > > 1. I have another idea though, during setup of the server ask for email > address of list administrator, but keep that on the server itself. > 2. Setup some dns server that provides dns record if there are necessary > updates (here is one example in reverse dns notation...: > 1.2.9.bind.updates.isc.org and set it to particular ip or > particular MX or whatever to show if update is needed). > Possibly have this special update dns recorb be HINFO to url where more > information on update is available. > 3. When bind starts if the record in #2 exists and shows that update is > necessary, have bind server email to address entered in 1 and with > abscense of that have it email to [EMAIL PROTECTED] and if HINFO > exists, it can take that and enter this as custome email. > > The above also makes it unnecessary for ISC to maintain that huge email > database or email everybody (and probably get bunch of people angry at you > for spamming...). Anyway just a thought... > > On 26 Mar 2003, Paul Vixie wrote: > > > > > [EMAIL PROTECTED] (Sean Donelan) writes: > > > > > What even stranger about the Iraqi state provider Uruklink.net is the DNS > > > servers are now self-identifying with earlier (with known bugs) versions > > > of BIND. Last week the Uruklink name server 62.145.94.1 was running > > > 8.2.2-P5, but now is running 8.1.2. ... > > > > at http://www.isc.org/products/BIND/bind-security.html we see: > > > > Name: "BIND: Remote Execution of Code" > > [Added 11.12.2002] > > Versions affected: BIND 4.9.5 to 4.9.10 > > BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 > > Severity: SERIOUS > > Exploitable: Remotely > > Type: Possibility to execute arbitrary code. > > Description: > > > > When constructing a response containing SIG records a incorrect > > space allows a write buffer overflow. It is then possible to > > execute code with the privileges of named. > > > > the list goes on. i'm sure several folks will use this as an opportunity to > > hawk their own alternative non-BIND DNS solution, i wish you well except plz > > change the Subject: header on your reply since what i really want to talk > > about is: how to get people to upgrade their software when defects are found. > > > > sending out announcements through CERT and the bind-announce m/l isn't working. > > > > so here's a proposal. we (speaking for ISC here) could add a config option > > (default to OFF) to make bind send some kind of registration packet at boot > > time, containing an e-mail address for a technical contact for that server, > > and perhaps its hostname as well. the destination would be configurable, and > > the format would be open, and we would include in the distribution a tool > > capable of catching these. any campus/WAN admin who wanted to run their own > > "BIND registration system" could do so. anyone who wanted to simply config > > their server to send registration data to ISC could do so. for data received > > at ISC, we'd (a) keep it completely private other than public statistics, > > (b) clean it of obvious trash (some people will sent registration data for > > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > > information only in the event that a security defect discovered in that > > version. remember, the default would be OFF. > > > > given such a feature, whose default was OFF, would anyone here who uses > > BIND stop using it out of protest? if so plz answer publically (on nanog). > > > > given such a feature, would anyone here create their own registration system > > so they had their own database of local BIND instances on their campus/WAN, > > or would anyone here config their servers to send registration data to ISC? > > if so plz answer privately (i'll summarize to the list.) >
Re: The weak link? DNS
In a message written on Wed, Mar 26, 2003 at 04:09:06AM -0500, Sean Donelan wrote: > For example, Al Jazeera had time-to-live set of their domain records set > to 15 minutes, making them even more vulnerable to increasing the load > on their systems. Of course, Al Jazeera had other problems too. This is very much a double edged sword. If they decided to add more servers, or Akamize, or set up traditional mirrors a long TTL would have prevented a large number of people from using them as ISP's continued to serve up cached entries. Imagine not being able to get new servers properly loaded for a week if you followed more traditional TTL guidelines. For web content, I would recomend a TTL approximately equal to the longest you would expect a single user to view your web site. Worst case, if every user had to ask your DNS servers directly, would then be one query for every web visitor. Given that there will be caching at larger ISP's and the like it will actually be even less. If you can scale your web infrastructure to serve the pages to that number of users, scaling DNS to answer one query for each one of those users should be a trivial exercise. In addition to making it easier to change the service on the fly and have those changes take effect, it also makes it easier on smaller companies that cache content. How many small ISP's or corporate caching servers keep entries around for a week or more when one person spent 10 minutes at one site? The shorter TTL allows these boxes to get rid of the junk entries much faster. Depending on your web content I'd recommend 15 minute to 1 hour TTL values. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: how to get people to upgrade? (Re: The weak link? DNS)
Personaly I'v not looked favorably at given my email to various lists, although its probably way too late and everyone by now has it... 1. I have another idea though, during setup of the server ask for email address of list administrator, but keep that on the server itself. 2. Setup some dns server that provides dns record if there are necessary updates (here is one example in reverse dns notation...: 1.2.9.bind.updates.isc.org and set it to particular ip or particular MX or whatever to show if update is needed). Possibly have this special update dns recorb be HINFO to url where more information on update is available. 3. When bind starts if the record in #2 exists and shows that update is necessary, have bind server email to address entered in 1 and with abscense of that have it email to [EMAIL PROTECTED] and if HINFO exists, it can take that and enter this as custome email. The above also makes it unnecessary for ISC to maintain that huge email database or email everybody (and probably get bunch of people angry at you for spamming...). Anyway just a thought... On 26 Mar 2003, Paul Vixie wrote: > > [EMAIL PROTECTED] (Sean Donelan) writes: > > > What even stranger about the Iraqi state provider Uruklink.net is the DNS > > servers are now self-identifying with earlier (with known bugs) versions > > of BIND. Last week the Uruklink name server 62.145.94.1 was running > > 8.2.2-P5, but now is running 8.1.2. ... > > at http://www.isc.org/products/BIND/bind-security.html we see: > > Name: "BIND: Remote Execution of Code" > [Added 11.12.2002] > Versions affected: BIND 4.9.5 to 4.9.10 > BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 > Severity: SERIOUS > Exploitable: Remotely > Type: Possibility to execute arbitrary code. > Description: > > When constructing a response containing SIG records a incorrect > space allows a write buffer overflow. It is then possible to > execute code with the privileges of named. > > the list goes on. i'm sure several folks will use this as an opportunity to > hawk their own alternative non-BIND DNS solution, i wish you well except plz > change the Subject: header on your reply since what i really want to talk > about is: how to get people to upgrade their software when defects are found. > > sending out announcements through CERT and the bind-announce m/l isn't working. > > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. > > given such a feature, whose default was OFF, would anyone here who uses > BIND stop using it out of protest? if so plz answer publically (on nanog). > > given such a feature, would anyone here create their own registration system > so they had their own database of local BIND instances on their campus/WAN, > or would anyone here config their servers to send registration data to ISC? > if so plz answer privately (i'll summarize to the list.)
Re: how to get people to upgrade? (Re: The weak link? DNS)
On 3/26/2003 at 15:24:18 +, Paul Vixie said: [snip] > so here's a proposal. we (speaking for ISC here) could add a config option > (default to OFF) to make bind send some kind of registration packet at boot > time, containing an e-mail address for a technical contact for that server, > and perhaps its hostname as well. the destination would be configurable, and > the format would be open, and we would include in the distribution a tool > capable of catching these. any campus/WAN admin who wanted to run their own > "BIND registration system" could do so. anyone who wanted to simply config > their server to send registration data to ISC could do so. for data received > at ISC, we'd (a) keep it completely private other than public statistics, > (b) clean it of obvious trash (some people will sent registration data for > [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact > information only in the event that a security defect discovered in that > version. remember, the default would be OFF. I'm not sure this helps. The people who don't subscribe or pay attention to CERT advisories are the same ones that won't turn this option on. It is like the cache option in Apache; the people who would get the most benefit, the ones with mainly static web pages, are the same ones who do not know to turn it on. -Dave
how to get people to upgrade? (Re: The weak link? DNS)
[EMAIL PROTECTED] (Sean Donelan) writes: > What even stranger about the Iraqi state provider Uruklink.net is the DNS > servers are now self-identifying with earlier (with known bugs) versions > of BIND. Last week the Uruklink name server 62.145.94.1 was running > 8.2.2-P5, but now is running 8.1.2. ... at http://www.isc.org/products/BIND/bind-security.html we see: Name: "BIND: Remote Execution of Code" [Added 11.12.2002] Versions affected: BIND 4.9.5 to 4.9.10 BIND 8.1, 8.2 to 8.2.6, 8.3.0 to 8.3.3 Severity: SERIOUS Exploitable: Remotely Type: Possibility to execute arbitrary code. Description: When constructing a response containing SIG records a incorrect space allows a write buffer overflow. It is then possible to execute code with the privileges of named. the list goes on. i'm sure several folks will use this as an opportunity to hawk their own alternative non-BIND DNS solution, i wish you well except plz change the Subject: header on your reply since what i really want to talk about is: how to get people to upgrade their software when defects are found. sending out announcements through CERT and the bind-announce m/l isn't working. so here's a proposal. we (speaking for ISC here) could add a config option (default to OFF) to make bind send some kind of registration packet at boot time, containing an e-mail address for a technical contact for that server, and perhaps its hostname as well. the destination would be configurable, and the format would be open, and we would include in the distribution a tool capable of catching these. any campus/WAN admin who wanted to run their own "BIND registration system" could do so. anyone who wanted to simply config their server to send registration data to ISC could do so. for data received at ISC, we'd (a) keep it completely private other than public statistics, (b) clean it of obvious trash (some people will sent registration data for [EMAIL PROTECTED] just for fun; we know that), and (c) use the contact information only in the event that a security defect discovered in that version. remember, the default would be OFF. given such a feature, whose default was OFF, would anyone here who uses BIND stop using it out of protest? if so plz answer publically (on nanog). given such a feature, would anyone here create their own registration system so they had their own database of local BIND instances on their campus/WAN, or would anyone here config their servers to send registration data to ISC? if so plz answer privately (i'll summarize to the list.) -- Paul Vixie
The weak link? DNS
Watching the Iraqi Ururklink and Al Jazeera over the weekend what struck me is how many different ways network administrators can mess up. Although malicious actors have been trying (and succeeding) to exploit vulnerabilities, the worst problems seem to be self-inflicted. Administrators had used firewalls and locked down their web sites, sometimes so well they couldn't handle the traffic load. But the real weak link was their DNS servers. For example, Al Jazeera had time-to-live set of their domain records set to 15 minutes, making them even more vulnerable to increasing the load on their systems. Of course, Al Jazeera had other problems too. What even stranger about the Iraqi state provider Uruklink.net is the DNS servers are now self-identifying with earlier (with known bugs) versions of BIND. Last week the Uruklink name server 62.145.94.1 was running 8.2.2-P5, but now is running 8.1.2. Although the web site for www.uruklink.net is up, DNS lookups for www.uruklink.net return various other IP addresses (not in 62.145.94.0/24). Including some addresses running web sites claiming the site is "owned." In reality, the site isn't owned, you are being redirected to a unrelated web site.
