- Test - lists.nanog.org

Re: Were A record domain names ever limited to 23 characters?
by steve pirk [egrep] 11 Oct '11

11 Oct '11

Hahahahaha! That is awesome. On Mon, Oct 10, 2011 at 17:50, <bmanning(a)vacation.karoshi.com> wrote: > back in the day, > > abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ.ca.us. > > existed to test the length of DNS label. circa 1992 > > ^b.com also existed (yes, we considered ^p) > > > the heady days of DNS evolution! > > /bill > > > On Fri, Oct 07, 2011 at 06:16:46PM -0700, Owen DeLong wrote: > > NSI was never the only registrar. They were just the only registrar > > for COM, ORG, NET, EDU, and possibly a few other TLDs, but, > > they were, for example, never the registrar for US or many other > > CCTLDs. > > > > Therefore, it was not internet wide, though I will admit that it did > > cover most of the widely known gTLDs. > > > > Owen > > > > On Oct 7, 2011, at 4:45 PM, steve pirk [egrep] wrote: > > > > > It turns out it was an artificial limitation on Network Solution's > part. > > > Being the only registrar at the time, it was pretty much internet wide > at > > > that point, contrary to the RFC spec. > > > > > > What was so funny was that someone got Internic/Network Solutions to up > the > > > limit. Apparently just to save some money on reprinting movie > posters... ok, > > > so they would have had to change some trailers... > > > ;-] > > > > > > On Fri, Oct 7, 2011 at 16:39, Jimmy Hess <mysidia(a)gmail.com> wrote: > > > > > >> On Fri, Sep 30, 2011 at 10:32 PM, Joe Hamelin <joe(a)nethead.com> > wrote: > > >>> I remember tales from when there was an eight character limit. But > that > > >> was > > >>> back when you didn't have to pay for them and they assigned you a > class-c > > >>> block automatically. Of course it took six weeks to register because > > >> there > > >>> was only one person running the registry. > > >> > > >> You may be referring to a limitation of a certain OS regarding a > > >> hostname; or some network's policy. > > >> But the DNS protocol itself never had a limit of 8 characters. > > >> When we are talking about the contents of "A" record names, > > >> > > >> I would refer you to > > >> http://www.rfc-editor.org/rfc/rfc2181.txt > > >> "RFC 2181 > > >> Clarifications to the DNS Specification R. Elz, R. Bush > > >> [ July 1997 ] (TXT = 36989) (Updates RFC1034, RFC1035, RFC1123) > > >> (Updated-By RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452) > > >> (Status: PROPOSED STANDARD) (Stream: IETF, Area: int, WG: dnsind) " > > >> > > >> " > > >> Elz & Bush Standards Track [Page > 12] > > >> ... > > >> Occasionally it is assumed that the Domain Name System serves only > > >> the purpose of mapping Internet host names to data, and mapping > > >> Internet addresses to host names. This is not correct, the DNS is a > > >> general (if somewhat limited) hierarchical database, and can store > > >> almost any kind of data, for almost any purpose. > > >> ... > > >> 11. Name syntax > > >> " > > >> The length of any one label is limited to between 1 and 63 octets. A > > >> full domain > > >> name is limited to 255 octets (including the separators). The zero > > >> length full name is defined as representing the root of the DNS tree, > > >> and is typically written and displayed as ".". Those restrictions > > >> aside, any binary string whatever can be used as the label of any > > >> resource record. > > >> " > > >> > > >> -- > > >> -JH > > >> > > > > > > > > > > > > -- > > > steve pirk > > > refiamerica.org > > > "father... the sleeper has awakened..." paul atreides - dune > > > kexp.org member august '09 > > > > > -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 - Google+ pirk.com

1 0

meeting network
by Randy Bush 11 Oct '11

11 Oct '11

perhaps as an educational exercise in network troubleshooting whoever is operating the meeting network could explain what the frack is wrong with the meeting network, how it is being debugged, and what they have learned about the cause of the suckage. randy

22 43

Y'all know Google is offering public DNS services now?
by steve pirk [egrep] 11 Oct '11

11 Oct '11

I saw this in a post from Travis Wise of Google yesterday. Pretty cool for those users who do not want to use their ISP's name servers, or just want to have dns resolve quickly from anywhere in the world. In either case, I think it is cool ;-] http://code.google.com/speed/public-dns/ Here is the original post - Yes, this one is public... oops! https://plus.google.com/111937447827665620879/posts/27S6QB8j1Ry Nice easy numbers to remember too. 8.8.8.8 and 8.8.4.4 -- steve pirk yensid "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09

9 13

EP.net and Almond Oil Process LLC?
by Chris Griffin 11 Oct '11

11 Oct '11

Anyone know what the current status is with EP.net and their new owner/parent company Almond Oil Process LLC? Some on this list may use EP.net services and have noticed the happenings of late. We contracted with EP.net for exchange space when it was owned by Bill Manning. Apparently it was sold and since then things have gone downhill. We were trying to get a simple authority record changed to no avail despite dozens of contact attempts, and now it appears the ep.net domain is functionally gone, which is causing even more issues. Any hints or current contact information would be helpful. Calls/email to ARIN POCs currently go unanswered. Tnx Chris -- Chris Griffin cgriffin(a)ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611

1 0

Enterprise WiFi list recommendations?
by James M Keller 11 Oct '11

11 Oct '11

All, I'm looking for some mailing list recommendations for wifi operations community, any commendations? Thanks in advance. -- --- James M Keller

5 6

2011.10.11 NANOG53 tuesday morning session notes
by Matthew Petach 11 Oct '11

11 Oct '11

Wow. People drank too much coffee this morning, they were talking at warp 10. Especially that Todd Underwood fellow; someone swap him out onto decaf next time. ^_^; Video stream worked much better today than yesterday, though VLC stream seemed to be running a bit odd, so I switched back to web stream instead. Notes from the morning session are posted at http://kestrel3.netflight.com/2011.10.11-nanog53-morning-session.txt in case they might be of use to people following along remotely. Thanks! Matt

1 0

new guest room SSID for NANOG
by Noah Weis 11 Oct '11

11 Oct '11

All, The hotel is in the process of deploying an SSID throughout the guest room network that terminates to the NANOG external router, rather than the hotel's gateway. The SSID is NANOG-guest. They stated it will take a couple of hours to be fully operational in the guest room space. As always, please let me know if you have any questions. Cheers, Noah -- Noah K. Weis Verilan, Inc. m: +1-503-902-2491

8 9

SP / Enterprise design (dis)similarities
by Tom Lanyon 11 Oct '11

11 Oct '11

Hi all, Looking for some advice or experience in a small enterprise / hosting provider context. There's plenty of BCP information around for SPs in the network design realm, and I'm curious how much of this applies to enterprises too. Commonly advised items like: * pull-up statics created on core devices, not network border devices * using iBGP to carry customer prefixes, not an IGP * announcing defaults over iBGP or IGP In some cases I imagine it may be simpler to have all BGP finish at the network border devices and not have to worry about running both IGP and iBGP sessions inwards to the core and/or aggregation devices. I understand the limitations of putting our Internet prefixes in an IGP, but for a hosting provider style network where everything is ethernet connected and within data centres there's much less route flapping to deal with (there's no bouncing DSL lines, for example). In the case that there is both iBGP and IGP running internally, is there any reason to choose one or the other to originate a default route to our aggregation/access layers? At some point I imagine it's going to be redistributed into the IGP (or re-originated in the IGP), so would think it would be best to just always run the default in the IGP to keep things consistent. Finally - are there any reasons to avoid running next-hop-self on ibgp sessions? The upside is we get to avoid distributing all of our transit/peer upstream point to point links into the rest of the network. Again, I understand this may be undesirable from a SP perspective, but when our 'clients' are all a bunch of internal servers it makes sense to keep iBGP/IGP as clean as possible... Thanks, Tom

5 6

Fwd: [Wikitech-l] WMF Staff Announcement - Welcome Leslie Carr!
by Jay Ashworth 11 Oct '11

11 Oct '11

I thought you guys might be vaguely amused by this reply on the Wikimedia tech mailing list to the announcement of Leslie Carr's move to the organization from Twitter: ----- Forwarded Message ----- > From: "Ashar Voultoiz" <hashar+wmf(a)free.fr> > To: wikitech-l(a)lists.wikimedia.org > Sent: Monday, October 10, 2011 2:19:19 PM > Subject: Re: [Wikitech-l] WMF Staff Announcement - Welcome Leslie Carr! > On 10/10/11 18:52, CT Woo wrote: > > Technical Operations department is pleased to announce another new fabulous > > staff member to its team. Please join us to welcome Leslie Carr, our > > Network Operations Engineer, starting today, 10/10/11. She is based > > in San Francisco office. > > leslie@life# configure exclusive > delete bgp group Employer peer-as 13414 > set bgp group Employer peer-as 14907 > leslie@life# commit > > Welcome! > > -- > Ashar Voultoiz Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

1 0

nanog53 network status
by Anton Kapela 11 Oct '11

11 Oct '11

Attendees, At present, we're aware of several issues affecting access to the NANOG attendee network -- in short, they include: -Apparent 'lumping' of iDevices, picking 11b/g channels of "1" and "6" (while channel 11 AP's sid idly by); adjusting additional AP's power and channel configuration to perturb this sub-optimal client selection logic. -AP's were permitting all frame bitrates (1 through 54 mbit encodings); these have been adjusted to include 5.5 mbits (cck, b) and 12 mbits (ofdm, g) encodings or greater (this reduces transmission duty cycles, frees up airtime, reduces contention, and hopefully performs better). -DHCP timer was set at 600 seconds; I'm informed that the lease time was increased to 3600 seconds at ~10:30AM PST today. Please relay any outstanding issues my way--I'll route to Verilan, which is handling the network and wireless support for the meeting. Best, -Tk

4 4