Re: Upcoming change to SOA values in .com and .net zones
If they do this change, theyll break a tremendows number of systems around. - Original Message - From: Frank Louwers [EMAIL PROTECTED] To: Maarten Van Horenbeeck [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 3:38 PM Subject: Re: Upcoming change to SOA values in .com and .net zones On Wed, Jan 07, 2004 at 11:34:46PM +, Maarten Van Horenbeeck wrote: Hi Frank, Dag Maarten, stuid question, but isn't 2004010101 (today) 1076370400 (9 Feb 2004)? This doesn't apply here. It is perfectly possible to decrease the value of your serial number without any consequences for the DNS slave/master zone transfers, if you adhere to the procedures put forward in RFC 1912 (section 3.1). The fact that the newly introduced serial is lower will thus not have any consequences from this perspective. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? Oh, wait, right, they don't care if they break stuff... Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
Re: Upcoming change to SOA values in .com and .net zones
Alexei Roudnev writes on 1/8/2004 2:00 AM: If they do this change, theyll break a tremendows number of systems around. Like, for example? -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: Upcoming change to SOA values in .com and .net zones
I think, I should agree with Vixie - while all .com and .net servers are controlled by Verisign, and no other servers xfer this zones, the only thing which can break is some script which use SOA to determine, if 'com' was changed (which is unlikely case - I can not image any use for such script). - Original Message - From: Suresh Ramasubramanian [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: Frank Louwers [EMAIL PROTECTED]; Maarten Van Horenbeeck [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 11:04 PM Subject: Re: Upcoming change to SOA values in .com and .net zones Alexei Roudnev writes on 1/8/2004 2:00 AM: If they do this change, theyll break a tremendows number of systems around. Like, for example? -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: GSR, 7600, Juniper M?, oh my!
Hardware is probably cheaper on eBay than the maintenance fees anyway. You should be wary of purchasing second user Cisco equipment and their software license. Hardware is transferable but the Cisco software is not. Regards, Neil.
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 07:41:54PM -0500, Joe Abley [EMAIL PROTECTED] wrote a message of 16 lines which said: I didn't notice anybody saying thank you for doing the right thing by announcing the change amongst the flurry of jerking knees. So, thank you for doing the right thing. Good luck with the maintenance. And should we thank Verisign for doing for a very minor change what they did not do for a much more crucial change, their wildcards?
Re: Upcoming change to SOA values in .com and .net zones
On Wed, Jan 07, 2004 at 05:43:01PM -0800, Martin J. Levy [EMAIL PROTECTED] wrote a message of 9 lines which said: I believe there have been 26 (opps, now 27) responses to this announcement in the last 2 hours 45 minutes, that's about one response every 6 minutes. This is normal and reasonable sensitivity, taking into account the way Verisign handled the introduction of wildcards. For very minor changes, they tell the 200 technical zealots URL:http://www.redherring.com/Article.aspx?f=articles/2003/12/14c9995f-5557-4dc4-ad48-4548360c2095/14c9995f-5557-4dc4-ad48-4548360c2095.xml in advance. For important and sensitive changes, like the wildcards, they do not.
Re: Upcoming change to SOA values in .com and .net zones
At 00:01 08/01/2004, Ian Mason wrote: At Wed, 7 Jan 2004 17:46:23 -0500, Matt Larson wrote: VeriSign Naming and Directory Services will change the serial number format and minimum value in the .com and .net zones' SOA records on or shortly after 9 February 2004. [snip] But because these zones are widely used and closely watched, we want to let the Internet community know about the changes in advance. Matt, was it not possible for Verisign to give more than 30 hours notice of these changes? This is an Internet-wide change that will very likely break some systems somewhere. Surely more notice would have been reasonable. The notice actually given is so short as to be almost worthless. It might have raised Verisign's moral stock around here if more notice had been given, or even some consultation issued. As it is, Verisign seem to have moved in a way that, yet again, is likely to convince the community of Verisign's apparent arrogance and contempt towards the rest of us. Sad. Whoops, here I sit with egg on my face. My excuse for misreading the date was it was late in the day here after a busy evening. I unreservedly apologize for my haste in condemning Verisign and withdraw my remarks. I shall now go and penitentially stand in the very heavy rain and wind that England is enjoying today. Ian
RE: Upcoming change to SOA values in .com and .net zones
RFC 2182 Section 7 covers this as Randy Bush mentioned earlier.. If They do serial # updates, in a scripted manner or they just change the serial number to 4000 let it propagate and then change to 100 something all will be fine... The RFC above explains it well, no need to repost here Jim ... and not as MMDDHHMMSS or any contracted version thereof! Right, but, the _OLD_ format is. Therefore, the old zone file prior to the conversion will be SN 2004020800 through 2004020901. After the change, the SN will be in the range 1076284800 through 1076371200 inclusive. This complete range is less than 2004020800, so, the serial number will, indeed, be going backwards at the time of the change. This should only matter to things doing automated zone transfers and a forced manual zone transfer should solve the problem. Presumably, the responsible TLD operators are being coordinated with to take the necessary steps. Anyone else doing zone transfers of COM and NET has now been warned and should take appropriate action. Owen
Re: Upcoming change to SOA values in .com and .net zones
On Thu, Jan 08, 2004 at 11:24:33AM +0100, Stephane Bortzmeyer wrote: I didn't notice anybody saying thank you for doing the right thing by announcing the change amongst the flurry of jerking knees. So, thank you for doing the right thing. Good luck with the maintenance. And should we thank Verisign for doing for a very minor change what they did not do for a much more crucial change, their wildcards? Yes we should, and furthermore we should pull out heads OUT of our asses and stop being so holier-than-thou about it. Verisign is learning their lesson, and it might take a while yet, but yes you should be very grateful they gave you some notice. This community needs to work together, not apart. Verisign didn't do right last time, but they did this time. Drop the grudge, and give them a break. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only)
Re: Upcoming change to SOA values in .com and .net zones
On Thu, Jan 08, 2004 at 12:43:40PM +, Ian Mason wrote: Whoops, here I sit with egg on my face. My excuse for misreading the date was it was late in the day here after a busy evening. I unreservedly apologize for my haste in condemning Verisign and withdraw my remarks. I shall now go and penitentially stand in the very heavy rain and wind that England is enjoying today. I'll do the same (same weather in .be today :(() for irritating randy :) (Although I do know of some scripts that check the serial of the gltd servers for things like monitoring new domains, deletes,...) Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
RE: GSR, 7600, Juniper M?, oh my!
If you choose the 7600's I would highly recommend going with the Sup720's the price difference is not that great and they incorporate the SFM which gives you the option of running dCEF on your WAN cards. Scott C. McGrath On Thu, 8 Jan 2004, Josh Fleishman wrote: Back to the original question.. A lot of your decision comes down to what you're going to be doing with the box and when you expect your next jump from OC3 to OC12(or greater). Also, you need to consider your comfort level with JUNOS vs IOS. If you're cool with JUNOS then multiple M series boxes are worth investigating. Our experience with them has been almost nothing but positive, plus they will allow you to expand to greater than OC3, providing you with some future proofing. 7600's have proven to be fine boxes, especially if you have need for Ethernet port density at the same layer as your optical circuits. A lot of feature support is going to depend on your supervisor/msfc selection. If you go this route, and the coffers are full, check out the new(er) sup720's. However, based on your ACL and Policing requirements, the Sup2/MSFC2 combo should be sufficient. Also, keeping in mind the emergence of point to point Ethernet solutions in the WAN/MAN (ie Metro Ethernet, and MPLS and L2TPv3 pseudowires) keeping Ethernet at your edge might prove useful one day. The GSR, IMHO, is a higher tier box based on both it's scalability to OC192 and cost. Since you're just going to OC3's now, I doubt the GSR will be your best bet for the cost, but then again I haven't priced one out lately. If you're really pinching pennies, then check out upgrading your 7500's with RSP8/16s and faster VIPs. But, if you're putting multiple OC3's on a box, then your down links will likely start turning to GE. I'd stay away from the GEIPs if possible. And for your 7200's, look into the NPG-G1 which have line rate GE ports onboard. We've used them and they are pretty solid. A head to head GRE bakeoff between the NPE-G1 and an RSP8(with dCEF) proved the NPE to be far superior. Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bcm Sent: Tuesday, January 06, 2004 1:11 PM To: [EMAIL PROTECTED] Subject: GSR, 7600, Juniper M?, oh my! Hello all, I'm faced with a difficult decision. I work for a large multi-node regional ISP (and Cisco shop). In our largest nodes we've found the Cisco 7500 series routers to be at the end of their useful life due to the throughput generated by POS OC-3 feeds and 10,000+ broadband users whose traffic needs to be moved out of the node. Short of building a farm of 7500's the need to upgrade seems clear. But where to go? The Cisco GSR platform seems a logical choice, but their new 7600 series units are attractive for their cost. Juniper may also have a place at this end of the processing spectrum. I'd also like to ensure that the new platform supports doing CAR and ACLs at line rate, given the client base. I wanted to see what other operators in this situation have done, so I would appreciate anyone's input or insight into the pros and cons of these platforms or any other ideas as to how I can grow beyond the Cisco 7500.
Re: Upcoming change to SOA values in .com and .net zones
On Thu, Jan 08, 2004 at 05:21:33AM -0800, Avleen Vig [EMAIL PROTECTED] wrote a message of 22 lines which said: Verisign is learning their lesson, and it might take a while yet, but ... Verisign didn't do right last time, but they did this time. No, they are not learning. At least this is not what their CEO says: http://www.redherring.com/Article.aspx?f=articles/2003/12/14c9995f-5557-4dc4-ad48-4548360c2095/14c9995f-5557-4dc4-ad48-4548360c2095.xml This community needs to work together, not apart. I don't remember signing anywhere for being member of the same community than Verisign.
Re: Upcoming change to SOA values in .com and .net zones
No, they are not learning. At least this is not what their CEO says: http://www.redherring.com/Article.aspx?f=articles/2003/12/14c9995f-5557-4dc4-ad48-4548360c2095/14c9995f-5557-4dc4-ad48-4548360c2095.xml After reading that article I got curious about who Overture is. A quick search on Google got me this article: http://www.internet-marketing-research.net/overture_click_fraud.php And in case you think that perhaps the Red Herring writer only used Overture's rates as an example, here's another article that confirms that Overture did have a deal with Verisign's Sitefinder project: http://www.internetnews.com/bus-news/article.php/3080071 Verisign and its CEO are looking slimier and slimier... Thankfully, it is highly unlikely that the .com boom will ever make a comeback. Marketing and advertising people and investors are beginning to understand what works and what doesn't on the Internet. I expect that Sitefinder will return but that a lot of browser software and ISPs will divert the misspelled URLs to a local spelling checker. Sitefinder version 2 will die a quick death because it won't get enough clicks and most of the ones that it does get will be nuisance clicks. --Michael Dillon
Re: Upcoming change to SOA values in .com and .net zones
. I didn't notice anybody saying thank you for doing the right thing by announcing the change amongst the flurry of jerking knees. So, thank you for doing the right thing. Good luck with the maintenance. And should we thank Verisign for doing for a very minor change what they did not do for a much more crucial change, their wildcards? An optimist might say: Maybe they are learning -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Wirespeed 24-port L3 switches
Hi all, We're looking at L3 switches which have decent L3 packet forwarding performance (wirespeed if possible), a reasonable amount of L4 ACLs/ACEs (an average of at least 80 per port) and comes in a 24-port 10/100 port package with a couple of GBIC slots for uplinking to the core network. OSPF, but no BGP. We've looked at the Cisco 3550-24, but they seem to have resource exhaustion issues[1] if you create more than 8 SVI's (i.e. it goes back to software routing). Extreme 200 switches look OK, but are limited to about 1000 ACE[2] (averages 32 rules per port). Allied Telesyn's 8800/Rapier series currently only manage half that figure in hardware and don't support UDP/TCP port ranges in a single ACE[3]. Are our expectations of a 24-port switch too high? Would it be better to move over to higher density switches and put in large amounts of underfloor cabling in large installations and keep putting separate routers and switches into the smaller locations (100 ports)? Or are L3 switches not a mature product and we should all stick to using switches for L2 and have L3+ dealt with by dedicated routers for the time being? Cheers, Rich [1] http://www.cisco.com/warp/public/473/145.html [2] http://www.extremenetworks.com/libraries/prodpdfs/products/summit200_24_48.asp [3] They do support ranges, but a rule to cover a single range may require multiple ACEs.
RE: GSR, 7600, Juniper M?, oh my!
used to be... One could lay hands on a magic Cd that turned an ordinary PC with (Commonly available but the Brand Escapes me) Nics into a Juniper Olive that ran the full JunOS. It has disappeared, much to the disappointment of those of us that would love to use one to study for a cert/resume fodder. -Ejay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexei Roudnev Sent: Thursday, January 08, 2004 12:51 AM To: [EMAIL PROTECTED]; Jeff Kell Cc: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! Many interesting network solutions that have to be dismissed outright because of IOS limitations, weaknesses or bugs can be easily expressed in newer systems, not just JUNOS. Example, please. (Agree with Jiniper OS for x86 - many people avoid Juniper because do not know it).
Re: Wirespeed 24-port L3 switches
I think you are expecting too much from a 24 port switch. All these devices are meant to sell at a price and most of the buyers are using the L3 features as a checklist elimination option and in my experience most of these switches are never used as anything other than a dumb L2 switch but the purchaser feels good because they have a Manageable L3 switch the fact that these features are not configured in their installations notwithstanding. Also the manufacturers do not want to cannibalize the sales of higher end products so the cheap ones tend to have limited functionality. This community is a exception and we really do configure the features and expect them to work. Scott C. McGrath On Thu, 8 Jan 2004 [EMAIL PROTECTED] wrote: Hi all, We're looking at L3 switches which have decent L3 packet forwarding performance (wirespeed if possible), a reasonable amount of L4 ACLs/ACEs (an average of at least 80 per port) and comes in a 24-port 10/100 port package with a couple of GBIC slots for uplinking to the core network. OSPF, but no BGP. We've looked at the Cisco 3550-24, but they seem to have resource exhaustion issues[1] if you create more than 8 SVI's (i.e. it goes back to software routing). Extreme 200 switches look OK, but are limited to about 1000 ACE[2] (averages 32 rules per port). Allied Telesyn's 8800/Rapier series currently only manage half that figure in hardware and don't support UDP/TCP port ranges in a single ACE[3]. Are our expectations of a 24-port switch too high? Would it be better to move over to higher density switches and put in large amounts of underfloor cabling in large installations and keep putting separate routers and switches into the smaller locations (100 ports)? Or are L3 switches not a mature product and we should all stick to using switches for L2 and have L3+ dealt with by dedicated routers for the time being? Cheers, Rich [1] http://www.cisco.com/warp/public/473/145.html [2] http://www.extremenetworks.com/libraries/prodpdfs/products/summit200_24_48.asp [3] They do support ranges, but a rule to cover a single range may require multiple ACEs.
Re: Upcoming change to SOA values in .com and .net zones
I shall now go and penitentially stand in the very heavy rain and wind that England is enjoying today. I'll do the same (same weather in .be today :(() for irritating randy :) hey, we got six inches (about 15cm) of snow on the island, and snow is a once every three year thing for us. randy
Re: Upcoming change to SOA values in .com and .net zones
--On 08 January 2004 11:54 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: For very minor changes, they tell the 200 technical zealots Noted, but the large number of rabid posts on nanog about said minor change doesn't exactly make it *harder* for them to propagate the 200 zealots theory!
Re: Upcoming change to SOA values in .com and .net zones
--On Wednesday, January 7, 2004 5:43 PM -0800 Martin J. Levy [EMAIL PROTECTED] wrote: There should be no end-user impact resulting from these changes ... I believe there have been 26 (opps, now 27) responses to this announcement in the last 2 hours 45 minutes, that's about one response every 6 minutes. Hence there seems to be at least some impact on the community and that's before these changes are even implemented. :-) Martin I never expected to find myself defending Verisign, but, in this case, I have to point out the following: 1. Most of the flap has been people demonstrating that they don't understand the effect of the change. On a technical level, all that _SHOULD_ care about the zone serial number is the slave servers that are authoritative for the zone. 2. Some of the flap has been from people that can't read and seemed to think that the change was for Jan 9 instead of Feb. 9. 3. Some of the flap was from people who thought that the serial number going backwards was a serious operational issue. 4. Some of the response to 3 was from people who didn't realize that the serial number really was going to go backwards. 5. Eventually, the fact that this didn't matter was pointed out by some. I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. However, I don't see any meaningful reason for them not to do this either. Having said that, I think that, for once, they actually did provide reasonable notification of the change, and, were extra helpful showing the simple perl conversion from new-format serial number to timestamp. I think we should be praising them for this, accepting that it is a minor change, and appreciating the actual advance notice. I think we should make it clear that we as a community are not a band of engineers opposed to changes for the sake of opposing change and keep it clear that there were real operational impact reasons to oppose the wildcard records. This change isn't worth opposing, and, at least they gave us reasonable notice on it. We should move on. Just my $0.02, but, I think we should declare this horse dead. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: Upcoming change to SOA values in .com and .net zones
Owen DeLong wrote: 5 Eventually, the fact that this didn't matter was pointed out by some. I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. However, I don't see any meaningful reason for them not to do this either. I am a (currently unemployed) mouse. I worry when the cat announces changes that the cat says are of no interest to mice. I worry especially when I can not clearly see a benifit to either cat or mice.
Re: Upcoming change to SOA values in .com and .net zones
(Although I do know of some scripts that check the serial of the gltd servers for things like monitoring new domains, deletes,...) Any such scripts should require only _VERY_ minor tweakage or one-time manual intervention. For any such issue, I think 30 days is more than reasonable notice. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp0.pgp Description: PGP signature
Re: Upcoming change to SOA values in .com and .net zones
On 8 Jan 2004, at 11:35, Owen DeLong wrote: I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. If they are going to do zone updates every 15 minutes, then that's 96 serial bumps per day. They could fit that in the the two-digit nn in MMDDnn, but it wouldn't leave an awful lot of room for any additional ad-hoc serial bumps that might be necessary to address operational problems. MMDDnnn exceeds 32 bits for contemporary values of , so that's not a viable alternative. YYMMDDnnn would work, but has Y2K-ignorant connotations (not that that's particular relevant, post Y2K). Using a second-counter from the unix epoch seems like a perfectly reasonable solution to me. Joe
Re: Upcoming change to SOA values in .com and .net zones
On Thu, 8 Jan 2004, Rob Pickering wrote: Noted, but the large number of rabid posts on nanog about said minor change doesn't exactly make it *harder* for them to propagate the 200 zealots theory! I don't think 24 hours is bad turnaround time to educate all of the people who tossed out possible concerns about the change. That's what I call educating efficiently. (Corporations sometimes take much longer to make as much progress as we do in 24 hours.) Verisign could have used NANOG to speed up the change if they had asked the question slightly different: - We are planning on changing the serial numbers from x to y. Please let us know any reasonable issues we should be concerned about with this change. If we do not receive any response we will make the change on $date. As it stands, all of the (non)issues that have been raised have been addressed. (if the concerned parties are reading their E-mail) Verisign could ask tomorrow if there are any more issues to consider, or if anyone directly affected by this change needs more time. Using interaction with the community to their advantage, they could introduce an idea, get feedback, and make a simple change within 72 hours. As for the whole zealot comments, it is my job to ask the questions about things others try to gloss over. I don't think it is right to chastise anyone for wanting to know more just to clear a concern. You wind up with a group of people afraid to speak and won't tell you when you are about to do something stupid. Anyone who uses that term is effectively getting on to you for using your own brain instead of following the crowd. The opposite of zealot is lemming. Gerald
Re: Upcoming change
encoded date). It doesn't provide the functionality they are striving for. actually, I think it does. However, I don't see any meaningful reason for them not to do this either. I am a (currently unemployed) mouse. I worry when the cat announces changes that the cat says are of no interest to mice. I worry especially when I can not clearly see a benifit to either cat or mice. Look again. They may wish to make more than 99 updates a day to the zone(s) and the mmddxx format is kind of restrictive in that regard. --bill
Re: Upcoming change to SOA values in .com and .net zones
Joe Abley wrote: On 8 Jan 2004, at 11:35, Owen DeLong wrote: I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. If they are going to do zone updates every 15 minutes, then that's 96 serial bumps per day. They could fit that in the the two-digit nn in MMDDnn, but it wouldn't leave an awful lot of room for any additional ad-hoc serial bumps that might be necessary to address operational problems. MMDDnnn exceeds 32 bits for contemporary values of , so that's not a viable alternative. YYMMDDnnn would work, but has Y2K-ignorant connotations (not that that's particular relevant, post Y2K). Using a second-counter from the unix epoch seems like a perfectly reasonable solution to me. If it doesn't matter to anybody, and nobody cares, and the value (current and proposed) is irrelevant, why not just add 1 to the current value and stop worrying about it?
RE: GSR, 7600, Juniper M?, oh my!
On Thu, 8 Jan 2004, Ejay Hire wrote: used to be... One could lay hands on a magic Cd that turned an ordinary PC with (Commonly available but the Brand Escapes me) Nics into a Juniper Olive that ran the full JunOS. It has disappeared, much to the disappointment of those of us that would love to use one to study for a cert/resume fodder. If one were searching for ISO images of such a thing, what would perhaps be some keywords to type into one's P2P application? Charles -Ejay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexei Roudnev Sent: Thursday, January 08, 2004 12:51 AM To: [EMAIL PROTECTED]; Jeff Kell Cc: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! Many interesting network solutions that have to be dismissed outright because of IOS limitations, weaknesses or bugs can be easily expressed in newer systems, not just JUNOS. Example, please. (Agree with Jiniper OS for x86 - many people avoid Juniper because do not know it).
RE: GSR, 7600, Juniper M?, oh my!
Ejay, Those would be Intel NICs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ejay Hire Sent: Thursday, January 08, 2004 10:17 AM To: 'Alexei Roudnev'; [EMAIL PROTECTED]; 'Jeff Kell' Cc: [EMAIL PROTECTED] Subject: RE: GSR, 7600, Juniper M?, oh my! used to be... One could lay hands on a magic Cd that turned an ordinary PC with (Commonly available but the Brand Escapes me) Nics into a Juniper Olive that ran the full JunOS. It has disappeared, much to the disappointment of those of us that would love to use one to study for a cert/resume fodder. -Ejay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexei Roudnev Sent: Thursday, January 08, 2004 12:51 AM To: [EMAIL PROTECTED]; Jeff Kell Cc: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! Many interesting network solutions that have to be dismissed outright because of IOS limitations, weaknesses or bugs can be easily expressed in newer systems, not just JUNOS. Example, please. (Agree with Jiniper OS for x86 - many people avoid Juniper because do not know it).
Re: Upcoming change to SOA values in .com and .net zones
MMDDnnn exceeds 32 bits for contemporary values of , so that's not a viable alternative. YYMMDDnnn would work, but has Y2K-ignorant connotations (not that that's particular relevant, post Y2K). Using a Hmm bearing in mind how the calculation is done YYMMDD (or nnn) wouldnt be a problem.. going from 991231 to 000101 is considered to be an increase isnt it? [actually it wraps at 2^31 =~ 4e10] Steve
Re: Upcoming change to SOA values in .com and .net zones
Subject: Re: Upcoming change to SOA values in .com and .net zones Date: Thu, Jan 08, 2004 at 08:35:54AM -0800 Quoting Owen DeLong ([EMAIL PROTECTED]): I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for. Oh, but I can see why. The primary master server's implementor might choose to autoincrement the SOA SERIAL if any of the following events occurs: (1) Each update operation. (2) A name, RR or RRset in the zone has changed and has subsequently been visible to a DNS client since the unincremented SOA was visible to a DNS client, and the SOA is about to become visible to a DNS client. (3) A configurable period of time has elapsed since the last update operation. This period shall be less than or equal to one third of the zone refresh time, and the default shall be the lesser of that maximum and 300 seconds. (4) A configurable number of updates has been applied since the last SOA change. The default value for this configuration parameter shall be one hundred (100). Vixie, et. al: RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE), pp16-17 (formatting slightly edited) Given: a/ The size of the .com and .net zones and the hassle associated with doing legacy-style maintenance of zones that size, b/ The desire of customers with the usual bad planning habits (ie. they want DNS delegation changes like yesterday and what is this TTL crap?) ..it is obvious that an administrator of a large, frequently updated zone would want to prepare for dynamic updates. One of the constraints with date-style serial numbers (the only situation when .us residents write dates in the sensible ISO standard MMDD style ;-) is that the size of the SOA serial number limits the number of zone generations to 100 per 24h period, which might be an issue when using dynamic updates especially if they are being processed automatically. Again, this is not a problem, not something to bother about, and the suits at Verisign will not break things by this. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE I'm wet! I'm wild! pgp0.pgp Description: PGP signature
Re: Upcoming change to SOA values in .com and .net zones
I worry especially when I can not clearly see a benifit to either cat or mice. The current serial number format supports a maximum of 100 changes to the .com zone per day. If you store your zone as text files on a hard drive that is more than enough. But! What if you consider the zone to be a database and maybe even store it in RAM? In that case, you could update the zone every single time one of the .com entries is added or deleted. The performance impact of doing this to a zone stored in RAM is approximately nil. However, the DNS protocol requires a serial number that changes every time the zone changes. So the first step is to change the way a zone serial number is created. Then you deploy a DNS server architecture that runs entirely out of RAM. And then when all of this works smoothly, you start to increase the number of updates per day until you're doing it every 15 minutes or so. Then, finally, you go live with real-time updates. In fact, with the speed of today's hardware and RAID arrays it's probably worthwhile to do this even without holding the whole zone in RAM. Now do you see why changing the serial number would clearly benefit the cat? And can you see how this would even lead to possible future benefits for many of us mice? If you are going to attack Verisign, at least pick a weak point to target with your attack. --Michael Dillon
Re: Upcoming change to SOA values in .com and .net zones
I worry especially when I can not clearly see a benefit to either cat or mice. [snip] If you are going to attack Verisign, at least pick a weak point to target with your attack. Several public and several private manifestations of this so I'll answer this one publically, then I am of out of the discussion. In some parts of the English-speaking world, an expression of worry or concern is not an attack. Asserting that a call for clarity is an attack, is in and of itself a new cause for concern.
Re: GSR, 7600, Juniper M?, oh my!
A lot of your decision comes down to what you're going to be doing with the box and when you expect your next jump from OC3 to OC12(or greater). Also, you need to consider your comfort level with JUNOS vs IOS. If you're cool with JUNOS then multiple M series boxes are worth investigating. Our experience with them has been almost nothing but positive, plus they will allow you to expand to greater than OC3, providing you with some future proofing. One additional data point is that due to excess forwarding resources its possible in JUNOS 6.x to condense many physical 760x and 750x down in to 1 or 2 M series using ithe virtual router capability. In a nutshell each virtual router is its own administrative domain so you can have different staff maintain different virtual routers on the same physical box. Fewer physical boxes might be an advantage for some. See release notes for JUNOS 6.x in the tech pubs area of the juniper.net web site for more details on virtual router features. -Rob
Re: GSR, 7600, Juniper M?, oh my!
Many interesting network solutions that have to be dismissed outright because of IOS limitations, weaknesses or bugs can be easily expressed in newer systems, not just JUNOS. Example, please. Due to a barrage of e-mails I received on the subject I thought I'd send a generic reply to the list rather than try to cook up a plethera of examples on a one-to-one basis... First, if you haven't done so already, I suggest watching the Intro to JUNOS web training session on the juniper.net web site: http://www.juniper.net/training/elearning/junos_cli/index.html Next, the full docs for JUNOS are available without registration at http://www.juniper.net/techpubs For M series, click on the software link and pick the highest version listed their; 6.x would be the most current. Once you've looked at the training video and downloaded the docs you should be able to drill down to the areas that interst you most. The comprehensive index might be good to actually print out for handy reference. Some areas of interest might include: Group inheritance Using function/procedure invocation in policys Virtual router features; N logical routers in 1 box, more extensive than Redback contexts. Operational goodies: Auto Chicken mode - Basically the JUNOS config is a database and as such you commit changes. You can do an auto reverting commit that restores a known good config after N minutes if the candidate config isn't confirmed; i.e. #$%#%#$, I just downed the infrastructure link on a remote router... See commit confirmed x for details. This feature has been rumored to have saved many a chicken hide! You can leave insane levels of debug turned on without killing the routing or forwarding engines. For Juniper: ( You know who you are! ) Why not release an Olive CD with each new major JUNOS bump? It wouldn't hurt to have every schmoe in the universe that can boot a FreeBSD ISO also be competant in JUNOS! Place it as an iso download in the software docs area. For the squemish in the legal dept. you could remove the code that handles Juniper hardware from the distro and still have an excellent CLI engine and minimal routing platform simulator. I bet if you passed out a stack of Olive CD's at a NANOG there would be plenty of takers! -Rob
Re: GSR, 7600, Juniper M?, oh my!
On Thu, Jan 08, 2004 at 12:14:18PM -0600, Rob Healey wrote: For Juniper: ( You know who you are! ) Why not release an Olive CD with each new major JUNOS bump? It wouldn't hurt to have every schmoe in the universe that can boot a FreeBSD ISO also be competant in JUNOS! Place it as an iso download in the software docs area. For the squemish in the legal dept. you could remove the code that handles Juniper hardware from the distro and still have an excellent CLI engine and minimal routing platform simulator. I bet if you passed out a stack of Olive CD's at a NANOG there would be plenty of takers! I still think there is a market for low-end 100Mbps-only PC routers for which they could easily sell thousands of copies of JunOS without the jpfe package at $1000 a pop. Considering they actually managed to add hardware-less firewalling in 5.x, I'm still not entirely convinced that they aren't thinking the same thing. But alas, it's probably too innovative a concept, and might cut into the stupid with too much money M5 buying market a tiny bit. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
New Statistics Format Available
On 5 January 2004, the Regional Internet Registries (APNIC, ARIN, LACNIC, and RIPE NCC) implemented a new standard file format for reporting the current state of Internet resource allocations and assignments for: - IPv4 address ranges - IPv6 address ranges - AS numbers The new file format, now available from all RIRs, ensures consistency and makes it easier for users to integrate and analyze data from different sources. The reports contain a snapshot of the status of Internet number resources, without any details of transaction histories. They are produced daily and include: - Information summaries - GPG key signatures - MD5 checksums for verification Statistics files The latest statistics files are available from the RIR sites listed below. Each RIR site also mirrors the files of the other RIRs. ARIN ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest APNIC ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest LACNIC ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest RIPE NCC ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest More information ARIN ftp://ftp.arin.net/pub/stats/arin/README APNIC http://www.apnic.net/db/rir-stats-format.html LACNIC ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest RIPE NCC ftp://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt Regards, Ginny Listman Director of Engineering ARIN
Verisign CRL single point of failure
Verisign's Certificate Revocation structure apparently was not designed to handle the load of large numbers of systems using crl.verisign.net. Verisign has introduced a 50% failure mechanism to gap the load on their servers. This is a side effect of the expiration of one of Verisign's Intermediate Root Certificates. Verisign has redirecting traffic to several RFC1918 addresses, which are not routable on the Internet but are frequently used in enterprise networks. It is possible Verisign has created a Denial of Service on Enterprise services using the same RFC1918 addresses as internal systems checking for crl.versign.net are redirected to other RFC1918 addresses. The consolidation of network power in a single company creates its own threat to the critical infrastructure when a single certificate expires instead of being randomly distributed among several different organizations.
Re: Verisign CRL single point of failure
: The consolidation of network power in a single company creates : its own threat to the critical infrastructure when a single : certificate expires instead of being randomly distributed among : several different organizations. Boy-o-boy that's fundamental wrt to the internet... scott
BGP configuration checking tool: announcement and request for users/feedback
Hi Nanog, As you may know, I've been developing a tool called RoLex (Routing Lexer) that performs various syntactic and conceptual checks on existing BGP configurations. (To refresh your memory, see: http://www.nanog.org/mtg-0310/feamster.html) The checker now parses Cisco and Juniper IOS and represents BGP configuration in an abstract format (in the form of relational database tables); the checks themselves are expressed as perl modules that run SQL queries against these tables. You can get more information about the tool itself, including the tests that the tool currently performs, at: http://nms.lcs.mit.edu/bgp/rolex/ (the code is in pre-release; if you would like to test it on your configurations, please ask me and I'll give you a version.) Part of our motivation for developing this tool is to get a better understanding of errors and anomalies that turn up in real configuration files. A couple of very kind, generous folks at some larger ISPs have given me some initial assistance by letting me run the tool on some of their configuration files, and, in some cases, our checks have allowed operators (and me) to see some interesting things. (read: you might find some things you didn't expect) Nevertheless, our study (and the tool) will benefit tremendously by exposure to configurations from a much wider variety of ASes. (The more, the better.) If you could help me in any of the following ways, I would be extremely grateful: 1. Run the tool on your configuration and let me know what types of errors you find. This will help me in our analysis as far as figuring out what types of problems are most common, etc. If you're feeling extremely helpful, you could let me run the tool on your configuration files for you. This would probably save you time; of course, I'd discuss with you what I found in your configs. (Yes, I am asking to look at your configs; I'm amenable to nondisclosure arrangements regarding keeping keeping your configuration data private, if you like.) 2. Suggest new tests that you would like to see incorporated into the tool. I am eager to provide the tool for you to try on your configuration files. I'm also more than willing to help you set it up in a way that works well for you. In return, I would hope that you would help me better understand the errors/anomalies that the tool turns up or at least give me some suggestions on how to improve the tool (e.g., what types of checks you would like to see added to the tool, personal experience, etc.). Please let me know if you are interested in helping out. Thanks! Nick
Re: Upcoming change
I am a (currently unemployed) mouse. I worry when the cat announces changes that the cat says are of no interest to mice. I worry especially when I can not clearly see a benifit to either cat or mice. Look again. They may wish to make more than 99 updates a day to the zone(s) and the mmddxx format is kind of restrictive in that regard. Indeed. PIR and UltraDNS update the .org zone (and SOA serials) every couple of minutes, and propagate changes in an equivalently snappy fashion. In UltraDNS's case, the format appears to be mm, or perhaps xx (hard to figure out what the scheme is this early in the year). I'm sure Verisign has gotten its share of why the hell can't you guys do this email since PIR started offering nice fast change turnarounds. I'm just hoping that the choice of a time_t as serial is not a harbinger of djbdns in the gtld servers... ---Rob
