Re: ICANN registrar supporting v6 glue?
I'm pretty disappointed now, Searching the ICANN web site I found this: http://www.icann.org/committees/security/sac018.pdf Does anyone know what's been happening in the wake of that document? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Think glocally. Act confused.
Re: ICANN registrar supporting v6 glue?
At 9:23 -0700 6/29/07, Barrett Lyon wrote: I would like to support v6 so a native v6 only user can still communicate with my network, dns and all, apparently in practice that is not easy to do, which is somewhat ironic given all of the v6 push lately. It also seems like the roots are not even fully supporting this properly? Given that the ARIN BoT has published a call to move to IPv6: http://www.arin.net/media/releases/070521-v6-resolution.pdf and that LACNIC and .MX have made these statements: http://lacnic.net/en/anuncios/2007_agotamiento_ipv4.html http://www.nic.mx/es/Noticias_2?NEWS=220 and ICANN has been studying the issue: http://www.icann.org/committees/security/sac018.pdf What possibly can be done to get the root zone really available on IPv6? http://www.root-servers.org/ lists a few root servers as having IPv6 addresses, so really means having for i in a b c d e f g h i j k l m; do dig $i.root-servers.net +norec; done return at least one in the answer section. What's the hold up? What's getting worked on? Is there a dns-root-on-ipv6-deployment task force anywhere? Is there someone that can give an authoritative update on where we are on the road to being able to accomplish what is requested above? Part of my reaction is to the quip given all of the v6 push lately juxtaposed with NANOG 40 that barely mentioned IPv6 in the agenda. If we can't get one application (DNS) to do IPv6 how can we expect the ISPs to just up and deploy it? I would suspect that getting the roots - or just some of them - to legitimize their IPv6 presence would be easier than getting ISPs rolling. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Think glocally. Act confused.
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
At 17:42 +0100 6/28/07, Stephen Wilcox wrote: - that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on There's also the possibility: :- continued to be used as they are, just not seen on the Internet. Unrouted address space isn't always missing matter. (E.g., see GSMA PRD IR.40, http://www.gsmworld.com/documents/ireg/ir4040.pdf) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Think glocally. Act confused.
why same names, was Re: NANOG 40 agenda posted
At 8:22 -0700 5/29/07, David Conrad wrote: Jordi, On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote: This is useless. Users need to use the same name for both IPv4 and IPv6, Why? The IETF chose to create a new protocol instead of extending the old protocol. Even the way you ask for names is different (A vs. ). Why should anyone assume a one-to-one mapping between the two Internets based on those protocols? I'll take a stab at why? First - the way you ask for names is not different at the application level, it is different in the layer in which you find where to shoot packets. It's like paying at a cash register - you pay but by cash, charge, atm, ... But why need - okay, need is a strong word, but, if the user is coming from a search engine result page, the search engine is going to hand a URL with a machine name. The search engine doesn't know if the user to service has a v6 pipe (or a v4 pipe even), so the URL won't be customized for v4/v6. If the user types in the domain label (like nanog) and the application then adds on TLDs and such, the application would have to try the likely set of IPv6 labels to pre-pend. As far as any other encoding of the name, whether IPv6 is working is something that the encoder cannot know as the code will probably be run from different points of the collective IP4 and IP6 network. OTOH - in the presentation I gave in May '04 (three years ago - and I didn't think it was pioneering even then, but who knew) I did have some gotchas about using the same name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Sarcasm doesn't scale.
Re: Interesting new dns failures
At 3:50 PM -0500 5/21/07, Gadi Evron wrote: As to NS fastflux, I think you are right. But it may also be an issue of policy. Is there a reason today to allow any domain to change NSs constantly? Although I rarely find analogies useful when trying to explain something, I want to use one now to see if I understand this. Let's say you rob convenience stores as a career choice. Once your deed is done, you need to get away fast. So moving fast is a real help to criminals. Since moving fast is rarely helpful for decent folk, maybe we should just slow every one down - this certainly would make it easier for law enforcement to catch the criminals. If the above is not an accurate analogy to the NS fastflux issue, I'd like to know what the deviations are. I don't doubt there are any, but from what little I've gathered, the problem isn't the NS fastflux but the activity that it hides - if it is indeed hiding activity. As in, not every one speeding around town is running from the law. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Sarcasm doesn't scale.
Re: UK ISP threatens security researcher
At 18:30 -0500 4/17/07, Gadi Evron wrote: http://www.theregister.com/2007/04/17/hackers_service_terminated/ A 21-year-old college student in London had his internet service terminated and was threatened with legal action after publishing details of a critical vulnerability that can compromise the security of the ISP's subscribers. I don't see any part of the story that indicates that the ISP did wrong, I see plenty that the student did wrong. E.g., did the student ever try to discreetly raise the issue with the ISP before going public? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Sarcasm doesn't scale.
Re: UK ISP threatens security researcher
At 11:32 -0700 4/19/07, Owen DeLong wrote: Being that I know nothing more than what is in the article, I will go along with the assessment that the ISP could have done a better job in running their network. But I don't think that their reaction is uncalled for (given again that the article is all that I have to go on). He was definitely in a gray area and could have handled things better, but, the ISPs actions are way over the top and beyond reason for the situation in question. The article fails to mention whether the student did try to use proper channels. Perhaps he did - that would change my assessment. Passing judgement on so little data - and data in the press at that - is only as good as, well, the data presented. Employing official channels is preferable to public humiliation. Complaints that postmaster@ isn't set up correctly take on bigger importance when we can say we tried to contact you via proper channels but then had to take our complaint public. When I hear about such stunts, I wonder if the student did this all for self-promotion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Sarcasm doesn't scale.
Re: Every incident is an opportunity
At 5:12 + 2/13/07, Paul Vixie wrote: [EMAIL PROTECTED] (Barry Shein) writes: ... If your goal is invasion then value preservation is important (factories, bridges, civilian infrastructure, etc.) ... so if the last remaining superpower were to bomb a country in the middle east in preparation for invasion, regime change, etc., that superpower would be well advised to avoid hitting civilian infrastructure, assuming that its bombs were smart enough to target like that? (i'm sorry, but your theory doesn't sound plausible given recent events.) What theory is plausible? DNSSEC even sounded good on the drawing board. ;) I think that war strategists have always only wanted to attack the other side's war machine and political machine. (Said sarcastically:) A bullet in a civilian is a waste of metal after all. The problem is that theory and operations don't mesh well. A bomb that killed only warriors and their infrastructure and left schools and children safe is as likely to exist as an electronic messaging protocol that prevented spam but let good email through. (How's that at trying to come back to being on topic?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Two years ago you said we had 5-7 years, now you are saying 3-5. What I need from you is a consistent story...
motivating security, was Re: Every incident...
I've worked in security for some time, not that it makes me an expert but I have seen how it is promoted/advertised. On Feb/12/07, someone wrote: Consumers are cheap and lazy. I think that is the wrong place to start. It isn't the consumer's fault that they have a device more dangerous than they think. Look at what the are being sold - a device to store memories, a device to entertain them, a device to connect with people they want to talk to. Everyone economizes on what they think is unimportant. A consumer doesn't care for the software, they care for the person on the other side of the connection. They care about the colors in the office, the taste of the food, etc. So it may appear they low-ball that part of the computer equation. My point is that it is convenient to blame this on the consumers when the problem is that the technology is still just half-baked. What they need is a serious incentive to care about security. I find this to be a particularly revolting thought with regards to security. Security is never something I should want, it is always something I have to have. Not need but something I am resigned to have to have. This is like saying folks will have to die before a traffic signal is put here or more planes will have to be taken by hijackers before the TSA is given the funding it needs. Security shouldn't wait for a disaster to promote it - you might as well be chasing ambulances. Security has to resign itself to being second-class in the hearts and minds of society. Security has to be provided in response to it's environment and not complain about it's lot in life. (I realize that this post doesn't say anything about people dying - I've heard that in other contexts.) Society holds individuals accountable for many forms of irresponsible behaviour. This is true, but individuals are not held entirely accountable. A reckless driver can cause a multi-car accident on an exit ramps and cause a tie up for the entire morning rush. Are the victims of this compensated? What about the person who loses a job offer because of a missed interview and suffers fallout from that? And maybe it isn't recklessness. A failed water pump may cause a breakdown, followed by an accident, etc. Mentioned just to spread the analogy out. There's no need to make exceptions for computer users. Make computer-owners/users pay in full for damages caused by their equipment with no discount for incompetence. If that happened, then computer users would be the exception. I can't think of any situation in which an accident might occur and the one causing the accident pays in full to everyone. Insecure products might then be considered inappropriate for public consumption and that would be a powerful signal to the IT industry to change their ways. Maybe the market also finally would challenge the validity (or even existence) of std.disclaimer statements common in today's software licences. I used to work for a gov't facility whose mission was science. They had a serious telecommunications problem on their hands. Although it was important to solve, they funded science first - up until all the telecom problems became too annoying and money was allocated to solve the problem. There are IT security problems. But there are other priorities in life. Instead of complaining that IP security is under appreciated, the case has to be made that the situation is more serious than some other problem. If that case can't be made, than may be IT security is not that big if a deal (to anyone other than you). Don't get frustrated, present a better case. And be prepared that you still may not win. But never wish ill-will (as serious incentive alludes to) on someone to prove your point. BTW-This isn't meant to be a critique on one message. It's my reaction to quite a few messages that are similar and to some comments I have heard. Sorry if it seems like I'm attacking a single messenger. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Two years ago you said we had 5-7 years, now you are saying 3-5. What I need from you is a consistent story...
Re: motivating security, was Re: Every incident...
At 14:59 + 2/12/07, Alexander Harrowell wrote: The whole logic of modern computing is that everything migrates towards users. Why shouldn't security? After all, if people didn't let the nasties in, 'twould be very hard to start a botnet.. Regarding letting the users in there was a story on the news while we were meeting in Toronto. A woman put her child in her car while it was warming and then went back into the house for 10 seconds. A thief jumped in the car, drove a while, crashed and fled the scene, stealing another car (that was also idling) to get away. The TV reports were very sympathetic to the woman and her husband (who was painted a hero for chasing down the suspect to the crash). A week earlier, in the DC metro area, there was a story about the police ticketing people for letting their cards idle unattended. The reason for the report was awareness of a new enforcement of the law that had been put on the books to stem auto theft in that county. One woman was ticketed having left some small children in the car while she went back into get one more item. The reporter asked what if someone ran here and just drove off? What I found interesting is the differences in the way the car owners were portrayed. It's not a US v. Canada thing, but just a point of view. Similarly, are the people who are running exploitable machines the cause of the problem or victims of those exploiting the machines? I don't mean to say that the car owners or computer users are free from blame. But holding a sentiment of just blaming users is not helpful. OTOH, if there was something the operators could clearly do to stop this, someone would have suggested it by now. (There are all them laws about snooping traffic, etc.) I thought I had a conclusion ... but I don't. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Two years ago you said we had 5-7 years, now you are saying 3-5. What I need from you is a consistent story...
on a different manners topic, was Re: Phishing...
I'm not going to pick on the it's (grammatically correct, but it refers the email disclaimers which I don't feel like commenting on) but I want to say that I've come to appreciate top-posting. With top-posts, there is no need to scroll down the list, and it is more like a conversation than injecting comments in-line. Some say that top-posting reverses the conversation, but if you are thumbing through the archives of top-posted threads, each contribution is on the first screen and you can navigate message to message in time-order. In my personal opinion, reading through archives of in-lined threads is much more of a problem - for one because threads take off in other directions and an in-line conversation never stands alone. Usually with a few nested in-lines I loose who said what context too. (As an exercise, try to prepare a reply in-line and then as a top-post. You will see that in-line means less typing, as you don't have to rephrase the question. In-line is less work to render, but I think it is a poor communication style.) As far as the HTML, I don't think I use it, but I fail to see why it's rude. Sorry, it is newer technology and it does screw up old tools. (I do get bit by it - the hotels seem to love HTML confirmations that I can't read on my work mailer.) It's my/reader's choice to not use newer tools. I do agree that full quoting is a pain - especially when the message is less than 1% new content. Especially when all them new headers (DKIM keys and what not) fill up my screen first anyway. Yeah, I know, upgrade. There. I've said it...oh, and the disclaimers don't give me heartburn. I just ignore them. At 8:03 -0500 1/3/07, Rich Kulawiec wrote: Because it's very rude -- like top-posting, or full-quoting, or sending email marked up with HTML. Because it's an unprovoked threat. Because -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch.
today's Wash Post Business section
Maybe OT, but surprising enough - On this link to a graphic printed in today's Washington Post: http://www.washingtonpost.com/wp-dyn/content/graphic/2006/12/20/GR200612289.html The #10 google search in the Who Is category (leading off with Borat, Hezbollah, EU, hot, ...) is IP Who Is. I'm not sure what to make of that. Has google replaced the whois client? The article for the graphic is on this link: http://www.washingtonpost.com/wp-dyn/content/article/2006/12/19/AR2006121901471.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch.
Re: today's Wash Post Business section
At 19:31 -0800 12/20/06, Thomas Leavitt wrote: Many people don't understand anything about how they access the Internet, they have a vague idea that they need to type a domain name into a box somewhere... so they type www.myspace.com into the Google search box, the result set pops up, and then they click on the first result to get to the web site in question... I've seen it more than once. Thomas Yeah, granted anyone looking for myspace might meet that demographic, but how many neophytes would use Google for a IP Who Is search? That's the listing I thought odd. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Dessert - aka Service Pack 1 for lunch.
Re: IP adresss management verification
At 10:36 -0500 11/13/06, John Curran wrote: A more interesting question might be: How does the community think an RIR should best verify information in the application process today, and should that change as we approach the IPv4 event horizon? IRIS. ;) ARIN is in a tricky place. It has to be open, fair, efficient, and able to keep a secret. Open - listens to the industry without requiring any membership. Fair - policies apply to all on face value. Efficient - low cost to the industry. Keeping secrets - holding confidential data used to justify resource allocations. As long as there is trust, the most efficient way is to rely on what an applicant (for space) claims. Once trust breaks down, all sorts of verification is needed. There are two parts to this. One is what is appropriate for ARIN to rely upon to verify an application. The other is what is an appropriate way for a third party to question the allocation of resources. I mentioned IRIS above because it is more or less WhoIs-on-steroids. One of it's features is the ability to authenticate the client, therefore various clients can be authorized to see different (in detail) data. E.g., to the casual observer, 258.127.3.123 belongs to private residence but to ARIN it belongs to Homer Simpson of Springfield. (ARIN can then verify that the addresses in 258.127.3/24 are assigned to different residences.) I'm guilty here of throwing out a solution before the problem. I'm doing this to say that although there is a problem (not as in we gotta solve this now problem) and it is quite undefined (how does a third party appeal an allocation, and how does ARIN defend a decision?), we have tools available to work on this already. Ooh, look, something that looks like a nail. Let me hit it with my IRIS hammer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar I didn't miss the meeting, I left it before I arrived.
Re: Collocation Access
But, I always thought that the purpose of most security was psychological reassurance anyway... Reacting to this and the story of just walking through the backdoor to get in - I think there's an element of self-fulfilling prophecy here. If the legitimate power users of the security system (i.e., the royal we/us) don't take it seriously, the security system will be useless against the nefarious element. It might be that the reason security is often so poorly implemented is that the job is often left to the unmotivated or the untrained (or differently trained - I mean in a good way). Perhaps these folks realize that their tasks are scoffed at, further lowering their gruntlement. (As in disgruntled.) What would be different if, instead of exploiting the open back door, the open back door is pointed out to the folks responsible for the facility? I don't mean mentioning this to the security guards who may have interests in back doors remaining open and/or just not reported. Whether the door was left open on purpose or not, a guard may lose a job over it - if the facility management took it seriously. (What would happen if someone actually obeyed the speed limit in the US?) One personality trait I find strong in this community is that desire to be able to cut through formality and red-tape and to push convention aside. This can be good for quick and productive innovation but at the same time detracts from the importance of the task at hand. Security by its nature is not fun, not productive, a drain on resources and time. Security is something we need only because there are bad things out there - nefarious activity, inadvertent neglect, design flaws, etc. At best you have to put up with security, don't expect to enjoy it. Arguing about any policy with someone hired to follow it is not productive. The hired can't do much about it, and there is no incentive for them to fix their job. At worst they can lose it by wasting time questioning their supervisors. Concerns about policy have to be raised to the level of those who can do something about it and have an incentive to fix it. No one is going to lay out more money for no more revenue if there's no other upside to it, that has to be kept in mind too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
Re: Need help explaining in-addr.arpa to Limelight
At 18:48 -0400 10/23/06, Joseph S D Yao wrote: No, because in fact you can. There is nothing magic about an in-addr.arpa domain. I'd say there is some magic. Possibly. If an admin were granted the authority for a /25 worth of space, then you can't just delegate that part of the in-addr.arpa domain. That's the RFC Joe Abley cited. A /24 can be delegated (assuming we are talking about 255 addresses, from .0 to .255). Perhaps, and this is weak speculation, the ISP in question is not used to SWIPing /24 and has an institutional policy of using RFC 2317 in all cases. As far as the DNS protocol goes, there's nothing different between the forward and reverse. But there are differences in the conventions used for placing data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
Re: that 4byte ASN you were considering...
At 9:44 +0100 10/10/06, [EMAIL PROTECTED] wrote: It breaks any applications which recognize IP address-like objects by seeing a dot in an otherwise numeric token. I can't believe grown engineers are afraid of a dot. We all know that the Internet is awash in homegrown scripts written in PERL or TCL or bash or Ruby or Python. It is likely I find that more of a reason to do a change than to leave well enough alone. What's gonna happen when all of the current generation (the writers of the scripts) retire and close the door on their careers? How will the Internet live on? Shouldn't a technical beast be able to thrive on technical changes? But that question isn't germane to the issue at hand. The real question is what does the notation 1.0 add that the notation 65536 does not provide? Fair enough - my answer is it provides the same as the dotted quad for IP, it makes it easier for human to human conveyance. It also makes the transition from 2 byte to 4 byte more obvious in the interim. If the IETF had really wanted to create a universal notation The IETF really doesn't want to create anything. The IETF is just a forum where folks can gather to discuss an issue like this. (Pardon my second non-germane comment on this thread.) When IP addresses were created, it was important to indicate the boundaries between the network number and the host address. Originally, the periods represented this boundary for the three classes of IP address, class A, class B and class C. Long ago, we removed this classfulness attribute, but the notation remains because lots of applications expect this notation. So why on earth are we changing AS number notation today? For the same reason - to distinguish the boundaries between what the old engineers know from what the future young engineers will take for granted. The dot would outlast the old engineers just as the dotted quad persists into the CIDR age. Why on earth? Because there aren't [m]any IP addresses on the moon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch.
Re: rDNS naming conventions (was: Re: SORBS Contact)
At 15:47 + 8/10/06, [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 10:21:45AM -0400, Steven Champeon wrote: on Thu, Aug 10, 2006 at 01:11:50AM -0700, william(at)elan.net wrote: On Aug 9, 2006, at 1:06 PM, Matthew Sullivan wrote: http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt The reason I do not like RDNS naming scheme is because it forces one particular policy as part of the name. Fair enough. FWIW, I've seen a wide variety of naming schemes (I've got a project that collects these as an antispam/anti-botnet measure, and so far we've got around 16K conventions documented for 11K domains). first... as a draft, it carries ZERO weight. -IF- it becomes an RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind. So no one is going to -force- you to implement it. hum... why does this draft remind me of the (in)famous WKS RR? what is WKS? you know, that RR type that specified the well known services running on/at the particular lable. WKS was depricated, in part due to the fact that black hats would use WKS to groom thair attack profiles. Use of the conventions outlined in this draft would be very useful in building targeted attacks. To paraphrase Randy Bush, I encourage all my competition to implement these guidelines. Piling on here ... The effort is to infer the intent of a packet based on ancillary data. The twin dangers here are inference of intent and exposure of the ancillary data. The first part is like asking would I want to have security research done by a company on Glenwood Road or on Shady Lane? (Ya, know shady in security.) Legend has it that one research company moved it's location because of this, or maybe it was a joke that came afterwards. The second part is what ancillary data is exposed. You can require, you can request, or you can assume you won't get the data you need. Sometimes you won't get it because the giver doesn't want the headache of providing it or because the giver is afraid of the ancillary data going to nefarious uses. My point is that inferring intent based on incomplete data is faulty, but it seems to be useable in real life. However, once heuristics get encoded in deterministic algorithms, the results generally are not so good - mostly because the encoding of the heuristics fails. The answer is to include things like RFC 3514, (Note the pub date.) or ancillary data. But the solution of adding ancillary data maybe worse than the disease. This is just one of the hard problems. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America.
gated communities - was Re: mitigating botnet
At 6:29 AM + 8/2/06, Paul Vixie wrote: as was true of spam when i said this about spam ten years ago, it is true now of botnets that the only technical solution is gated communities. but the internet's culture, which merely mirrors the biases of those who use it, requires the ability for children to go door to door selling girl scout cookies, without necessarily having the key code to every one of the doors. I agree with this in a number of dimensions. One, look at mankind's physical security over the centuries. Walled cities were once in vogue for defense. (Sieges were a DOS attack.) Walled defenses evolved over time, yet there was always a need to have gates for commerce. Eventually walls have become unimportant (mere tourist curiosities) as wealth has shifted from the physical to monetary realm (and then from gold bars to electronic accounts). The goals of attacks, and the methods of attack shift. Defensive strategies must, okay, ought to shift too. Two, look at the DHS recommendation to secure the Internet via DNSSEC and enhancing BGP. What amounts to an unfunded mandate to everyone to protect themselves hasn't given much impetus to everybody pitching in and making a safer Internet. My recommendation would have been for the DHS to say to the (US Federal) government the Internet's an unsafe place, protect your self in dealing with contractors and bidders but requiring all transactions be done with suitable security. Basically protect your own first, recommend safer actions for others, and allow those that want to be at risk to continue doing so. What I mean here is that building a gated community is more likely to happen around the assets the government needs to protect than the government is going to get others to voluntarily spend more resources to defend against boogymen that may or may not exist. Money is more easily spent to answer a need you know than to follow a recommendation from someone you don't. What is considered an acceptable level of safety is relative. For those who get to ride in cars (taxis) around the world, how many times have you been in a cab that has done something illegal in your home country but is considered safe in another (because the action is 'expected')? Gated communities, wall gardens, same thing. Both are counter to the philosophy of which spawned the Internet. But they may also be the only way to make the Internet a reliable tool for mankind and not just an academic exercise run amok. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America.
Re: gated communities - was Re: mitigating botnet
It was pointed out to me that I'm even less of a historian than a lawyer...walls became unimportant (security-wise) when warfare changed. But still, what's being defended has also changed. At 10:22 AM -0400 8/2/06, Edward Lewis wrote: At 6:29 AM + 8/2/06, Paul Vixie wrote: as was true of spam when i said this about spam ten years ago, it is true now of botnets that the only technical solution is gated communities. but the internet's culture, which merely mirrors the biases of those who use it, requires the ability for children to go door to door selling girl scout cookies, without necessarily having the key code to every one of the doors. I agree with this in a number of dimensions. One, look at mankind's physical security over the centuries. Walled cities were once in vogue for defense. (Sieges were a DOS attack.) Walled defenses evolved over time, yet there was always a need to have gates for commerce. Eventually walls have become unimportant (mere tourist curiosities) as wealth has shifted from the physical to monetary realm (and then from gold bars to electronic accounts). The goals of attacks, and the methods of attack shift. Defensive strategies must, okay, ought to shift too. Two, look at the DHS recommendation to secure the Internet via DNSSEC and enhancing BGP. What amounts to an unfunded mandate to everyone to protect themselves hasn't given much impetus to everybody pitching in and making a safer Internet. My recommendation would have been for the DHS to say to the (US Federal) government the Internet's an unsafe place, protect your self in dealing with contractors and bidders but requiring all transactions be done with suitable security. Basically protect your own first, recommend safer actions for others, and allow those that want to be at risk to continue doing so. What I mean here is that building a gated community is more likely to happen around the assets the government needs to protect than the government is going to get others to voluntarily spend more resources to defend against boogymen that may or may not exist. Money is more easily spent to answer a need you know than to follow a recommendation from someone you don't. What is considered an acceptable level of safety is relative. For those who get to ride in cars (taxis) around the world, how many times have you been in a cab that has done something illegal in your home country but is considered safe in another (because the action is 'expected')? Gated communities, wall gardens, same thing. Both are counter to the philosophy of which spawned the Internet. But they may also be the only way to make the Internet a reliable tool for mankind and not just an academic exercise run amok. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America.
Re: DNSSEC in Plain English
At 11:11 +0100 6/15/06, [EMAIL PROTECTED] wrote: certificates, and so on. This is fine for a technical audience but it won't help explain the issue to the decision makers who spend the money. We should be clear on who the decision makers are. I've spent a long time trying to trick folks with engineering budgets and policy roles into doing DNSSEC. As much as they have been sympathetic to the cause, they can't find the justification they need to make DNSSEC happen. It's not that they are ignorant. It's that they answer to other authorities - not the *gasp* engineers. The people who have investments in the Internet are the decision makers here. The consumers of the Internet, those who buy its services and turn them around for a profit, are the decision makers. They are the ones exposed to risk, they are the ones to best judge if DNSSEC fills a need. Unfortunately, I don't speak their language. Shucks, I'm just a simple country engineer from the old days. I do not mean to say we should stop technical discussions of DNSSEC nor stop the education process happening today. I also don't mean to say that we ought to give up on developing tools that will make DNSSEC less onerous. I mean to say that the effort to deploy DNSSEC has to consider (or increase what's done now) reaching out to those who we think are the consumers or beneficiaries of DNSSEC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: wrt joao damas' DLV talk on wednesday
At 10:20 +0100 6/14/06, [EMAIL PROTECTED] wrote: Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? I think a lot of Over and over and over and over again. (Not to say we've done enough! but we've done all we can think of.) 1) Google for DNSSEC introduction 2) Look at http://www.dnssec.net/ 3) This has no crypto: http://apricot.net/apricot2005/slides/T11-3.pdf (a discussion of what it means to registries to pull it off) 4) Or this, for a NANOG presentation: (NANOG 32) http://www.nanog.org/mtg-0410/pdf/crocker.pdf If what you see isn't clear, ask the respective presenters. Maybe we haven't been clear enough. But, many have considered...maybe the only beneficiary has been the travel industry (through our buying of tickets/rooms). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: wrt joao damas' DLV talk on wednesday
At 11:37 -0700 6/13/06, Randy Bush wrote: can you say does not scale? or how about works poorly when a zone is transferred? There are two ways to look at scaling. Scaling in volume and scaling across generations. DLV definitely does not scale across generations with such a person-to-person protocol backing it up. But if it's just a bootstrap mechanism, then I think it's acceptable. As far as volume scale, DLV puts more work onto whomever configures DLV repository data in resolvers. A DLV per TLD might lower the work for the TLD, and possibly remove the need to develop NSEC3 and opt-in. (As DLV only lists the DNSSEC'd zones.) i think there is no question that you and isc mean well. but we've entered the the twisty passages of security. DLV at least lets those who are able and willing to take the risk to gain first hand experience. If the ISC DLV runs for 5 years without an incident, even with the non-scalable approach as documented, it'll be seen as a winner. The longer it runs without incident, the more trustworthy it'll (appear to) be, right up until the point that it no longer scales. If there's an incident, then it won't be trusted but we will probably learn from the experience. Hopefully the lesson will come cheap. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
to DLV or not
My background and position on this is best summed up as one of the early implementers of DNSSEC and now working for a gTLD/ccTLD registry. In between I spent a lot of time developing, redeveloping DNSSEC in the face of operational realities. (To those who are critics of DNSSEC, I ask forgiveness for my wasted middle-age.) DLV is a concept that someone somewhere in the past few years came up with to put needed DNSSEC data in a special location. Although DLV per se is novel in the development of DNSSEC, it is well in-line with the earliest intentions of the protocol dreamers. The original DNSSEC design was to allow any resolver (client) to decide how it would collect the needed records to substantiate an answer. In the mid to late 90's we tried to figure out how to first express a policy and then come up with something that could take the policy and direct the operation of a DNS validator (the thing that gives a thumbs up or down to an answer after checking the DNSSEC stuff). We punted, resulting in RFC 3008, which said that the only common policy was to follow the tree, i.e., root signs tlds, tlds, sign down, etc. A few years later, a project called FMESHD to reopen the policy to be more general. Again, the problem proved too big to solve. Why DLV is different from these two failures is that we had been trying to solve the general case without a validator in hand. (We did have validators, but nothing that was integrated with a real name server.) DLV is starting from an implementation and is a pragmatic attack on the problem. DLV is not as general as the original idea, but wider than RFC 3008. The main concern with DLV is that is it not scaleable. That's inherent in the problem so I am not surprised. The tradeoff is that you can go off the tree but at the cost of knowing where you are going off the tree. Some folks feel that DLV will compete with TLD registries and delay their interest. Or maybe, for the same reason, spur their interest. My opinion is neither, DLV is orthogonal to the TLDs. DLV may be a good measure of interest in DNSSEC though. Either there will be no interest, a quick spike in interest, or a sustained growth. My guess is the middle option - a lot of early registrations and then slow growth. If that's the case, scaling isn't the concern and it won't spur the registries to add DNSSEC. So, ISC's DLV operation? The developers of BIND are free to distribute code with a validation policy that looks up data in their DLV. If all works, then all is good. If it's a disaster, ISC's DLV will cease and the code will cease to have the feature. Let the market decide. I don't think that what the pro-s and anti-s *think* matters as much as having tangible data on what *happened*. If the techies still rule the Internet, something like DLV ought to be given a try. Show off a technical solution and use that as an example of the way forward. We've been stalling long enough trying to move policy makers to sign the root zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: How to tell if something is anycasted?
At 15:45 -0700 5/16/06, Steve Gibbard wrote: The approach I settled on was to ask lots of questions, and then do some traceroutes to verify once I knew where to look. If I knew there was supposed to be a server in location x, a looking glass near location x would probably find it for me. From my experience, passively detecting how something is assembled on the Internet has gotten harder with each passing year. Whether it is from intentional obfuscation or just evolutionary new operational practices, you can tell a lot less about a set up now that in the past. What Steve says is the right thing to do. Get off-net ask questions and then verify on-net. Not just for anycasting, for just about anything. The network is a lot less obvious that it used to be. For better or worse, depending on your point of view. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: do bogon filters still help?
No data, but I thought I should add...RFC 3330 Special-Use IPv4 Addresses lists the obvious stuff. I just went through an exercise in de-bogonizing and needed that reference. [http://www.ietf.org/rfc/rfc3330.txt] Be careful though. It lists 24.0.0.0/8 as special, explaining that this went to cable operators (and eventually administered via ARIN). So don't just use the Summary Table in section 3 blindly. At 13:03 -0500 1/11/06, Steven M. Bellovin wrote: Every time IANA allocates new prefixes, we're treated to complaints about sites that are not reachable because they're in the new space and some places haven't updated their bogon filters. My question is this: have we reached a point where the bogon filters are causing more pain than they're worth? The Team Cymru web page (http://www.cymru.com/Bogons/index.html) gives some justification, but I think the question should be revisited. First, as the page (and the associated presentation) note, most of the benefit comes from filtering obvious stuff -- 0/8, 127/8, and class D and E source addresses. Second, the study is about 5 years old, maybe more; attack patterns have changed since then. Third, considerably more address space has been allocated; this means that the percentage of address space that can be considered bogus is significantly smaller. Possibly, there are more sites doing edge filtering, but I'd hate to count on that. So -- I'd like people to re-examine the question. Does anyone have more recent data on the frequency of bogons as a percentage of attack packets? What would that number look like if you filtered just the obvious -- the ranges given above, plus the RFC 1918 prefixes? Are your defenses against non-spoofed attacks really helped by the extra filtering? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Inactionable unintelligence is bliss.
Re: do bogon filters still help?
At 20:28 +0100 1/11/06, Florian Weimer wrote: * Martin Hannigan: You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local). Good example as to why to use authoratative sources only. But most authoritative sources are too shy to make explicit operational recommendations. 8-) The authoritative sources put the data out there. What more can you ask of them? What more do you want? It's been said that the neutral parties (the authorities are supposed to be neutral) should not make business decisions for the industry. Recommending route filters is a business decision. Operational recommendations in general are business decisions. Consider it lucky you have a choice here. The plain official version, William's marked up copy, and edits to William's on the list. You have a choice here, you can't beat that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Inactionable unintelligence is bliss.
RE: Let's talk about ICANN
At 7:56 -0800 12/12/05, william(at)elan.net wrote: On Mon, 12 Dec 2005, Hannigan, Martin wrote: I would think that ICANN is off topic for NANOG? Are you saying there is no operational impact in the decisions made by ICANN? That's not how I read the comment. The impact of ICANN on NANOG would be on topic. A general let's talk about ICANN is best done in a forum designed for discussing ICANN. It's not a sin to discuss ICANN on NANOG, but it's barking up the wrong tree. If anyone has any questions or concerns about any organization, go to an appropriate forum. Don't talk about an organization (or person) behind its back. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
Re: Viral Cure Could 'Immunise' The Internet
At 9:30 -0500 12/9/05, [EMAIL PROTECTED] wrote: Thought folks might find this interesting http://www.newscientist.com/article.ns?id=dn8403 Viral Cure Could 'Immunise' The Internet, New Scientist Excerpts: A cure for computer viruses that spreads in a viral fashion could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Most conventional anti-virus programs use signatures to identify and block viruses. But experts must first analyse a virus before sending out the fix. This means that rapidly spreading viruses can cause widespread damage before being stopped. Source: Viral Cure Could 'Immunise' The Internet, Kurt Kleiner, NewScientist, 05/12/01 This has been thought of many times. My spin around this was attached to DARPA's Active Network (http://www.darpa.mil/ato/programs/AN/). The eternal question in security is what are you defending against? Because of that, security will always have a strong reactionary element. I can't cite any, but I recall hearing some claims that viruses in the past were meant to fix problems or highlight in a benign way the presence of problems. It's been tried in real life, I don't see that a mathematical study is going to come up with a result that is more meaningful. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
cross-registry interactions was Re: BGP ... PKI...
At 17:06 -1000 11/23/05, Randy Bush wrote: i have been whining about the problems of cross-registry operation for over a decade, formally, informally, presos, ... i have had it on every rir's meeting agenda (except lacnic) for many years. do i need to iterate for every ort of service the registries provide? Sometimes I think you are right about this and sometimes I think you are wrong about this. It just may be that you are thinking only about the right half, but operation of the registry to some means the policy process too. Where I see this as wrong is: There are five distinct RIRs for a reason, to be attuned to local needs. The domain name industry has one RIR asserting authority and we see the political fallout of that. Having the five RIRs locked together would certainly benefit (usually the larger) organizations that deal across RIR boundaries, most likely (and I say that without certainty or accusation) to the detriment of smaller organizations tuned to the needs within one RIR. I think it's very important that we keep the policy processes - the decision making part, and even discussion - separate. Yes, that means it takes a long time to get a global (effectively, one involving IANA) policy through. On the other hand, you are right when it comes to the technical services rendered and the interfaces used. That's because the use of the data is global, no doubt about that. A student sending mail from Africa to Asia will traverse two or three RIR area networks, just to show how 1 consumer can cause a cross-RIR event. One of the dynamics I see happening now is that the RIRs are independently developing some advanced services. RIPE into DNSSEC, APNIC into certificates, LACNIC into IRIS and unifying the RIR WhoIs data. These advancements happen locally much faster than globally, as is true with any innovation. Failed attempts at advancement will be easier to recover from too. Eventually we want these services to be global, but in development I expect differences. we are the registries' customers. many of us, especially the ones who pay the registries the most, have to deal with multiple registries. can the registries please get over the inter-registry rivalry and make life more reasonable for us, the paying members? Keep in mind that the RIRs were originally cobbled together out of different cloth. Unifying the service interface will take an investment in doing that. This is why I have made comments at ARIN meetings about providing technical input to ARIN - trying to define a way to have the community, or even just the membership, inform ARIN on what service interfaces we would like to see in an open, reviewable arena. ARIN has this for policies, but the path towards service upgrades is not as well defined. It's one thing to lay heat at the feet of organizations, it's another to make clear the reason for the heat. where as before i was merely inclined, this has just made me an extremely strong proponent of the isp web of trust identity model. The upside of this is that it directly addresses the routing problem - ISPs get to determine who they trust for the data they rely on. On the other hand, ultimately a web of trust has to fair to newcomers, not rely on superficial popularity, and obviously scaleable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
Re: BGP Security and PKI Hierarchies
After reading this thread well after it has ended...why does it seem that a lot of folks equate trust with paying money? Trust isn't about who can pay what but maintaining a system that conveys trust does *cost* money. The RIRs are not-for-profit themselves. That doesn't mean service-for-no-fee. I don't see that an RIR has any obligation to speak on behalf of (in this case, issue certificates for) any other organization that holds IP space and has not established any arrangement with the RIR. On the other hand, any such organization cannot expect an RIR to do something for them for free. If the ISP industry wants there to be certificates for the so-called swamp space (badly enough), what would stop them from subsidizing the the work? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
Re: IAB and private numbering
At 13:59 -0800 11/11/05, Tony Tauber wrote: There are some resources, like IP addresses and AS numbers, the proper operation of which hinges on their uniqueness. ... Does this concern make sense? Does this course of action make sense? Is there a(nother) better venue than the IAB? What do people think? (Yeah, I did read the rest of the thread, but am replying to the original message.) I think there are a few dilemmas in this topic. One stems from the RIR's duty to provide stewardship of the number resources they administer. The other is the dividing line between protocol design (IAB) and operations (RIRs). One concern from this is number resources depletion, which is why, in my estimation, there are people measuring things like announced space and time to network with AS numbers. (I'm referring to work Geoff Huston, Tony Hain, and Henk U of RIPE have presented in numerous locations in the past few months.) When a resource is becoming scarce, there's a push to try and be certain that it is being used efficiently, with efficiency measured in terms of time to depletion. With this in mind, if a resource is used privately, why can't it be used publicly too by some deserving? (I ask this rhetorically as an example.) Stewardship also means uniqueness too, or at least uniqueness in some scope. (A 48 bit number could be a hardware address or a combination IPv4 and port number, as an example of stretching.) To achieve this, the RIRs would naturally assign an number to anyone deserving, regardless of how the network is connected. Combine that with a third dimension, that the RIRs are run in the context of some sort of public trust, there are folks that will want to check up on them. That's where we get folks probing the exposed data (via whois, say) and seeing what they can get to. I think this is where the assumption of a public internet comes from. This is a three-way conflict centered on the RIRs. There's the whole matter of the benefit vs. pain of scoped (as in site local, link local, RFC 1918) addressing. That's a matter for the protocol engineers to figure out, I think that is something the IAB would be concerned about - if not so already. I don't think that you want to have the directory services of the RIRs (whois today) flag addresses as public use or private use, but you do what the defined protocol scope clearly indicated. The reason for not labelling public or private is that there are multiple private (if there is indeed one true public). If you see two private addresses, can they see each other? In as much as we don't want the RIR's in the routers, we shouldn't put the routers into the RIRs. The outcome of this is that folks probing and prodding the data in the RIRs ought to not expect to see all the resources registered therein on the public Internet. It would tempting to say not to worry about unseen resources, to assume they are in the private areas of the world. However, there are probably resources that are lost - allocated in the days when IANA was a small part of ISI and things were done on paper. In the effort to stop depletion, these should be reclaimed, but deciding what is lost versus what is in private use is ... a dilemma. My experience in this is tied to DNS and lame delegations. Just like the routing table issue, we have delegations into places that are not reachable. A name server may be situated in a way in which it can see out but we cannot see in. The problem with these seems to be some past implementations of DNS that looped as a result of lame delegations (in this case situations in which the desired name server[s] are not reachable). Maybe this is where the IAB steps in, and looks for documents showing how members of a network, whether the public or a private network, can either protect themselves from trying to reach unreachable areas, or to set up stub or proxy services to absorb ill-fated traffic destined to an unreachable address. I'm not sure this is feasible - the DNSOP WG seems to have killed, or is about to kill a document on don't publish unreachable things in the DNS. As much as that sounds useful, there was no energy in the group to finish the document. A lack of energy tells me something. Scoped addresses do run afoul of the theory that a network is a collection on mutually reachable endpoints. Once you scope an address, you've lost the theory of the network layer. Still, it does work to do this, so it's not that it's impossible, it's that the theory needs to be, umm, scoped. I've thought far less about this, but that's the kind of thing that the IAB might weigh in on, if there is the energy to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
Re: multi homing pressure
At 12:20 -0400 10/19/05, Todd Vierling wrote: That's why SLAs exist. Do SLA's say if you are out of the water for 30 minutes we will also cover your lost business revenue? There are some times with service guarantees just are not enough (e.g., manned space flight support). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar True story: Only a routing expert would fly London-Minneapolis-Dallas-Minneapolis to get home from a conference. (Cities changed to protect his identity.)
Re: (What If?) ccTLD Delegation Question
http://www.iana.org/cctld/cctld-establishment-procedures-19mar03.htm At 16:28 -0500 10/3/05, Joe Johnson wrote: Call it Monday Boredom, if you will, but a funny DNS question just popped into my head: if I were to, say, win the lotto and buy my own Island (which, of course, would technically be its own country), would I be able to receive a ccTLD for said island nation? Kind of like .joejohnsonisland or .jji? If so, would the DNS have to be actually contained inside of said island? I think not, as it was mentioned earlier that .iq was run from Texas, but it's always good to ask. Joe Johnson [EMAIL PROTECTED] -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
off-list Re: Weird DNS issues for domains
;; ANSWER SECTION: sanderson.mtrsd.k12.ma.us. 604800 INNS dns-auth1.crocker.com. sanderson.mtrsd.k12.ma.us. 604800 INNS dns-auth2.crocker.com. ;; ADDITIONAL SECTION: dns-auth1.crocker.com. 151957 IN A 204.97.12.58 dns-auth2.crocker.com. 151957 IN A 204.97.12.57 ;; Query time: 119 msec ;; SERVER: 68.100.16.25#53(68.100.16.25) ;; WHEN: Thu Sep 29 11:36:31 2005 ;; MSG SIZE rcvd: 134 $ dig www.sanderson.mtrsd.k12.ma.us. a ; DiG 9.3.1 www.sanderson.mtrsd.k12.ma.us. a ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4869 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.sanderson.mtrsd.k12.ma.us. IN A ;; ANSWER SECTION: www.sanderson.mtrsd.k12.ma.us. 604800 IN CNAME www.mtrsd.k12.ma.us. www.mtrsd.k12.ma.us.604800 IN A 159.250.29.161 ;; AUTHORITY SECTION: mtrsd.k12.ma.us.604800 IN NS dns-auth1.crocker.com. mtrsd.k12.ma.us.604800 IN NS dns-auth2.crocker.com. ;; ADDITIONAL SECTION: dns-auth1.crocker.com. 151950 IN A 204.97.12.58 dns-auth2.crocker.com. 151950 IN A 204.97.12.57 ;; Query time: 58 msec ;; SERVER: 68.100.16.25#53(68.100.16.25) ;; WHEN: Thu Sep 29 11:36:38 2005 ;; MSG SIZE rcvd: 172 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: off-list Re: Weird DNS issues for domains
whoops...sorry for the extraneous data... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Why use ccTLDs?
At 20:42 -0700 9/27/05, Steve Gibbard wrote: some stuff Following on Steve's coattails, I'd like to put a plug in for the Swedish TLD (.SE) and applaud their introduction of DNSSEC: http://www.nic.se/english/nyheter/pr/2005-09-14?lang=en May we all benefit from their experience. PS - The RIPE NCC has also been introducing DNSSEC, but they aren't a ccTLD: http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00159.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Anyone seen 172.15/16 lately?
But that doesn't answer the question: (;)) NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName:IANA-BBLK-RESERVED That's the reserved range, he's looking for the /16 before that. Signed, A curious bystander who spent a few moments on this out of curiosity. At 11:11 -0700 9/28/05, Roy wrote: 172.16/12 is RFC1918 space Mark Boolootian wrote: Can anyone tell me to whom 172.15/16 is allocated? IANA says 172/8 May 93 Various Registries but checks with ARIN, RIPE, APNIC, AFRNIC, and LACNIC don't show anything. gr33tz to Team Furry!! mb --- Mark BoolootianUC Santa Cruz Dislaimer: Any operational content in this email is intentional -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
RE: Anyone seen 172.15/16 lately?
At 14:35 -0400 9/28/05, Hannigan, Martin wrote: Isn't 172.15/16 legacy Sun example space pre 1918? It's all over CCO and Sunsolve in examples and defaults. I poked some more and the LACNIC server says it is unallocated. That was the most straightforward answer of the bunch. It's an interesting exercise to see what the 5 RIRs return and what IANA doesn't. ;) ARIN - no records found APNIC - ' 172.0.0.0 is not allocated to APNIC' but lists CC of AU AFRINIC - '0/0', CC of EU LACNIC - unallocated RIPE - pretty much the same answer as AfriNIC IANA - doesn't query for numbers Didn't see a WhoIs box on the NRO site. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
RE: Anyone seen 172.15/16 lately?
At 21:10 +0200 9/28/05, Jeroen Massar wrote: Thus all nicely return Unknown, which is consistent. No argument about that, but they do say it in different ways. Hence a plug for the deployment of IRIS to tie the registry lookups together. IRIS - http://www.ietf.org/html.charters/crisp-charter.html, the IETF WG developing it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: SWIP and Rwhois in the Real World
NetRange: 4.0.0.0 - 4.255.255.255 ReferralServer: rwhois://rwhois.level3.net:4321 % telnet rwhois.level3.net 4321 Trying 209.244.1.179... telnet: connect to address 209.244.1.179: Operation timed out Doesn't seem to have made much difference yet... Their rwhois seems to be terminally down. Can we reclaim 4/8 from them now? Who is we? IANA says it belongs to BBN (ARIN not mentioned): http://www.iana.org/assignments/ipv4-address-space 004/8 Dec 92 Bolt Beranek and Newman Inc. (as opposed to) 073/8 Mar 05 ARIN(whois.arin.net) 074/8 Jun 05 ARIN(whois.arin.net) 075/8 Jun 05 ARIN(whois.arin.net) 076/8 Jun 05 ARIN(whois.arin.net) Either IANA's records are out of date or the space was granted prior to ARIN's start (in 97 or so). ARIN (via policies) has little say over this space. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
dotUS DNS problems on July 7
On July 7, 2005, NeuStar received a handful of reports that DNS resolvers were unable to resolve dotUS domains, plus the mention of the problem on the NANOG list. From the reports received, the DNS problem seemed to impact a limited number of independent organizations but was not widespread. The reports followed a maintenance operation at one DNS site. During the maintenance operation a new piece of network equipment was installed. At approximately 10pm EDT (July 8 0200 UTC) the state of a previously operating load balancer was reset. At that time affected servers at independent sites resumed resolving dotUS names. We have reviewed and revised our maintenance procedures to prevent a reoccurrence of this issue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: OMB: IPv6 by June 2008
At 10:57 -0400 7/6/05, Scott McGrath wrote: IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed. Sliding anything past the accountants is bad practice. Is the goal to run IPv6 or to run a communications medium to support society? If it costs $1M to adopt IPv6 in the next quarter, what would you take the $1M from? (I used to work at a science research center. Having a good network wasn't the goal, doing science was. Without good science, there would be no FY++ budget for a better network.) The Internet serves society, society owes nothing to the Internet. Members of this list may prioritize communications technology, other members of society may prioritize different interests and concerns. That is why IPv6 must offer a benefit greater than it's cost. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: OMB: IPv6 by June 2008
At 19:23 +0200 7/6/05, Iljitsch van Beijnum wrote: With the chicken little-ing again... You are approaching the problem at the wrong end by asking what's in it for me to adopt IPv6 now. The real question is is IPv6 inevitable in the long run. Pardon my skepticism, but I recall hearing about the coming of the world due to pollution in the 1970's and the end of the oil supply by the 1980's. (E.g., see http://www.ncpa.org/pub/bg/bg159/ for a discussion on the latter, albeit written before the most recent oil 'scare.') The point isn't whether IPv6 is good or not - it's that long-range predictions are often wrong. For every memex (http://www.iath.virginia.edu/elab/hfl0051.html) there's an oil crisis, Ada, GOSIP, economic default of New York City (Ford to City: Drop Dead! - NY Daily News, Oct 30, 1975)... So by all means, be an IPv6 hold out as long as you like, but don't assume that just because adopting IPv6 doesn't make economic sense for you now, it isn't going to happen at some point in the next decade. No rush, though. http://www.nanog.org/mtg-0405/augmentation.html Been there, done that, documented and shared results. (Yes, got the T-Shirt too. It was a NANOG, after all.) That wasn't even the first go-round I had with IPv6. My experiences were that IPv6 was painful - I ran into a lot of application bugs, OS's didn't deal with it well, and the ISP's were tough to deal with - as in, not many suppliers, not enough expertise to deliver on promises. Maybe things are better now (note the use of past tense in the previous paragraph), I don't deal with IPv6 at this time. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Enable BIND cache server to resolve chinese domain name?
At 9:39 +0800 7/4/05, Joe Shen wrote: Hi, Some of our customer complaint they could not visit back to their web site, which use chinese domain name. I google the net and found some one recommend to use public-root.com servers in hint file. I found domain name like xn--8pru44h.xn--55qx5d could not be resolved either. Our cache server runs BIND9.3.1 with root server list from rs.internic.net. Do I need to modify our cache server configuration to enable it? Yes. In order to get BIND to resolve a domain name under the xn--55qx5d. TLD, you have to configure BIND's root hints to point to root servers making that delegation. If you do this you won't be able to simultaneously use the rs.internic.net listed servers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: OMB: IPv6 by June 2008
At 11:30 -0400 6/30/05, Daniel Senie wrote: At 10:02 AM 6/30/2005, Fergie (Paul Ferguson) wrote: Just in case anyone was wondering, U.S. gummint agencies will be screaming in migration agony for the next couple of years. ;-) http://www.fcw.com/article89432-06-29-05-Web GOSIP II anybody? Will it be different this time than it was with OSI? Everyone had to scramble in the late 1980s to get OSI stuff done, then the gov't never used it. Having been in the US gov't (too) at the time of GOSIP, there were three reasons why I never used it much: 1) No budget was ever allocated to convert operations. (We had products, but we weren't forced, induced, encouraged to use it.) 2) The API for the GOSIP protocols was not standard - not only different from the API for TCP/IP, the API for GOSIP varied by platform. (POSIX had just begun.) 3) There was no tidbit of information available over the network that was on a server that spoke only GOSIP and not TCP/IP. (No compelling reason.) So, the questions are: will OMB fund the transfer of the US gov't sites? Will there ever be a US gov't web site only on IPv6? (I think the API issue has been solved.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: OMB: IPv6 by June 2008
At 21:29 -0400 6/30/05, Todd Underwood wrote: the rest of fred's comment stands with useful information but i'm still looking for the tipping point where people migrate, en-masse, away from the Internet to this new, incompatible network. You can color me skeptical on IPv6 - basing this on attending way too many PPT presentations on the subject and only limited hands on experience. But while I think the tipping point doesn't exist today, I bet it will sooner or later. IPv6 is not all that incompatible with IPv4 really, it's a lot closer than CLNP and UDP. It's not that IPv6 is chasing what IPv4 already offers. A lot of the improvements to IPv4 are thanks to IPv6. The fact remains that IPv6's expanded address range will be what makes it trump IPv4 eventually. It's not GOSIP all over again. But the USG's OMB statement may not be the panacea to the fans of IPv6. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: ATM
ATM is a great technology. indeed! i use them often. remember when you had to go into the bank and wait in a queue for a teller? When FIX-East was in College Park (Maryland), FIX-E was in an building NSI (as in NASA Science Internet) labelled the Maryland National Bank building. It appeared on all the network map slides. QA time - Why have you hooked up a bank building? Because of ATM What does that get you? It's how we get our funding from HQ. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Stanford Hack Exposes 10,000
Yes, that seems obvious, but it doesn't happen. Considering the sort of free wheeling environment prevalent in University networks, you would think they would be a bastion of high security. Sadly, this isn't the case. This isn't meant to be a bashing session on universities and other educational systems, just an observation. I would think, and I may be wrong, that a educational network would be subject to - stakeholders (students, faculty, alumni) that turn over quickly, calendar-tied fluctuations in activity, and a user base that tends to be more liberal and risk-tolerant than a typical end user network. I would think that these traits would work against the accumulation of tested operational techniques, appreciation of the time and cost of a reliable service, and stiff enough penalties for anti-cyber-social behavior. Also working against this is the availability of time (like between semesters) when major upgrades can be done, because in the rush to do so sound techniques can be over looked. I don't mean to cast dispersions on educational campus IT functions. There is a lot of good security research and energy available in those environment. I'm just saying the environment is harsher than for other end users. No - I'm not leading up to a suggestion to quarantine them from the rest of the Internet. Stories like this just serve as the example headlines of why any organization ought to take preventative measures when it comes to this kind of data. Hopefully, whatever vulnerabilities that were exploited will be patched, even if there is no public disclosure. (Word will get around when it needs to.) PS - I was more surprised by the case of identity data that was lost when a laptop was stolen. Why was something so valuable left in such a mobile form? http://informationweek.com/story/showArticle.jhtml?articleID=159907962 An example of following bad practices. Is the solution more consultants? ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
At 11:27 -0400 5/23/05, Larry J. Blunk wrote: I suspect this was due to the fact that template submissions were not fully automated at the time and required human review (disclaimer: I worked for the MichNet side of Merit back then and was not intimately familiar with PRDB operations). It could have been the tools. (I can't argue, I wasn't there.) Here's another thought. Much like the comparison of SSH and DNSSEC in this reply of mine from last March: http://www.merit.edu/mail.archives/nanog/2005-03/msg00694.html I.e., the mythical core needs work. This time it's the address organizations and routing elements. Yet another thought. Skimming through this thread, and only being slightly aware of sBGP and soBGP in past years, some concepts remind me of work under DARPA's Active Nets research done in the late 90's. (http://www.darpa.mil/ato/programs/activenetworks/actnet.htm) Some things I learned then: 1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood). 2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.) IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)? Dijkstra's shortest path algorithms (an example IGP) work in the plane because it manages to mimic the ubiquitous view. You aren't afraid that someone is not playing my the rules. When you are working with security (algorithms), you don't have that safety belt. And a final thought... Security ought to not make the system being protected brittle. Like the example of routing changes being held up until the paperwork went through - maybe an improvement in tools will enable this. But think of the long term impact - who will be paying to keep the tools and system up to date? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
At 10:37 -0700 5/23/05, william(at)elan.net wrote: You do need trusted third party to act as PKI root signer. We're lucky because unlike other places, we do have hierarchy with ip addresses and ASNs and NIR is the root organization. Don't confuse cryptography with security. You need one trusted third party to arrange for the cryptography to scale (work). You need a different third party to help authenticate (secure) the routing data. IMHO, you don't necessarily want these two third parties to be the same. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: soBGP deployment
At 14:00 -0400 5/23/05, Daniel Golding wrote: My reply is mostly tongue-in-cheek. I think it's always healthy to explore alternatives. Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof. I'll ignore that you said (or use a TXT record). ;) Without DNSSEC, what does this buy? Secure information on a non-secure channel. If, by stealing addresses you mean that the RIR records are changed, then changing the name servers is trivial - changing to servers that have the hijacker's preferred data (or none!). Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it. Who populates the DNS (well, the .arpa domain)? The RIRs do. Ok, please start flaming now :) Brave to make such a request on a Monday afternoon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Underscores in host names
At 8:04 -0700 5/19/05, Roger Marquis wrote: Laurent Frigault wrote: gethostbyaddr (and may be other functions) will return NULL under at least FreeBSD/NetBSD for ANY PTR having the _ character. As it should. I wish it would also return a null for hostnames containing sequential non-alphanumerics (--, ---, __, ___, ...). If null were returned for all host names containing -- then IDN names wouldn't work. (See RFC 3490, section 5.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Underscores in host names
At 12:01 -0300 5/19/05, MARLON BORBA wrote: Hmm, they've always teached to me that . (dot) at the end of hostnames indicates the (hidden) Root domain: blah.domain.com.[Root] And my teachers always said that we don't need to write the final . because every domain belongs to the Root domain. This thread needs to consider the layering of applications. E.g., Applications: Mail, Web, things using gethostbyname(host names, etc.) Infrastructure: DNS, etc, (such as X.500)(domain names) Apps deal with host names, DNS deals with domain names. To the DNS, host names are a subset of domain names. To applications, domain names per DNS are behind that interface. Apps deal with host names and other names, all of which, if running over DNS, are mapped into domain names. Referring to the above text, yes, a full qualified domain name ends in a dot. Whenever talking to or among DNS elements, the dot terminates the FQDN. It must syntactically - a zero length label is the null termination of the domain name. Applications passing domain names to the DNS (not strings of domain names) must have this terminating null. However, this does not mean that the applications have to make the user or GUI require the null, as that interface is likely to be dealing with a string version of the name. Some DNS applications, such as dig, don't require a dot at the end of the name - if one is missing, the dot is appended. The user is alleviated of the burden of adding the dot - but on the other hand - the dot is forced upon the user. Some applications, being agnostic, won't add anything to the user's input. (This is true for non-DNS applications too.) This gives the knowledgeable user more power - unique things can be done. But it means that novices have more to learn. Some applications assume the user is lazy and adds the dot in all instances. Knowledgeable users get burned because now here are two terminating dots at times - until these users remember to fall back to not terminating domain names. I've seen all three kinds of applications. The latter ones tend to be the quick and dirty prototypes that don't see the light of day. The moral is that applications are choosing when to add the terminating dot. It's always there in DNS, but people don't access the DNS without going through an application. As far as whether an _ is legal in a host name, you can attack the question in many ways. When cast into a domain name, _ is legal. DNS assigns no special meaning to that character in domain names. Not even in the SRV record - if one reads the document carefully, there is no special meaning assigned by DNS, only a convention proffered that uses the _. The convention is a function of the applications using the SRV, not the manipulation of the SRV within the DNS. When cast into a host name, _ is not among the legal characters specified in the ancient documents. But documents are just documents - arguing over what's legal according to them is about as useful as watching haircuts. (Unless you are on a software design implementation team.) When thrown into applications, _ may or may not have a special meaning. Some applications will raise exception to _. The more interesting question is why? Is this simply because of the ancient documents' restrictions? Is there some parsing consideration? Is there a special semantic inferred? It really isn't important whether the character is legal or not (until there is a network police force). What is more important is whether the character will work in all environments in which the name is needed. Will the _ work in DNS domain names? Yes, unless there is a but in the DNS implementation (always a caveat). Will the _ work in a host name? Only if the applications in use, referring to the host, can handle such a name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Underscores in host names
At 8:52 -0700 5/19/05, Roger Marquis wrote:
On Thu, 19 May 2005 [EMAIL PROTECTED] wrote:
...
Don't like RFC3490 and its xn-- hostnames? ;)
xn--... aren't host names, they are domain names. The host name
corresponding to that would be something my simple minded mail
application can't accept as input.
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with -, TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
There is real value in KIS, and not just from the perspective of a
security-minded coder...
KIS is great, if it gets the job done. Systems that are too simple
are useless too.
Supporting IDN is a necessary job. That's been made clear to the
Internet community. If it complicates things, well, then that's
what has to be done. If the Internet is to be global, it can't
restrict the world to just a few convenient languages.
It's true that the xn-- convention isn't the best way to encode
IDN's, but it has proven to be the optimal one in design (at least).
It would have been nice to use a new domain name label type, but
we've about run out of them. It would have been nice to use domain
classes and use this to create a new domain name syntax, but that
can't be done either. Encoding IDNs this way (xn--) is optimal
according to the considered opinion of the IETF, at least those
working on RFC 3490 (published in 2003), when you consider impacts on
other protocols and applications.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.
Re: Underscores in host names
At 17:53 -0400 5/19/05, Eric A. Hall wrote: Edward Lewis wrote: It's true that the xn-- convention isn't the best way to encode IDN's, but it has proven to be the optimal one in design (at least). It's the necessary minimum for compatibilty purposes, but not anywhere near the optimal design. Moreover, those have nothing to do with each other. Optimal is so subjective. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Schneier: ISPs should bear security burden
clean it up from pollutants [spam, ddos], add antibacterial [antivirus] agents, ;) My hotel confirmation for NANOG 34 was marked as spam. Thankfully, the ISP let it through anyway. It would be nice if the ISPs protected me from bad stuff on the Internet - but why are they to be held to a higher standard than similar services? E.g., (not intended as a water-tight analogy) the roads around me have laws and enforcement (sometimes). If I am hit by someone who breaks a rule, my insurance takes care of that. But the road system offers no protection to guarantee my on-time arrival at a Wednesday night beering session. (No over-provisioning there.) If we can't make it easy to get to happy hour, how are we going to make the Internet safe? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Problems with NS*.worldnic.com
At 21:34 -0700 4/25/05, Rodney Joffe wrote: The culprit is dig. Ahh, dig. What version? You have to be running the latest at all times these days...so many changes... In my experiences with v6 the problems I have come down two are: 1) Broken testing tools. (See change 1610 in the BIND CHANGES file for one.) 2) Broken route policy. (Dasterdly ISP's!) 3) Broken OS API's. (Have we learned nothing since or from Berkeley Sockets?) #1 - I've had to reevaluate everything I know about debugging since I met IPv6. Now there's an entirely alternate universe of failure to consider. One day I was sitting in RIPE NCC's offices and couldn't 'dig @ns.ripe.net'. So I walked to the ops room and asked, umm, is your big machine down. After a good laugh, we figured that my Mac was trying v6 where v6 wasn't *really* live. #2 - When I first got real live IPv6 service from a provider, I tried tracerouting to all the machines I knew about - the roots as listed on root-servers.org, the RIPE machines. I'd get about halfway there and fail. I asked for reverse traces from the other side and see failures about the same place. We had to work with ISPs to loosen route policies. #3 - I have seen all sorts of mistakes involving OS's, OS API's, and app software API's. Mapped addresses are mishandled, having more than one address to try is something apps don't deal with. (Like they've been force fed one kind of food their entire life, and now have to choose from a menu.) At NANOG last year I related my problems with ssh (choosing v6 over v4 - and me assigning the same domain name to two machines, one on a v4 net and one on a v6 net). Stupid me... The biggest problem was that one type of machine kept dropping its statically configured default v6 route. Packets would get in, but they didn't know where to go next. The machine logged all activity as good though...it didn't know. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: AUP for NANOG?
At 7:48 -0700 4/14/05, Matthew Black wrote: Do we have an Acceptable Usage Policy fot this NANOG mailing list? http://nanog.org/aup.html I suspect that the question above is rather rhetorical, nevertheless. Of late this forum has become a forum for ad hominem rather than a friendly discussion of technical issues. I agree. IMHO, I don't place much credibility in what I learn via this list. I wish I could. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: report of .biz outage...
At 10:03 -0400 4/4/05, Eric Brunner-Williams in Portland Maine wrote: The occasional connectivity problems with Neulevel of March 31st persist. I can assure you that our registration services have been up and running continually during the time period in question. In the spirit of diligent troubleshooting, I suggest that you consult with any intermediary parties that may be involved. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Telcordia report on ICANN .net RFP Evaluation
At 8:48 +0530 3/30/05, someone wrote: Telcordia ranking VRSN way ahead does seem to be raising some hackles here Telcordia did not rank VRSN way ahead of the rest. Being that I work for one of the bidding teams (Sentan), I merely want to point out that the above statement is untrue. Below are two quotes from the report that contradict way ahead. From the report's section 1.2 (Executive Summary of the Findings): The evaluators find that all of the vendors have the capability to run the .NET registry. and later in the section, VeriSign has a small numerical edge over Sentan that is not statistically significant given the methodology used to rate the RFP responses. I encourage concerned folks to draw opinions from reading the report itself, at least the executive summary. Here is the link to the ICANN page announcing the report: http://www.icann.org/announcements/announcement-28mar05.htm And the report itself: http://www.icann.org/tlds/dotnet-reassignment/net-rfp-finalreport-28mar05.pdf FYI, For discussions on the evaluation report, ICANN's web page says: ICANN Opens Public Comment Forum on .NET Evaluators' Report 29 March 2005 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
report of .biz outage...
Eric, Assuming that the first item of work email refers to mail today (March 31), or even in the past couple of days, I can say that we (NeuLevel) have had no outages, neither planned nor unplanned, of our SRS in that time. If you can give us some more information (off-line), we can look into whatever may have caused you to see such an email. I'm about to hit the road, so a response from me will be delayed. For a more immediate answer, contact our registry services help desk (support (at) neulevel.biz). Ed At 15:48 -0500 3/31/05, Eric Brunner-Williams in Portland Maine wrote: funny, the first item of work email i read today was this: the Neulevel SRS is currently down, .biz registrations are therefore not possible. We will inform you as soon as the registry is online again. your metric for match may vary. eric -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: DNS cache poisoning attacks -- are they real?
At 20:15 -0500 3/26/05, Sean Donelan wrote: effort. Why has SSH been so successful, and DNSSEC stumbled so badly? Short answer to that question alone. (Believe me, I've considered it too.) SSH is an example of innovation that requires only the end points to cooperate - e.g., like TCP doing congestion control at the edges. In particular, the key exchange in SSH is simplistic... DNSSEC is a change to the operations at the mythical core of the Internet. DNSSEC won't work until third parties are involved, i.e., the parents (et.al.) of the server are involved, not just the server and client. In particular, the key exchange in DNSSEC has been the sore spot. Mythical core: in this case, the administration of the root zone, the TLDs, etc., not the routing/transit/peering core. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
ARIN, was Re: 72/8 friendly reminder
At 15:17 + 3/24/05, [EMAIL PROTECTED] wrote: To begin with, nothing I have to say here has any bearing on the other IRR's. There is a reason there are 4-5 IRRs, each should be tuned to local sensibilities. However, ARIN today is a very dysfunctional organization. That is a very brash statement, one that is easily misinterpreted, one that may be simply wrong, or a statement that has an element of truth. The tone of this statement is why I am bothering to reply. First, distinguish between ARIN staff and ARIN membership. The staff at ARIN go to great lengths to respond to what the membership - and the public at large - ask ARIN to do. Note - NOT JUST membership. This is why there are open policy discussions, and open mics. (Sessions are webcast, the public policy mailing list is free to join.) Of course, membership does control the bounds of ARIN's response, including that of the staff, which is why there is also a member-only meeting on the last day of the conference. ARIN's staff is to fairly and equitably execute the policies that the membership organization has put into play. (I won't split hairs on the Advisory Council or the Board's roles, this can be learned by starting with ARIN's web site, http://www.arin.net.) This has two consequences. One is that it means the staff should not go and try to set the agenda for how ARIN operates. It it beneficial if the staff is involved to educate the members on the reality of running the registry. It the staff goes further, they are potentially disrupting an otherwise level playing field. The other consequence is that the membership takes on the responsibility for ARIN's actions. Not the staff's actions, but ARIN's actions. If there is any dysfunction in ARIN, I suspect that it lay here. I do not mean to infer that there is a problem, but I think this is where the largest misunderstanding of ARIN's role exists. I also do not demean the efforts of those who do take the time to participate, they are the ones heading in the right direction, no matter whether I agree with the opinions I hear. One question does haunt me about how the operations community views ARIN. Most ARIN policies are concerned with address allocation, reporting, and such. There are not many policies regarding the functional role ARIN plays in the Internet, the only one that leaps to mind is a lame delegation policy under discussion. The (haunting) question is whether the operations community feels that there should be operational policies put before ARIN. E.g., support for secure routing - when a concrete approach is defined that needs RIR input, should ARIN play? Is there a feeling within the operator community that ARIN is... Most ARIN members seem to view ARIN as a distant regulatory agency to whom they must regularly burn incense and make sacrifices in order for the ARIN gods to bestow IP addresses upon the unworthy network operator. The result is that there is little participation by ARIN members in monitoring and governing ARIN. And therefore, ARIN does what it has always done without changing or innovating. Oh, that's was where I was going. Is that the case? If so, then there is a dysfunction. I want to make it clear that any lack of change or innovation is not something that the staff has caused. (By design the staff is in reaction mode.) The lack of change or innovation is the motivation for the haunting question above. that ARIN carries a big stick like the FCC. The fault is not with the people involved in ARIN; the fault is with the majority of IP network operators who do not get involved with ARIN. I don't like fault, it implies that there is something seriously broken. For the most part, things are working fairly well. Maybe at the operator level we see ways the world would be much better if we ruled things, but to the general public, the Internet is making things better. (Maybe for just some, but you have to admit overall things are better.) But, the point is taken that ARIN would be much more useful to the Internet if there was a change in participation. However, the improvement is not in the demographics of the participation, but in the content of the participation. If the content of the participation was well-balanced, then the demographics will follow. After all, if the policies ARIN membership were perfect now and into the future, there's no longer a need for the membership to steer the staff. The only thing the staff would have to do is execute the (benevolent, perfect) bureaucracy. ;) PS - I think my response to Michael is not so much an opposing view, but a slightly different emphasis in where improvements may lie. I really don't think Michael is trying to stick it to the staff. (I hope he's not.) But a lot of times people confuse the ARIN staff with the ARIN membership organization. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis
Re: ARIN, was Re: 72/8 friendly reminder
At 17:01 + 3/24/05, Andrew Dul wrote: I agree, I'd certainly like to see more people actively participate in the process. If nanog folks believe that the ARIN membership is not getting the right stuff done... How do we fix this problem? How do we get more operators involved and active in the RIRs? In the spirit of cart and horse, it's not about getting more operators involved in ARIN. It's about getting operators to use ARIN as a resource in the proper way. (I'm addressing operators here as this is NANOG.) What do operators expect from ARIN? Most ARIN policies are centered on the administrative function of allocation of address space and AS numbers. Is that all there is? Are the existing policies all that are needed? Are there concerns about the live-in-the-network registry services like WhoIs, DNS, IRIS, routing registry? There are not many policy proposals (lame delegations, privacy concerns with WhoIs) in play covering operational considerations. ARIN staff has begun work on documenting the registry service level agreements, there was a presentation on this in October. There has been little discussion on this by anyone since the presentation. If WhoIs is out, reports fly on NANOG. But has anyone ever tried to quantify what level of service is expected of ARIN's computing facilities? If the staff is doing a good thing by documenting SLA's, then they should be encouraged to continue. There is routing security research work that would require the RIR's to issue certificates for use in route update validation. I would hope that someday, before anything goes live, there are operator-led tests involving support from ARIN. I think colocating 1 ARIN meeting/per year with Nanog in the fall has been a help. I would caution that attending meetings is neither a sign of contribution nor a sign of progress. Don't get me wrong, making meetings easier to attend is good, but we shouldn't attend meetings because it is easy, fun or entertaining. I prefer to have fun at home. ARIN isn't perfect but it could be a lot worse. In some ways I think the issue you describe is an industry wide problem. There are many different groups (RIRs, ICANN, IETF, Nanogs, etc...) and participating in all of them is a lot of effort, especially when most of us already have full-time jobs. Participating in all of them *is* a full-time job. ;) We could of course create a huge beuarcratcy with lots of people to study the issues and make policy, but that hasn't been the way the Internet has developed and is counter to what many operators think is best for the Internet. That also requires money. Is that what people want? I don't think so, but I could be wrong. One the one hand, what built the Internet isn't what will maintain it. A bureaucracy will be needed, the challenge isn't to prevent it but to build the best one possible. If ARIN goes unchecked it'll either be a weakened organization unable to serve the community (chaos ensues) or it will become an ogre, burdening the community (suffocation). It benefits operators to be involved, but the real trick is to realize what kind of involvement is needed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: ARIN, was Re: 72/8 friendly reminder
At 12:53 -0800 3/24/05, Owen DeLong wrote: NO. Operational specifications and routing are the domain of the IETF and _NOT_ ARIN. ARIN is responsible for the stewardship of assigned numbers within the ARIN region. This includes IP addresses, Autonomous System Numbers, and, DNS delegations for reverses on IP addresses. While ARIN should consider routing issues and the operational impact of ARIN stewardship policies, and, ARIN also has an educational role in helping the community to understand BCP including operational BCP as it relates to IP Addresses, ASNs, and DNS, ARIN has no role in dictating or driving operational practices. My question is not related to specification development but operational requirements of ARIN itself providing a service based on specifications. E.g., picking something a bit more concrete that secure routing, should ARIN deploy DNSSEC support, once it is published (again), in 6 months? 12 months? 10 years? This will tell the staff what level of staffing is needed to accomplish the work. The policy discussion will let membership know whether it is willing to pay for this. (Open to the public or not, the membership determines what it pays.) Discretionary funding for supporting research within the IETF should exist too, to cover participation in development of specifications at an appropriate level of effort. Let's say DNSSEC is ready for deployment. Does the impetus come from the ARIN staff or from the membership? (Maybe it comes from outside, but does it need to be made into a policy before the staff implements it?) I'm not sure ARIN has a change or innovation role. It is not unlikely that responsible stewardship includes a minimum of change and a preservation of stability and consistency. ARIN has two definite roles when it comes to innovation. 1) Don't get in the way of innovation by the community and 2) provide expert advice when it comes to the development of specifications related to RIR functions. And ARIN ought to be wary of trends in the improvement of its internal operations. An example of role number 1 is providing DNS services over IPv6 transport. An example of role number 2 is contributing to the discussion of the IRIS definitions for address registries. In neither case is ARIN leading the charge, but is playing a part in innovation. To come back to secure routing, the reason ARIN would be involved is that ARIN would be asked to publish information on who is allocated number resources. Although this is done in WhoIs now, there is a need to do this via whatever format is required by secure routing. I'm sure the specification of secure routing will describe how to operate the protocol, but not address the server capacity nor topology needed. Perhaps policies aren't the vehicle, but then how does the operational community get ARIN to supply services? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: ARIN, was Re: 72/8 friendly reminder
At 13:01 -0800 3/24/05, Owen DeLong wrote: There are not many such proposals in play at the moment because the ARIN community reached consensus around most of these issues over the last two years. There seems to be general agreement that the current state of things is acceptable in terms of Whois and DNS. While ARIN runs a Routing Registry as part of it's public service focus, I do not believe that ARIN should have a defining role in the IRR process. In general, that also is the purview of the IETF. Here's my dilemma. On the one hand I hear calls for greater operational input to ARIN. On the other hand is empirical evidence that there isn't much input being given. What I have been trying to do extract what latent operational input might be fed to ARIN, judging from discussions I have seen at other RIRs, the IETF, etc. If there aren't follow ups to these ideas, then I would conclude that ARIN isn't dysfunctional and is operating as it should be, an idea supported by what is above. If there are ideas forthcoming, then maybe there is a need to encourage participation. This thread was ignited by the desire to have a pingable address in newly allocated blocks (from IANA to ARIN), and maybe Randy's suggestion is all that is needed - simply asking ARIN to do this. Maybe policies aren't the only way to influence ARIN's operation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Delegating /24's from a /19
At 23:54 -0800 3/16/05, Owen DeLong wrote: Ed's comments: If that were true, then, there would be no such thing as recursive resolvers and all clients would have to have recursive libraries. If I ask a recursive resolver for a foreign A record, I usually get an A record in response. If I ask a non-recursive server, I usually get NS records in response. I was going to respond with a really long tutorial on reading DNS responses, but I figure this is not the forum. In short, yes, the responses are as you say, but to really understand this you have to dig deeper into the protocol details to see the difference between a referral and an answer. Perhaps, but, as long as the referrals consistently point to an end and not a loop, in general, it seems to work. In the IPv4 reverse space, you only have the following zones... root, arpa, in-addr.arpa, /8, maybe the /16, and /24 In operations, four or five referral possibilities, tops. DNAME and CNAME kind of change this, but they aren't referrals in the DNS dictionary, they rewrite the query. In theory, DNS referrals only loop if the there is a break in the protocol. DNS is a tree, which means there's only one path between any two points. If you turn the tree into a bush, you've broken it. 1) Send a reassign-detailed or reallocate template (in ARIN lingo) for the space to the RIR. Then the next set of DNS zone files generated will delegate to the customer's name servers. Obviously, in most circumstances, I'd agree that this is preferred. If that's the case, I don't know why this thread is being continued. I responded under the presumption you were about to propose some other way to do this. From your earlier message you mentioned sideways delegations and this is what is proposed. Before proposing a change to DNS, the details of the protocol have to be clearly understood. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Delegating /24's from a /19
work just fine. Nothing really to debug. I think the above two paragraphs are on the same side of the page. Delegation is the DNS is strictly hierachical. I don't see where the above breaks this. It's the incoherency in your example that is the breakage. You either SWIP the new servers or you slave the zones from the customer. In both cases you are following the delegation heirarchy. Note even if you slave the zones you still have to ensure the delegation is correct. I guess we will have to agree to disagree on this. I will point out that the above solution is working in a number of networks without problem. Sure, if you screw it up, it doesn't work. That's true of DNS generally. If the delegation from the /8 zone is to the /24 level (as opposed to the /16 level) there are three options for an ISP to transfer the delegation to the customer. 1) Send a reassign-detailed or reallocate template (in ARIN lingo) for the space to the RIR. Then the next set of DNS zone files generated will delegate to the customer's name servers. 2) Use DNAME, RFC 2672. Good luck. (http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html) 3) Use RFC 2317. I encourage my competitors to operate this way. 'Course, the ISP is free to have the customer just update the ISP's name servers, whether by dynamic update or be zone transfers from hidden masters. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Delegating /24's from a /19
At 13:48 -0800 3/16/05, David Raistrick wrote: On Wed, 16 Mar 2005, Edward Lewis wrote: aside) to uphold. In the global DNS, no matter where you ask question, you should get the same answer. Really? Yes. dig @ns1.arin.net 124.16.172.in-addr.arpa. IN NS and dig @ns1.foobar.com 124.16.172.in-addr.apra. IN NS had better return the same NS RRSet. An example modeled after the above using real servers: dig 48.173.209.in-addr.arpa ns @a.root-servers.net ;; AUTHORITY SECTION: 209.in-addr.arpa. 1D IN NSchia.ARIN.NET. 209.in-addr.arpa. 1D IN NSdill.ARIN.NET. 209.in-addr.arpa. 1D IN NSBASIL.ARIN.NET. 209.in-addr.arpa. 1D IN NShenna.ARIN.NET. 209.in-addr.arpa. 1D IN NSindigo.ARIN.NET. 209.in-addr.arpa. 1D IN NSepazote.ARIN.NET. 209.in-addr.arpa. 1D IN NSfigwort.ARIN.NET. dig 48.173.209.in-addr.arpa ns @chia.ARIN.NET ;; AUTHORITY SECTION: 48.173.209.in-addr.arpa. 1D IN NS oak.neustar.com. 48.173.209.in-addr.arpa. 1D IN NS pine.neustar.com. 48.173.209.in-addr.arpa. 1D IN NS willow.neustar.com. 48.173.209.in-addr.arpa. 1D IN NS cypress.neustar.com. And that is correct. Both are referring you to another zone. The set of servers in the first belong to 209/8, the latter to 209.173.48/8. What is not apparent is that neither query is resulting in an answer. Instead, the reply is a go ask someone else referral. It's like Joe says ask Bob and Bob says ask Charlie. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Delegating /24's from a /19
At 16:56 -0500 3/16/05, Edward Lewis wrote: servers in the first belong to 209/8, the latter to 209.173.48/8. Whoops - the last is /24. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss.
Re: Registrar and registry backend processes.
At 10:32 AM +0100 1/21/05, Stephane Bortzmeyer wrote: Remember that the whois protocol is a mess. May be IRIS will fix that. For those concerned with IRIS, please take time to review the documents listed at the bottom of this page: http://www.ietf.org/html.charters/crisp-charter.html RFCs 3981, 3982, 3983 represent the review of the entire IETF (tacitly by most). Although these are permanent documents, it is never too late to read and comment on them. Revisions happen. The document for the RIR's (ARIN, et.al.) hasn't completed its review, it can be seen at: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-09.txt and there's a related draft at: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-urires-00.txt It's never too late to comment on a protocol, although it maybe too late to comment on a document. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar A noble spirit embiggens the smallest man. - Jebediah Springfield
Re: [registrars] Re: panix.com hijacked
At 13:54 -0500 1/17/05, Joe Abley wrote: So the TTLs of records in the registry-operated zones will likely have no impact on how long NS records for delegated zones remain in caches. If panix (or anybody else) wants to increase the time that their NS records stay in caches, the way to do it is to increase the TTLs on the authoritative NS records in their own zones. For panix.com, these appear to be set to 72 hours (the non-authoritative NS records for PANIX.COM in the COM zone have 48-hour TTLs). That's provided that the panix.com authoritative NS's are seen in the cache. Not all name servers return the authoritative NS's in an answer. (BIND has an option 'minimal-responses yes_or_no;' that control this. The default is no, but I know of one yes user.) The registrant's copy of the NS set is more credible (RFC 2181 speak) than the registry's copy, so if a cache sees both, the cache tosses the registry copy. But there's no guarantee that the cache will see both. Usually it does though. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar A noble spirit embiggens the smallest man. - Jebediah Springfield
RE: [WAY OT]: concern over public peering points...
-Original Message- Which almost begs the question - what's the oddest WTF?? anybody's willing to admit finding under a raised floor, or up in a ceiling or cable chase or similar location? (Feel free to change names to protect the guilty if need be:) In a job long ago, at a gov't facility that was non-military yet had a secret building...probably in 1993 give or take a year... There was a lone Macintosh computer (not even a workstation) in an unsecured room of a secured building plugged into a small hub that was FOIRL'd (10BaseFL) out of the building, along an atrium, into the neighboring unsecured building. In a nondescript office of the unsecured building, the FOIRL was connected to Thinnet. The Thinnet snaked around the office, behind desks, etc., to a small 10BaseT hub which went into the wall (as Cat V). At the other end was a Cabletron hub I was managing for the Campus-wide Network. FOIRL was used because, being fiber and not EMF radiating copper, it was secure enough for the secured building. At least according to the facility security officer. I suppose that the thinnet was used because they couldn't find a FOIRL to 10BaseT repeater. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer I can't go to Miami. I'm expecting calls from telemarketers. - Grandpa Simpson.
Re: IPv6 reverse lookup - lame delegation?
Having been present at the meeting that gave rise to the document (at the IETF meetings held in London, August 2001), I'd say that the material quoted in the document is at fault. (There was quite a lot of controversy at the meeting, perhaps my recollection isn't shared with all others. But this is my story and I'm sticking to it.) The changes in status of bit labels, the A6, and DNAME were discussed in the context of DNS's support of IPv6. At the time the main debate was whether or not DNS records ought to be defined to support renumbering (among other features, but renumbering was the star). A6 and bit sting labels (forward and reverse) proved to be too much for the DNS to handle, the new thought was that such functionality ought to be pulled out of DNS and into tools the pre-processed zone definitions. E.g., something that generated records from a database, etc. DNAME was kind of the third record in. The change in it's status pertained to the role it played in supporting bit sting labels - which is why the reverse tree is mentioned in the deprecation. Looking at the document now, the document ought to have read the use of DNAME RRs in the support of bit string labels is deprecated - based on my memory. PS - Note that DNAMEs are defined in RFC 2672, not in 2874. If you want to get all IETF document lawyerish about it (;)), the quoted material is referencing a discussion of DNAME in the context of supporting renumbering, not the definition DNAME itself. RFC 2672: Non-Terminal DNS Name Redirection RFC 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering At 14:45 +0200 2/11/04, Pekka Savola wrote: On Wed, 11 Feb 2004, Mark Andrews wrote: RFC 3363 does NOT say that DNAME is deprecated. All it says is that since A6 was moving the exprimental using DNAME to support renumbering is deprecated. Which part of: Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. do you difficulties in parsing? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer History repeats, therefore my life is a rerun.
Re: Lazy Engineers and Viable Excuses
At 19:08 -0400 8/25/03, Haesu wrote: Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone. But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available. (Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: Microsoft to ship new versions with firewall enabled
[Veering further off-topic] Hmm...I didn't even know XP had a built-in firewall. Any bets on how long it is before other companies with software firewall products bring suit against Microsoft for bundling a firewall in the OS? Along the vein of I dislike Microsoft, but let's get over it - when some Linux started out with, what, ipchains/ip-something to protect it from network vulnerabilities, it took our little lab's folks some time to remember to punch holes in it for DNS, SSH, etc. each time we set a new one up. Ah, live and learn. The legacy of shipping machines open to attack predates Microsoft, it isn't their fault(tm). This issue was raised in at least as far back as The Cuckoo's Egg (since I've met folks that don't remember it, by Clifford Stoll - very entertaining tale of an astronomer-turned-SA tracking a hacker). In the epilogue, he mentions the Morris worm, so we're talking about incidents in '87 or so. (The Morris thing was what, Nov 2, 1988? Give or take a week.) I highly recommend that book as part suspense novel and part security tutorial. Every time a vendor/open-sourcer decides to stop shipping with security down, there's a learning curve forced on the buyers. But that's why we get paid to work in air conditioned offices in the summer. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: ISPs are asked to block yet another port
At 2:58 -0400 6/23/03, Jeff Kell wrote: And as was noted earlier, unconditionally blocking udp/1026 will cause a lot of collateral damage when udp/1026 outbound is used as an ephemeral port for a legitimate UDP-based service (DNS, NTP, etc). Jeff It's been a long time since I did any substantial BSD-socket coding, but, back in the day, when you asked for socket 0 in a bind call, the OS would just pick one. The first (unused) one chosen would be 1024, then incrementally pick the next up to some limit where it would then circle around. Most clients (incl. DNS resolvers) would ask for port 0, so, well, y'all can predict the result if you were to filter any of the user space ports. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop...
Re: COM/NET informational message
At 18:31 + 1/3/03, E.B. Dreger wrote: UTF-8 is a standard. MS products have used two-octet chars to support Unicode for a long time. Any reason to add yet another encoding? Sounds like a question to ask of the IETF. How about encouraging widespread adoption of EXISTING standards instead of adding more cruft? UTF-8 is standard. Proper DNS implementations are eight-bit safe. People upgraded browsers due to SSL, Year 2000, Javascript... The DNS protocol is not 8-bit safe, much less any implementations of it. This is because ASCII upper case characters are down cased in comparisons. I.e., the following are equivalent label values in DNS: ABCDEF and abcdef and AbCdEf. Each has distinct binary encodings, but DNS comparisons treat them as equal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: COM/NET informational message
At 12:26 -0800 1/3/03, just me wrote: Am I the only one that finds this perversion of the DNS protocol abhorrent and scary? This is straight up hijacking. It's scary but I'm not sure it's abhorrent. The DNS is hit by a lot of bad traffic. E.g., a presentation at the previous nanog (http://www.nanog.org/mtg-0210/wessels.html) mentioned that just about 2% of traffic at the roots is healthy traffic. Over the years, there have been servers for 10.in-addr.arpa just to suck up queries that should have never leaked out the source networks. It's encouraging that there is an effort to try to clean up the reasons for bad traffic. It's scary because in some sense the response is not true (I wouldn't call it hijacking), but when you are trying to cull out incompatible older editions of software, there's no safe route (no 'fail safe' method). And yes, the approach mentioned is optimized for DNS resolution for web access. Hopefully this doesn't trap, for example, unwary SSH connections. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: COM/NET informational message
At 17:15 -0500 1/3/03, Daniel Senie wrote: It's so nice Verisign is pushing a solution for COM/NET. I have to wonder if we'll have a different solution in .ORG, another in .BIZ, etc. Folks, this is why we cooperate with competitors and produce standards. Well, the way I look at this is: I hope it's temporary (for everyone's sake) and perhaps most of the problem cases will be in web look ups for names under com and net, so maybe this will knock a lot of the problem cases out. Hopefully. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: Next NANOG meeting/stats
At 16:46 -0500 11/19/02, Randy Bush wrote: and the World Series is a game played only by amercian teams. and if you don't like it, shut up or we'll bomb you. The Toronto (Ontario) Blue Jays won the series in 1992 and 1993. 'Course, in one of the games in Philadelphia, someone raised the Canadian flag upside down at the start of a game. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: How to secure the Internet in three easy steps
At 13:14 -0400 10/25/02, Sean Donelan wrote: Are there some down-sides? Sure. But who really needs the end-to-end principle or uncontrolled innovation. The context of the above is, of course, sarcastic. But it reminded me of a quote that once appeared on mailing list that is germane to this. The quote was uttered in 1824 or so, by the inventor of the telegraph. The quote lamented that the funding needed to deploy an innovative concept was held by the folks that were the most threatened by innovation - i.e., they made money with out the latest new fangled thing so whatever the new fangled thing did, it was sure to be a threat to their current income stream. Does anyone know this quote? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Re: Fwd: IETF Call for Nominations
At 19:52 -0400 10/21/02, RJ Atkinson wrote: Operators who are involved in IETF should consider providing input (good/bad/other) to the IETF Nomcom -- since that is the best way to affect the future makeup of the IESG and IAB. Details below. For those who want to give verbal input, at least one IETF Nomcom member (i.e., me) will be attending NANOG and the following ARIN meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
