- Test - lists.nanog.org

COM/NET/ORG/EDU Registry Informational Message
by Brad Verd 11 Feb '02

11 Feb '02

To All, VeriSign GRS will be making several changes to the COM, NET, ORG and EDU zone files. Their format will be modified to reduce the overall file size by removing unnecessary text and extraneous records. Currently the excess information causes an increase in the time required to generate and distribute these files. In the interest of making timely updates and meeting ICANN requirements for file distribution, the following changes will be made: 1. Modify Zone File Format to Reduce Size Using certain directives and shortcuts to replace recurring values will significantly reduce the size of these zone files: - Records will contain unqualified, or relative, domain names whenever possible. The particular zone files origin will be specified with a $ORIGIN directive and should be appended to unqualified domain names per RFC 1035, section 5.1. - The $TTL directive will be used set the default time to live for subsequent records in the zone file per RFC 2308, section 4. Individual records will no longer contain an explicit TTL. - The IN class will be specified in the SOA record but omitted in all subsequent records, since a records class defaults to the previously specified class. See RFC 1035, section 5.1 for more information. These format changes are currently scheduled to be implemented late Q2 2. Eliminate Orphan A Records The current zone generation process publishes A (address) records (also called glue records) regardless of whether the name server is referenced by any NS (name server) records. Put another way, an A record is published even if no zone delegations reference it. These A records are called orphans, and their presence in the COM/NET/ORG zones is undesirable for both administrative and technical reasons The inclusion of these orphan A records can cause problems for administrators of lower-level name servers. Even if the lower-level servers are configured properly, orphan A records in the COM/NET/ORG zones can interfere with normal resolution of lower-level zones and make maintenance (especially changes) difficult and confusing. If the lower-level name servers are configured improperly, the presence of orphan A records may be the only reason that resolution is currently working correctly. Therefore, it is important that all administrators of COM/NET/ORG subzones have the correct information in their zones prior to the removal of orphan A records from the COM/NET/ORG zones. Verisigns proposed resolution for achieving this is as follows: Step 1 (by late February): A report will be generated weekly for each registrar indicating the orphan A records owned by that registrar. VeriSign GRS will also include instructions describing the steps that should be taken to ensure that lower-level name servers are properly configured so that removal of the orphan A records will not cause failures in resolution. Step 2 (by late February): A list of all orphan A records will be posted to the VeriSign GRS web site and will be updated weekly. This list will allow registrants to determine if they might be affected by the elimination of orphan A records from the COM/NET/ORG zones and provide instruction on resolving these issues Step 3 (Currently scheduled for late Q2): Approximately a week before the modification to the zone generation process to remove orphan A records is implemented, another email will be sent out as a reminder with the exact date that the change will occur. Regards, Brad -------------------------------------- Brad Verd Resolution Systems Operations Manager Verisign Global Registry Services Email - bverd(a)verisign.com ---------------------------------------

1 0

Re: Reducing Usenet Bandwidth
by Stephen Griffin 11 Feb '02

11 Feb '02

In the referenced message, Jared Mauch said: > > On Tue, Feb 05, 2002 at 04:28:39PM -0500, Stephen Griffin wrote: > > Actually, after confirming with Cisco, the above bug is different. > > Essentially, if a router has two links, and a route in both iBGP and > > iMBGP with same igp distance, local pref, mask, etc, the unicast BGP > > route is chosen for RPF, rather than the multicast route. This would > > lead to using the "wrong" interface. > > > > Although it is related in that, if the RPF check was done against > > the MRIB first, it would solve this bug. > > does "ip multicast multipath" help you at all either? > > that should cause it to rpf down both paths. > > - jared Based upon what I've previously been told, "ip multicast multipath" doesn't actually work yet. I've not tested it. The problems I see are related to short EBGP unicast routes beating long IBGP multicast routes due to the default checks based on administrative distance (ebgp has lower admin distance). (EBGP unicast routes beat IBGP multicast routes, even at the same prefix-length) if the knob is twiddled to do length-based checks, then the problem turns to long unicast routes beat short multicast routes, which can be a problem if someone is doing TE with no-export tagged more-specifics, such that you would have multicast connectivity via the shorter prefix, but follow the path where there is no multicast connectivity. Cisco is aware of my concerns, and the proposed solution of doing multicast RPF checks in the same manner as the MSDP checks (of sorts) with longest-match across the mrib, and falling back to longest-match across the urib (if there's no covering prefix in the mrib) but don't have any timeframe as to when that might be undertaken.

1 0

Re: testing sprint
by Matthew S. Hallacy 11 Feb '02

11 Feb '02

On Wed, Feb 06, 2002 at 08:14:34PM -0600, Eric A. Hall wrote: > > > The question is, does sprint.net have the balls to terminate Sprint long > distance for spamming? > > http://tracking.networkpromotion.com/Tracking/etags.html?LinkID=5202 But then I'd miss out on my free motorola two-way radios, or whatever the latest gimmick is. FWIW, they got my email address from my previosu sprint local phone service account when I lived in a sprint serviced area.. the one I told them I did not want special promotional offers sent to. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- Matthew S. Hallacy CACU, PWGCS, and BOFH Certified http://techmonkeys.org/~poptix GPG public key 0x01938203

1 0

Re: Ethernet EP - MAC Address Filtering
by David McGaugh 11 Feb '02

11 Feb '02

This is a multi-part message in MIME format. --------------BFB259ADB7DC6A39F9566071 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would be planning deploy it on the Juniper Platforms and it appears that at least the 4 port FE PICs support it as well. I would imagine (without actually investigating it) you could do some sort of port security on the 65xx/76xx platform though. Primarily I am questioning whether it would be scalable in the long term or whether it would become more trouble than what it would be worth. Also while Deepak pointed out that you could perform line rate packet filtering only allowing packets to valid destinations on your network, this would only stop someone defaulting you but would not stop someone repointing next hop to valid destinations on your network. -Dave Lane Patterson wrote: > > I'm aware that Juniper GigE interfaces support a mac-filter-list. I'm > not well versed on which versions of Cisco router products support this > well (and line rate), but I didn't think GSRs and 7xxx had any support for > this. Are the L2/L3 family (65xx, 76xx) able to handle mac-filters at > line rate w/o a slow path? > > I too would be interested in knowing if folks perform mac-filtering. > > Certainly there are other measures you can take as well, such as scripting > some default-pointing traceroute checks, to check both peers and non-peers > on an IXP fabric. These have been documented at various times, and Avi > at one point posted some form of this to Nanog (moons ago...search archives). > > My impression of "best practices" would be to: > > 1. implement mac-filter or mac-counters to prevent > any illegally statically routed non-peer traffic. > 2. implement traceroute scripts to check that peers are > not defaulting any partial transit thru you. > > Feedback welcome :-) > > Cheers, > -Lane > > On Fri, Feb 08, 2002 at 10:29:07AM -0800, David McGaugh <david_mcgaugh(a)eli.net> wrote: > > > Hello NANOG, > > > > Just curious if anyone is performing MAC Address Filtering at any of > > the Ethernet Exchange Points. If so has it been found to be easy to > > administer or difficult where by peers may be changing Layer 3 devices > > or Interfaces without notice? Alternately is MAC Address Filtering > > considered an unneeded security measure? > > > > Thanks, > > Dave > Content-Description: Card for Dave McGaugh --------------BFB259ADB7DC6A39F9566071 Content-Type: text/x-vcard; charset=us-ascii; name="david_mcgaugh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave McGaugh Content-Disposition: attachment; filename="david_mcgaugh.vcf" begin:vcard n:McGaugh;David tel;fax:360.816.3297 tel;work:360.816.3718 x-mozilla-html:FALSE url:http://www.eli.net org:Electric Lightwave, Inc.;Network Planning and Engineering adr:;;4400 NE 77th Ave.;Vancouver;WA;98662;USA version:2.1 email;internet:dmcgaugh@eli.net title:Internetwork Engineer x-mozilla-cpt:;26448 fn:David McGaugh end:vcard --------------BFB259ADB7DC6A39F9566071--

1 0

WHOIS db datamining
by Scott Francis 11 Feb '02

11 Feb '02

Apologies for starting a new thread - I seem to recall one recently regarding somebody who was having difficulty making more than X requests per Y seconds to the WHOIS servers (receiving disconnects). Received a spam recently from 212.171.42.117 offering the contents of .com/.net/.org/.edu on 4 CDs (reported to the usual sources - spamcop, abuse@domain, abuse@upstream, and in this case, abuse(a)internic.net (see below) ). My annoyance at receiving a spam is fairly limited - I have become used to it by now. However, I am curious - the WHOIS servers (some of them, anyway) contain a statement in the connect message that explicitly prohibits commercial use of the registry. And IIRC that earlier thread, too many connection attempts from a single location in a certain amount of time would cause a disconnect (presumably to thwart this very type of datamining). ==== "By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems)." ==== Is NetSol/VeriSign serious about enforcing this? Are they willing to blackhole abusers? One would think it would be a trivial matter to engineer the servers such that more than X attempts per Y seconds either results in a block (temporary or permanent) or flags the activity for later review (a la IDS). Perhaps I am vastly oversimplifying such a task. I sent my concerns to NetSol's abuse department already, but I hold little hope of that achieving anything of lasting significance. I was really hoping to get either "been there, done that", "try X" or even "this is off-topic - stop polluting the list" from those of you that have been down this road before. -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

2 1

Re: WHOIS db datamining
by Stephen J. Wilcox 11 Feb '02

11 Feb '02

Verisign contacted us to get IP addresses for our whois queries, they say information will be limited to include non personal info shortly... Steve On Mon, 11 Feb 2002, Scott Francis wrote: > > Apologies for starting a new thread - I seem to recall one recently regarding > somebody who was having difficulty making more than X requests per Y seconds > to the WHOIS servers (receiving disconnects). Received a spam recently from > 212.171.42.117 offering the contents of .com/.net/.org/.edu on 4 CDs (reported > to the usual sources - spamcop, abuse@domain, abuse@upstream, and in this case, > abuse(a)internic.net (see below) ). > > My annoyance at receiving a spam is fairly limited - I have become used to it > by now. However, I am curious - the WHOIS servers (some of them, anyway) contain > a statement in the connect message that explicitly prohibits commercial use of > the registry. And IIRC that earlier thread, too many connection attempts from a > single location in a certain amount of time would cause a disconnect > (presumably to thwart this very type of datamining). > > ==== > "By submitting a WHOIS query, you agree that you will use this Data only for > lawful purposes and that, under no circumstances will you use this Data to: > (1) allow, enable, or otherwise support the transmission of mass > unsolicited, commercial advertising or solicitations via e-mail > (spam); or (2) enable high volume, automated, electronic processes > that apply to Network Solutions (or its systems)." > ==== > > Is NetSol/VeriSign serious about enforcing this? Are they willing to > blackhole abusers? One would think it would be a trivial matter to engineer > the servers such that more than X attempts per Y seconds either results in > a block (temporary or permanent) or flags the activity for later review (a la > IDS). Perhaps I am vastly oversimplifying such a task. > > I sent my concerns to NetSol's abuse department already, but I hold little > hope of that achieving anything of lasting significance. I was really hoping > to get either "been there, done that", "try X" or even "this is off-topic - > stop polluting the list" from those of you that have been down this road > before. > > -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008

1 0

WHOIS db datamining
by Scott Francis 11 Feb '02

11 Feb '02

Apologies for starting a new thread - I seem to recall one recently regarding somebody who was having difficulty making more than X requests per Y seconds to the WHOIS servers (receiving disconnects). Received a spam recently from 212.171.42.117 offering the contents of .com/.net/.org/.edu on 4 CDs (reported to the usual sources - spamcop, abuse@domain, abuse@upstream, and in this case, abuse(a)internic.net (see below) ). My annoyance at receiving a spam is fairly limited - I have become used to it by now. However, I am curious - the WHOIS servers (some of them, anyway) contain a statement in the connect message that explicitly prohibits commercial use of the registry. And IIRC that earlier thread, too many connection attempts from a single location in a certain amount of time would cause a disconnect (presumably to thwart this very type of datamining). ==== "By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems)." ==== Is NetSol/VeriSign serious about enforcing this? Are they willing to blackhole abusers? One would think it would be a trivial matter to engineer the servers such that more than X attempts per Y seconds either results in a block (temporary or permanent) or flags the activity for later review (a la IDS). Perhaps I am vastly oversimplifying such a task. I sent my concerns to NetSol's abuse department already, but I hold little hope of that achieving anything of lasting significance. I was really hoping to get either "been there, done that", "try X" or even "this is off-topic - stop polluting the list" from those of you that have been down this road before. -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

1 0

arin application help
by Bryan Decker 11 Feb '02

11 Feb '02

Could somebody who has completed an ARIN IP application please contact me off-list? I'd like to get it right the first time. Thanks Bryan Decker Network Engineer Bluemarble Telecom, LLC

2 1

RE: arin application help
by Richard Jimmerson 11 Feb '02

11 Feb '02

This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C1B306.0E104ED0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello Bryan, ARIN has a help desk available from 7:00 AM to 7:00 PM EST, on week days. The registration help desk phone number is: +1-703-227-0660 You may also contact ARIN registration services by sending email to hostmaster(a)arin.net A registration analyst would be glad to answer any questions you have about the request process. Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Bryan Decker Sent: Monday, February 11, 2002 1:59 PM To: nanog(a)merit.edu Subject: arin application help Could somebody who has completed an ARIN IP application please contact me off-list? I'd like to get it right the first time. Thanks Bryan Decker Network Engineer Bluemarble Telecom, LLC ------=_NextPart_000_0076_01C1B306.0E104ED0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD> <BODY style=3D"FONT-FAMILY: Arial" text=3D#000000 bgColor=3D#ffffff> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>Hello=20 Bryan,</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>ARIN has a help = desk available=20 from 7:00 AM to 7:00 PM EST, on week days.</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>The registration = help desk=20 phone number is:</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>  =20 +1-703-227-0660</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>You may also = contact ARIN=20 registration services by sending email to</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2><A=20 href=3D"mailto:hostmaster@arin.net">hostmaster(a)arin.net</A></FONT></SPAN>= </DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>A registration = analyst would be=20 glad to answer any questions you have about</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>the request=20 process.</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2>Regards,</FONT></SPAN></DIV> <DIV><SPAN class=3D305330519-11022002><FONT = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D305330519-11022002><FONT size=3D2>Richard = Jimmerson<BR>Director=20 of Operations<BR>American Registry for Internet Numbers (ARIN)=20 </FONT></DIV></SPAN> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] <B>On Behalf Of = </B>Bryan=20 Decker<BR><B>Sent:</B> Monday, February 11, 2002 1:59 PM<BR><B>To:</B> = nanog(a)merit.edu<BR><B>Subject:</B> arin application = help<BR><BR></FONT></DIV> <DIV><FONT size=3D2>Could somebody who has completed an ARIN IP = application=20 please contact me off-list? I'd like to get it right the first=20 time.</FONT></DIV><FONT size=3D2> <DIV><BR>Thanks<BR><BR>Bryan Decker</DIV> <DIV>Network Engineer<BR>Bluemarble Telecom,=20 LLC</FONT></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0076_01C1B306.0E104ED0--

1 0

arin application help
by Bryan Decker 11 Feb '02

11 Feb '02

--=====_101345392911478=_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Could somebody who has completed an ARIN IP application please contact me= off-list? I'd like to get it right the first time. Thanks Bryan Decker Network Engineer Bluemarble Telecom, LLC --=====_101345392911478=_ Content-Type: text/html; charset="us-ascii" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD> <BODY style="FONT-FAMILY: Arial" text=#000000 bgColor=#ffffff> <DIV><FONT size=2>Could somebody who has completed an ARIN IP application please contact me off-list? I'd like to get it right the first time.</FONT></DIV><FONT size=2> <DIV><BR>Thanks<BR><BR>Bryan Decker</DIV> <DIV>Network Engineer<BR>Bluemarble Telecom, LLC</FONT></DIV></BODY></HTML> --=====_101345392911478=_--

1 0