- Test - lists.nanog.org

San Diego Colocation
by Steve Rude 02 Oct '02

02 Oct '02

I'm looking for carrier neutral colo in San Diego. We are a wireless isp, and will need rooftop rights. Any advice/experiences would be appreciated. Specifically we are interested in thoughts on Switch and Data, and ClearBlue. TIA. Steve Rude

1 0

Re: Security Practices question
by Scott Francis 02 Oct '02

02 Oct '02

On Tue, Oct 01, 2002 at 02:43:41PM -0700, kent(a)songbird.com said: [snip] > On Mon, Sep 23, 2002 at 02:44:34PM -0700, Scott Francis wrote: > > On Sun, Sep 22, 2002 at 03:22:11PM -0700, john(a)chagresventures.com said: > > > > > > I have question for the security community on NANOG. > > > > > > What is your learned opinion of having host accounts > > > (unix machines) with UID/GID of 0:0 > > > > > > otherwords > > > > > > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh > > > > > > The argument is that way you don't hav to give out the root password, > > > you can just nuke a users UID=0 equiv account when the leave and not > > > have to change the real root account. > > > > This is a really /really/ REALLY bad idea. I had nightmare issues dealing > > with a network formerly run by a 'sysadmin' who thought every user that > > might need to do something as root should have a uidzero account. > > That's not the issue, however. > > The assumption is that you have several people who really are fully > qualified admins on the system in question, who really do need full > privileged access. The choice John describes is between giving these > trusted sysadmins the password for "root", or giving them (and them > alone) a UID 0 account as he describes (except that one would of course > use shadow passwords etc.) Wrong. The choice here is between having one password for the account with uid zero, and having multiple, equally valid passwords for that same account. This is an abysmally bad idea, and shame on anybody that encourages it. See Barb Dijker's reply in this thread for more details on why. > To put it in other terms, the choice being presented is between several > fully authorized sys admins sharing a single password for "root", or for > each of them to have a unique password, known only to them and shared > with nobody. These are the people who would have full privileged access > on the machine in any circumstance; the only issue is how they get that > access. Still wrong - with multiple entries in /etc/passwd sharing a single UID, you end up with multiple passwords for the same exact user, as far as the system is concerned. The name placed with that user id is strictly a human convention - to the system, it's all the same user, multiple aliases notwithstanding. > In my past life working in a classified research facility, the following > policy was strictly enforced: every sysadmin had a user level account > and a root-equivalent account, and all normal work was done from the > user-level account; direct logins to the root-equivalent account were > disabled, so under normal circumstances the only means of getting uid 0 > access was through a user level login followed by an su to a unique > account; the password for "root" was locked in a vault, and could only which was a waste of time - every account with a UID of zero already HAD a password for root. In the case mentioned, root had not one but one + (number of non-root uid zero accounts) passwords, all equally valid. (Unless of course the system in question was running some bizarre version of UNIX dissimilar to every other I have seen.) > be retrieved in an emergency via a signout procedure, after which the > password was changed and a new one was put in the vault -- in practice > nobody used the "root" account for any purpose, except in emergencies. > In this environment sudo was used heavily, as well -- these > root-equivalent accounts were only for the sysadmins who had full access > to the system -- there were other admins who used sudo to handle many > routine system management tasks. There is no reason to have multiple UID zero accounts. In the very best of scenarios, it's a horrible kludge and an excuse for lazy admins to avoid using sudo properly. That's in the _best_ of scenarios. > This policy was arrived at after a lot of discussion, and it provides > some significant advantages. Most importantly, it allowed much better I would _love_ to hear what advantages this provided. > management of privileged access: in a large facility systems get added > and modified frequently, sysadmins change responsibilities, emergencies > happen; and you can very easily get to a point where it is hard to know > just who currently has the password to the username "root" account. Every individual with an account that has a uid of zero had the root password. Again, see Barb Dijker's mail for more on this. > (Fundamentally, all the arguments agains normal users sharing passwords > apply with even more force to passwords for privileged accounts.) Absolutely so - which is why no account should have multiple equally valid passwords, which is what multiple accounts sharing a uid equates to. Use sudo, use ssh keys from a central admin host, use ACLs - use whatever you like, but please don't create multiple aliases for an account and think it's anything but an invitation to disaster. > Kent -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui

1 0

Re: Security Practices question
by Scott Francis 02 Oct '02

02 Oct '02

On Tue, Oct 01, 2002 at 02:43:41PM -0700, kent(a)songbird.com said: [snip] > > > I have question for the security community on NANOG. > > > > > > What is your learned opinion of having host accounts > > > (unix machines) with UID/GID of 0:0 > > > > > > otherwords > > > > > > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh > > > > > > The argument is that way you don't hav to give out the root password, > > > you can just nuke a users UID=0 equiv account when the leave and not > > > have to change the real root account. > > > > This is a really /really/ REALLY bad idea. I had nightmare issues dealing > > with a network formerly run by a 'sysadmin' who thought every user that > > might need to do something as root should have a uidzero account. > > That's not the issue, however. > > The assumption is that you have several people who really are fully > qualified admins on the system in question, who really do need full > privileged access. The choice John describes is between giving these > trusted sysadmins the password for "root", or giving them (and them > alone) a UID 0 account as he describes (except that one would of course > use shadow passwords etc.) Wrong. The choice is between having a single password for the user with id 0, and having multiple passwords for that same account. This is an abysmally bad idea, and shame on anybody encouraging it. See > > To put it in other terms, the choice being presented is between several > fully authorized sys admins sharing a single password for "root", or for > each of them to have a unique password, known only to them and shared > with nobody. These are the people who would have full privileged access > on the machine in any circumstance; the only issue is how they get that > access. > > In my past life working in a classified research facility, the following > policy was strictly enforced: every sysadmin had a user level account > and a root-equivalent account, and all normal work was done from the > user-level account; direct logins to the root-equivalent account were > disabled, so under normal circumstances the only means of getting uid 0 > access was through a user level login followed by an su to a unique > account; the password for "root" was locked in a vault, and could only > be retrieved in an emergency via a signout procedure, after which the > password was changed and a new one was put in the vault -- in practice > nobody used the "root" account for any purpose, except in emergencies. > In this environment sudo was used heavily, as well -- these > root-equivalent accounts were only for the sysadmins who had full access > to the system -- there were other admins who used sudo to handle many > routine system management tasks. > > This policy was arrived at after a lot of discussion, and it provides > some significant advantages. Most importantly, it allowed much better > management of privileged access: in a large facility systems get added > and modified frequently, sysadmins change responsibilities, emergencies > happen; and you can very easily get to a point where it is hard to know > just who currently has the password to the username "root" account. > (Fundamentally, all the arguments agains normal users sharing passwords > apply with even more force to passwords for privileged accounts.) > > Kent -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui

1 1

Toolmakers BOF in Eugene
by Joe Abley 02 Oct '02

02 Oct '02

Hi, We're trying to assemble a small herd of script hackers in Eugene in the form of a BOF. If anybody has interesting tools they use to wrangle routers (or interesting problems that can currently only be solved by hand, for which automated solutions would be useful), want to drop me a line and tell me about them? Maybe I can spot some common requests and match them up with some neat solutions, and give the BOF a little kick start. [Note! this is not a sales forum for anybody selling network management software. People selling management software are overwhelmingly welcome to come along and listen, though, if they want to find out how people use software to manage networks in real life] Replies off-list would be good. Thanks :) http://www.nanog.org/mtg-0210/ableybof.html > The software engineering process lends itself well to large, > well-managed, multi-disciplinary teams producing well-defined products > in response to detailed requirements analysis. As much fun as that > sounds, sometimes what you really need is a short and simple answer to a > short and simple question, preferably now. > > The business of daily operations at almost every service provider > depends on the existence of a herd of small, single-use scripts designed > to emulate in a few seconds work that a human operator might take a > couple of hours to do. The focus of these tools is usefulness in the > hands of a network operator over engineering purity or elegance in > design. > > Questions that are readily answered by the judicious application of a > small pile of scripts include: > > # What BGP sessions have gone down in the last hour? > # What routers rebooted in the last five minutes? > # What filters are defined, but not used? > # What filters are used, but not defined? > # What interfaces have been admin shutdown for over a month? > # Who just tripped their maximum-prefix limits? > > This BOF is a place for toolmakers to meet other toolmakers, and to > exchange ideas, code, and horror stories.

1 0

NANOG 26 Misc.
by Carol Wadsworth 02 Oct '02

02 Oct '02

For those of you registered to attend NANOG 26 in Eugene, Oregon, please note the following upcoming deadlines: October 5 -- hotel room block rate expires http://www.nanog.org/mtg-0210/hotel.html October 11 -- registration fee due To check your payment status see: http://www.nanog.org/mtg-0210/attendee.list.html For additional meeting information, please see: Presentation Topics: http://www.nanog.org/mtg-0210/topics.html Registration: https://www.merit.edu/nanog/registration.form.html Meeting Info: http://www.nanog.org/mtg-0210/index.html Hope to see you there!

1 0

Bob on SPAM
by Bob Martinez 02 Oct '02

02 Oct '02

NANOG: Since Ethernet strings die, I give you my opinion of how to stop SPAM. We shall let Ethernet defend for itself for now. It is doing fine w/o my help. Mail Adminstrators need to have peering policies. Traffic Adminstrators need to have traffic policies. Processes beget policies. These policies need to be enforced by protocols. If two peers are authenticated as valid communications agents by the mail transfer protocol, they should be given a higher thread of priority than random email by someone telneting to the server (ex.). As with PIM Snooping, Ethernet based networks can easily snoop this activity (authenticated traffic) and deny it at wirespeed as close the source as you dare go (domain). These service could easily be positioned in the core if you are already pumping the packets to an FPGA. Going to an ASIC may be a bit more difficult. 10G is an FPGA. Bobby _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 1

Re: Re: Root DNS Server Issues?
by John Neiberger 02 Oct '02

02 Oct '02

We're getting responses from the root servers, the names just aren't resolving. From a windows NT machine the error is "Non- existent Domain". Ah, I just noticed something. The packet length for the DNS response is supposed to be 510 bytes but it's being truncated to 128. What the heck would cause that?? John ---- On Tue, 1 Oct 2002, John M. Brown (john(a)chagresventures.com) wrote: > > > Here is for L, F also seems to reply. Tested from 8 different > places on the net. OTW Transit splay on the test was 8 different > providers. > > > > Can you give a sample of the "errors" you are seeing? > > Got a sample DIG line ?? > > John Brown > Le Geek > > > > %dig @l.root-servers.net com ns > > ; <<>> DiG 8.3 <<>> @l.root-servers.net com ns > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 > ;; QUERY SECTION: > ;; com, type = NS, class = IN > > ;; ANSWER SECTION: > com. 2D IN NS L.GTLD-SERVERS.NET. > com. 2D IN NS F.GTLD-SERVERS.NET. > com. 2D IN NS J.GTLD-SERVERS.NET. > com. 2D IN NS K.GTLD-SERVERS.NET. > com. 2D IN NS E.GTLD-SERVERS.NET. > com. 2D IN NS M.GTLD-SERVERS.NET. > com. 2D IN NS A.GTLD-SERVERS.NET. > com. 2D IN NS G.GTLD-SERVERS.NET. > com. 2D IN NS H.GTLD-SERVERS.NET. > com. 2D IN NS C.GTLD-SERVERS.NET. > com. 2D IN NS I.GTLD-SERVERS.NET. > com. 2D IN NS B.GTLD-SERVERS.NET. > com. 2D IN NS D.GTLD-SERVERS.NET. > > ;; ADDITIONAL SECTION: > L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 > F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 > J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 > K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 > E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 > M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 > A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 > G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 > H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 > C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 > I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 > B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 > D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 > > ;; Total query time: 89 msec > ;; FROM: jedi.staff.chagres.net to SERVER: l.root- servers.net 198.32.64.12 > ;; WHEN: Tue Oct 1 17:29:36 2002 > ;; MSG SIZE sent: 21 rcvd: 453 > > % > On Tue, Oct 01, 2002 at 07:08:37PM -0400, John Neiberger wrote: > > > > We seem to be getting name resolution errors when we query any > > of the root servers, and this just started a hour or so ago. > > > > Anyone else noticing a problem? > > > > John > >

6 6

Re: Re: Root DNS Server Issues?
by John Neiberger 02 Oct '02

02 Oct '02

Forgive me for being a DNS clunkhead. <g> I honestly don't know much about it, but I thought I'd post this to the list because it did appear to be a problem with the root servers, which would be A Bad Thing (tm). Probable dumb question: if I do an nslookup from a desktop directed at a root server, should the name eventually resolve? Or, is a request to a root server from our DNS server a different kind of request? I have a feeling it is and that I'm barking up the wrong tree. That might explain why an nslookup directed at someone else's name server is working. Still, that would lead us back to the original problem. Our DNS server can't communicate with the root servers. Hmm.. Again, I apologize for being a total noob at this. I believe that I'm misunderstanding the symptoms and using the wrong tools to troubleshoot! Thanks to all, John ---- On Tue, 1 Oct 2002, John M. Brown (john(a)chagresventures.com) wrote: > Root servers don't resolve names other than the TLD's. > > OTW they don't have data for www.yahoo.com only for .com > which will point you towards the gTLD servers (listed below) > which will point you towards Yahoo's name servers. > > What names are you trying to lookup ? > > John Brown > Le Geek > > > On Tue, Oct 01, 2002 at 07:46:00PM -0400, John Neiberger wrote: > > We're getting responses from the root servers, the names just > > aren't resolving. From a windows NT machine the error is "Non- > > existent Domain". > > > > Ah, I just noticed something. The packet length for the DNS > > response is supposed to be 510 bytes but it's being truncated > > to 128. What the heck would cause that?? > > > > John > > > > ---- On Tue, 1 Oct 2002, John M. Brown > > (john(a)chagresventures.com) wrote: > > > > > > > > > > > Here is for L, F also seems to reply. Tested from 8 different > > > places on the net. OTW Transit splay on the test was 8 > > different > > > providers. > > > > > > > > > > > > Can you give a sample of the "errors" you are seeing? > > > > > > Got a sample DIG line ?? > > > > > > John Brown > > > Le Geek > > > > > > > > > > > > %dig @l.root-servers.net com ns > > > > > > ; <<>> DiG 8.3 <<>> @l.root-servers.net com ns > > > ; (1 server found) > > > ;; res options: init recurs defnam dnsrch > > > ;; got answer: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > > > ;; flags: qr rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, > > ADDITIONAL: 13 > > > ;; QUERY SECTION: > > > ;; com, type = NS, class = IN > > > > > > ;; ANSWER SECTION: > > > com. 2D IN NS L.GTLD- SERVERS.NET. > > > com. 2D IN NS F.GTLD- SERVERS.NET. > > > com. 2D IN NS J.GTLD- SERVERS.NET. > > > com. 2D IN NS K.GTLD- SERVERS.NET. > > > com. 2D IN NS E.GTLD- SERVERS.NET. > > > com. 2D IN NS M.GTLD- SERVERS.NET. > > > com. 2D IN NS A.GTLD- SERVERS.NET. > > > com. 2D IN NS G.GTLD- SERVERS.NET. > > > com. 2D IN NS H.GTLD- SERVERS.NET. > > > com. 2D IN NS C.GTLD- SERVERS.NET. > > > com. 2D IN NS I.GTLD- SERVERS.NET. > > > com. 2D IN NS B.GTLD- SERVERS.NET. > > > com. 2D IN NS D.GTLD- SERVERS.NET. > > > > > > ;; ADDITIONAL SECTION: > > > L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 > > > F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 > > > J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 > > > K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 > > > E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 > > > M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 > > > A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 > > > G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 > > > H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 > > > C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 > > > I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 > > > B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 > > > D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 > > > > > > ;; Total query time: 89 msec > > > ;; FROM: jedi.staff.chagres.net to SERVER: l.root- > > servers.net 198.32.64.12 > > > ;; WHEN: Tue Oct 1 17:29:36 2002 > > > ;; MSG SIZE sent: 21 rcvd: 453 > > > > > > % > > > On Tue, Oct 01, 2002 at 07:08:37PM -0400, John Neiberger > > wrote: > > > > > > > > We seem to be getting name resolution errors when we query > > any > > > > of the root servers, and this just started a hour or so ago. > > > > > > > > Anyone else noticing a problem? > > > > > > > > John > > > > > > > > > >

2 1

Re: Re: Root DNS Server Issues?
by John Neiberger 02 Oct '02

02 Oct '02

---- On Tue, 1 Oct 2002, Adam McKenna (adam-nanog(a)flounder.net) wrote: > > On Tue, Oct 01, 2002 at 07:46:00PM -0400, John Neiberger wrote: > > > > We're getting responses from the root servers, the names just > > aren't resolving. From a windows NT machine the error is "Non- > > existent Domain". > > You still haven't told us what you are trying to look up and what exact error > you are getting. > > Until you do that, nobody is going to be able to provide you with any kind of > real answer. > > --Adam > This was my mistake. My desktop was sending out a request that didn't get a valid response, so it then sent a second request with out internal domain appended to the original request and *that* is what generated an actual error. So, we're not getting a specific error response, it's just that the responses are being truncated to 128 bytes even though the IP header says that they all should be longer. I think this is occurring because I'm being a dork and trying to do an nslookup on a root server and they're not designed for that. An nslookup directed at another ISP's name server seems to work just fine so the problem must lie in our own DNS server. Nothing was changed recently and that is the perplexing issues. It just appeared that it couldn't reach any of the root servers, so we--being unwashed and unschooled--went barking up the wrong tree. My apologies, and I'll get back to hounding our DNS admin. :-0 Thanks, John

1 0

Re: Re: Root DNS Server Issues?
by John Neiberger 01 Oct '02

01 Oct '02

Okay, nevermind. Even the valid responses from another ISP's domain server are being 'sliced', yet we get valid responses. None of the responses from the root servers contain a valid name resolution. John ---- On Tue, 1 Oct 2002, John Neiberger (neiby(a)ureach.com) wrote: > > We're getting responses from the root servers, the names just > aren't resolving. From a windows NT machine the error is "Non- > existent Domain". > > Ah, I just noticed something. The packet length for the DNS > response is supposed to be 510 bytes but it's being truncated > to 128. What the heck would cause that?? > > John > > ---- On Tue, 1 Oct 2002, John M. Brown > (john(a)chagresventures.com) wrote: > > > > > > > Here is for L, F also seems to reply. Tested from 8 different > > places on the net. OTW Transit splay on the test was 8 > different > > providers. > > > > > > > > Can you give a sample of the "errors" you are seeing? > > > > Got a sample DIG line ?? > > > > John Brown > > Le Geek > > > > > > > > %dig @l.root-servers.net com ns > > > > ; <<>> DiG 8.3 <<>> @l.root-servers.net com ns > > ; (1 server found) > > ;; res options: init recurs defnam dnsrch > > ;; got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > > ;; flags: qr rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, > ADDITIONAL: 13 > > ;; QUERY SECTION: > > ;; com, type = NS, class = IN > > > > ;; ANSWER SECTION: > > com. 2D IN NS L.GTLD-SERVERS.NET. > > com. 2D IN NS F.GTLD-SERVERS.NET. > > com. 2D IN NS J.GTLD-SERVERS.NET. > > com. 2D IN NS K.GTLD-SERVERS.NET. > > com. 2D IN NS E.GTLD-SERVERS.NET. > > com. 2D IN NS M.GTLD-SERVERS.NET. > > com. 2D IN NS A.GTLD-SERVERS.NET. > > com. 2D IN NS G.GTLD-SERVERS.NET. > > com. 2D IN NS H.GTLD-SERVERS.NET. > > com. 2D IN NS C.GTLD-SERVERS.NET. > > com. 2D IN NS I.GTLD-SERVERS.NET. > > com. 2D IN NS B.GTLD-SERVERS.NET. > > com. 2D IN NS D.GTLD-SERVERS.NET. > > > > ;; ADDITIONAL SECTION: > > L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 > > F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 > > J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 > > K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 > > E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 > > M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 > > A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 > > G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 > > H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 > > C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 > > I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 > > B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 > > D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 > > > > ;; Total query time: 89 msec > > ;; FROM: jedi.staff.chagres.net to SERVER: l.root- > servers.net 198.32.64.12 > > ;; WHEN: Tue Oct 1 17:29:36 2002 > > ;; MSG SIZE sent: 21 rcvd: 453 > > > > % > > On Tue, Oct 01, 2002 at 07:08:37PM -0400, John Neiberger > wrote: > > > > > > We seem to be getting name resolution errors when we query > any > > > of the root servers, and this just started a hour or so ago. > > > > > > Anyone else noticing a problem? > > > > > > John > > > > > > >

1 0