RE: OpenTransit (france telecom) depeers cogent
All, Here is an output of show ip bgp regexp _5511_ on my cogent facing router (ie with a full cogent feed)...Most of the prefixes with best paths that are not through cogent don't exist in my cogent route feed at all (even via a non FT path). It looks like things are still a bit wonky. http://as23265.net/cogent.txt Thanks, John van Oppen PocketiNet Communications AS23265 -Ursprüngliche Nachricht- Von: Patrick W. Gilmore [mailto:[EMAIL PROTECTED] Gesendet: Sunday, April 17, 2005 10:26 PM An: nanog@merit.edu Cc: Patrick W. Gilmore Betreff: Re: OpenTransit (france telecom) depeers cogent On Apr 17, 2005, at 11:16 PM, Patrick W. Gilmore wrote: On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: As a cogent customer, I still see no routes to 217.167.0.0/16 (the route that holds www.francetelecom.com) via my cogent feed. That /16 also appears to be unreachable from the looking glass on cogent's website still. I can trace from Cogent to FT just fine. Haven't checked all possible end points, but my spot check shows connectivity. Replying to my own post, I still see some Cogent - FT strangeness. Tracing to www.opentransit.net works fine, but www.fracetelecom.com dies on the first hop. Spot checking other IPs in FT, they seem to work. Is it just the 'fracetelecom.com' sub-network that is still not connected? Anyone have any more info? -- TTFN, patrick
Re: Memory leak cause of Comcast DNS problems
Hi, On Apr 17, 2005, at 8:20 PM, Eric A. Hall wrote: | The maximum amount of memory to use for the server's cache, in | bytes. [...] The default is unlimited, meaning that records are | purged from the cache only when their TTLs expire. That was my first guess too. Most DNS servers don't even have this switch. Actually, I suspect most servers now do, at least in the context of Internet service provision. I believe BINDv9 + dnscache + CNS (don't know about maradns, powerdns, or posadis but I believe their relative percentage isn't significant) outnumber BINDv4 and BINDv8. Don't know if Microsoft DNS allows you to limit memory consumption, but I don't think it is used in an ISP context that frequently (although I might be wrong). Rgds, -drc
Re: OpenTransit (france telecom) depeers cogent
John van Oppen wrote: All, Here is an output of show ip bgp regexp _5511_ on my cogent facing router (ie with a full cogent feed)...Most of the prefixes with best paths that are not through cogent don't exist in my cogent route feed at all (even via a non FT path). It looks like things are still a bit wonky. http://as23265.net/cogent.txt Thanks, John van Oppen PocketiNet Communications AS23265 -Ursprüngliche Nachricht- Von: Patrick W. Gilmore [mailto:[EMAIL PROTECTED] Gesendet: Sunday, April 17, 2005 10:26 PM An: nanog@merit.edu Cc: Patrick W. Gilmore Betreff: Re: OpenTransit (france telecom) depeers cogent On Apr 17, 2005, at 11:16 PM, Patrick W. Gilmore wrote: On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: As a cogent customer, I still see no routes to 217.167.0.0/16 (the route that holds www.francetelecom.com) via my cogent feed. That /16 also appears to be unreachable from the looking glass on cogent's website still. I can trace from Cogent to FT just fine. Haven't checked all possible end points, but my spot check shows connectivity. Replying to my own post, I still see some Cogent - FT strangeness. Tracing to www.opentransit.net works fine, but www.fracetelecom.com dies on the first hop. Spot checking other IPs in FT, they seem to work. Is it just the 'fracetelecom.com' sub-network that is still not connected? Anyone have any more info? I am seeing wonkiness too. I have a default-free router peering exclusively with AS174 that's not seeing routes for hosts in rain.fr and francetelecom.com, and traces to those hosts die two hops into AS174. The same hosts are reachable via level3 and their traces go through on our routers that have multiple peerings. Note that the authoritative nameservers for francetelecom.com are in rain.fr and are not reachable via an exclusive cogent path. Hence, I am not able to even get DNS resolution on the cogent-only path. michael
IX Panel for Seattle
Good Morning Nanog! I am looking for IX Operators of small to medium size, or that of regional scope of interest, or perhaps a naps offering unusual services to present at NANOG-SEA. After Las Vegas, I'm looking for a change of direction to get some new blood in. Smaller, perhaps member based, or not. Please email me with your interest. I need emails in the next 3-5 days with slides 3-5 days after. Thanks! Chris Malayter TDS Telecom - Network Services Data Network Engineering [EMAIL PROTECTED] Phone: (608) 664-4878 FAX:(608) 664-4644
Re: OpenTransit (france telecom) depeers cogent
For many folks too the falling price they buy transit for just meansthey are being forced to take that off their product sell prices so they dontactually make any more profit.. in which case there is no advantage to buying below cost services. In recent years, the unregulated telecoms industry has struggled with the steep slide towards commoditization. This is a problem because the industry's definition of telecom services is so narrow that there are few opportunities to add value and outrun the commoditization wave. Moving packets from point A to point B is rapidly becoming as glamourous and as profitable as moving water from point A to point B or moving gas, or moving electricity... The only way out is for the telecoms industry to be dismantled by 3rd parties who will buy and own networks in order to leverage those networks for their own value-add services. Everyone else will just have to get used to repeated cost-cutting exercises. --Michael Dillon
RE: OpenTransit (france telecom) depeers cogent
They are alive! host_name(217.167.29.246,www.francetelecom.com). No ping, no traceroute, but I get their homepage. host_name(84.167.240.52,p54A7F034.dip.t-dialin.net). That is me. 217.0.67.105 (217.0.67.105) 9.237 ms 9.128 ms 9.335 ms da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 8.362 ms 8.445 ms 9.784 ms That is my way out. In europe there seem to be no problems. I have not seen anything in forums here. From http://vision.opentransit.net/docs/peering_policy/ If you meet the criteria defined above, please send your formal peering application by email to peering5511 at opentransit.net ([EMAIL PROTECTED] has been discontinued) I guess they have another mailbox in qa. Regards, Peter Dambier -- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +49-6252-750308 (Sipgate VoIP) [EMAIL PROTECTED] www.peter-dambier.de peter-dambier.site.voila.fr
Re: Anyone familiar with the SBC product lingo?
On the contrary, you get better redundancy by sticking to one carrier and making sure that they really provide separacy though the entire span of the circuit. If you have two carriers running fibre to yoiur building down the same conduit, then you do NOT have separacy and as a result, the redundancy is not there. The problem with this theory is that one carrier is completely free to reroute your connectivity among its resources. One carrier can only do what your contract allows them to do. And negotiating a contract with strong requirements for separacy is easier with one carrier than two. Note that many carriers, though perhaps not the LECs, will answer questions about the underlying resources they are using if they are sufficiently motivated, but you have to reask every now and again to make sure that the answers are still satisfactory. Agreed. --Michael Dillon
Re: Service providers that NAT their whole network?
A lot of european mobile providers do this, as they're evolving from addressing their own network and GPRS into 3G and proper internet access, if you will. Internet [EMAIL PROTECTED]@merit.edu - 15/04/2005 20:43 Sent by:[EMAIL PROTECTED] To:nanog cc: Subject:Re: Service providers that NAT their whole network? On Fri, Apr 15, 2005 at 03:39:56PM -0400, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). Can anyone give me some names of providers that do this? Rose.net, the municipal provider in Thomasville GA. They'll assign you a fixed public address which can be gotten back through if you ask, for extra money, but your interface address will still be in 1918 space. Cheers, -- jra -- Jay R. Ashworth [EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ** BNP Paribas Private Bank London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.
DSCP ECN bits
Hi, Is anyone using the DSCP ECN bits to any great extent? Does it require end-host support in the stack to actually work? Cheers, Christian This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ** BNP Paribas Private Bank London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.
Security Concerns Boosted VeriSign's Dot-Net Bid
Interesting article in the Wasington Post this morning (link is via Yahoo! News, which doesn't require registration): Security Concerns Boosted VeriSign's Dot-Net Bid http://story.news.yahoo.com/news?tmpl=storycid=1804ncid=1804e=2u=/washpost/20050418/tc_washpost/a62302_2005apr18 - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Security Concerns Boosted VeriSign's Dot-Net Bid
On Monday April 18 2005 07:21, Fergie (Paul Ferguson) wrote: Interesting article in the Wasington Post this morning (link is via Yahoo! News, which doesn't require registration): Security Concerns Boosted VeriSign's Dot-Net Bid http://story.news.yahoo.com/news?tmpl=storycid=1804ncid=1804e=2u=/washpost/20050418/tc_washpost/a62302_2005apr18 Just proves its the one that can suck better that wins. -- Scott Grayban Security/Abuse Engineer FCT Enterprises -- www.fctsupport.com
Re: cost of doing business
On Mon, 18 Apr 2005, Joe Abley wrote: On 17 Apr 2005, at 13:54, Andrew Odlyzko wrote: We are talking of two different things here, traffic versus access bandwidth. It will be a while before the average household generates 5 megabit/s traffic. I don't think that's true. I have seen bittorrent clients running on machines that have good connectivity (typical North American residential; say 100M access to a data centre on the east coast). With only moderately-popular torrents (think fan movies like fanimatrix or starship exeter, a week or so after the slashdot effect has died down) such a client can easily seed at 10-20Mbit/s. Yes yes, it's of course technically possible. It's no problem to saturate a 100M either if you have a decent computer. Still, if you take 10.000 random consumers with 10M/10M pipes you'll see that this population as a whole only has an average peak of a few hundred kilobits/s per user. A few percent will do 5-10M sustained a lot of the time, but a lot of them will be totally quiet most of the time. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Apr 18, 2005, at 11:45 AM, Jay R. Ashworth wrote: Here we go again... http://techrepublic.com.com/5100-10595-5657417.html?tag=nl.e044 My initial reaction is why? My followup reaction is Well, most workstations don't cache anyway, do they? Depends on what you call caching. Does honoring a TTL qualify as caching? Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query? -- TTFN, patrick
Re: Memory leak cause of Comcast DNS problems
A friend in St. Paul left me a comment: Irritated Comcast customer from St. Paul here. I'm just glad I didn't wait until Friday to e-file my taxes. Eric
Re: N+? redundancy
Not necessarily. The number of paths in a city often has little to do with the providers and how many paths they would like offer, or at least did when they had the money to build. Many times the contraint is not demand but the zoning laws on where paths can be laid. Even if a client demanded and was willing to pay for the diverse paths there can be none available. Thus some times providers simply don't tell what the physical pathways are because they can be no different than the ones the prospective client is already using. Quite simply it is not a problem that the market can solve on its own because the market does not completely own the problem, state and municiple authorities also have a large piece of the game. The number of paths varies widely between cities, and has little to do with demand in those cities for diversity or how critical they might be to the nation as a whole. - Original Message - From: [EMAIL PROTECTED] Date: Saturday, April 16, 2005 2:00 pm Subject: N+? redundancy [EMAIL PROTECTED] writes: In my opinion, the following rule of thumb is reasonable. 1 path is enough for a site/enterprise that shuts down its services evenings and weekends. 2 paths is enough for a site/enterprise that provides a 24 hour, 7 day per week service. 3 paths is enough for a population center with under a million inhabitants. 5 paths is enough for a population center with over a million inhabitants. And a very few population centers such as New York, London, Tokyo, and Cheyenne Mountain should probably have more than 5 paths. Given that anything larger than a single enterprise has no central coordinating body, how is it useful to say how many paths is enough for a city of any size? Service providers will build as many paths as make commercial sense, whatever that may be, and if customers have opinions and are willing to back it up with money, they should express those opinions to their providers.
Re: cost of doing business
On 18 Apr 2005, at 11:33, Mikael Abrahamsson wrote: On Mon, 18 Apr 2005, Joe Abley wrote: I don't think that's true. I have seen bittorrent clients running on machines that have good connectivity (typical North American residential; say 100M access to a data centre on the east coast). With only moderately-popular torrents (think fan movies like fanimatrix or starship exeter, a week or so after the slashdot effect has died down) such a client can easily seed at 10-20Mbit/s. Yes yes, it's of course technically possible. It's no problem to saturate a 100M either if you have a decent computer. My point was not just that it was technically possible, but rather that with active filesharing clients running it's something that a naive user can easily do, today -- no future killer apps required. Joe
Re: N+? redundancy
Even if a client demanded and was willing to pay for the diverse paths there can be none available. When there is demand for something that the market cannot supply due to political constraints, then there are political solutions. The number of paths varies widely between cities, and has little to do with demand in those cities for diversity or how critical they might be to the nation as a whole. If requirements for network path separacy can be communicated in such a way that people clearly see that it is critical to the nation (or any other political body) then it is possible to release additional path opportunities to the market. The rules of thumb that I suggested had to do with how much network redundancy is likely to be enough network redundancy. I also didn't supply the numbers to back up these rules because, to the best of my knowledge, nobody has studied the risks involved in enough detail to do analyse this. I did receive one anecdotal account related to the ice storm in Montreal back in '98, I believe. It seems that this city of over 1 million inhabitants had 5 paths providing electricity to the city and 4 of those paths were knocked out. Interestingly, nobody suggested my numbers were too low or too high. I suppose that is a rough and ready tacit approval of my rough and ready rules of thumb. --Michael Dillon P.S. Let's hope that Jay gets his Mediawiki off the ground so that we can develop other best practice rules in a format that makes it easy to use them for training new people coming into the industry.
Re: Memory leak cause of Comcast DNS problems
Several of the servers that were down are not BIND, at least these: prospero:~/Desktop/fpdns-0.9.1 dgold$ ./fpdns.pl 68.87.66.196 fingerprint (68.87.66.196, 68.87.66.196): Cisco CNR I ran fpdns against them between outages. They now respond differently. prospero:~/Desktop/fpdns-0.9.1 dgold$ ./fpdns.pl 68.87.66.196 fingerprint (68.87.66.196, 68.87.66.196): q0r?1,IQUERY,0,0,1,1,0,0,REFUSED,0,0,0,0 These are the Comcast national DNS servers. (I am using plural, because there are several reverse DNS entries for this IP address - ns.cmc.co.denver.comcast.net and ns.inflow.pa.bo.comcast.net) I wouldn't rush to blame BIND for this. For purposes of investigation, does anyone have DNS servers from those periods of downtime other than the ones above? Comcast is quite a patchwork, that's to the incomplete integrations of MediaOne, ATT Broadband, etc. It would be interesting to see data on other DNS servers during the downtime periods. Many folks on various forums were suggesting the use of ns1. And ns2.level3. Of course, logic suggests that the vast majority of folks, having no Internet access, could not have read the advice. There have been three explanations given for the outage - 1) Upgrade issues 2) Memory leak/software issue 3) DDoS There is also the possibility of some combination of the above. There are a number of possible permutations. - Dan On 4/17/05 2:18 PM, Steven M. Bellovin [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Fergie (Paul Ferguson) writes: Not to my knowledge, or at least, none that has been publicly acknowledged. From a Washington Post article yesterday (posted via Yahoo! News), Comcast said that the problem manifested itself when they were in the process of upgrading their DNS servers: http://story.news.yahoo.com/news?tmpl=storyncid=1212e=3u=/washpost/2005041 6 /tc_washpost/a56223_2005apr15sid=96168964 At least in my neighborhood, Comcast appears to be running BIND 9.2.4rc6 --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: Depends on what you call caching. Does honoring a TTL qualify as caching? What other kind of DNS caching is there? Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query? That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Windows definitely caches DNS entries...but as far as I've seen, it does honor TTLs... Erik Amundson A+, N+, CCNA, CCNP IT and Network Manager Open Access Technology Int'l, Inc. Phone (763) 201-2005 Fax (763) 553-2813 mailto:[EMAIL PROTECTED] CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic. -Original Message- From: Chris Adams [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 12:35 PM To: nanog@merit.edu Subject: Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: Depends on what you call caching. Does honoring a TTL qualify as caching? What other kind of DNS caching is there? Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query? That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Apr 18, 2005, at 1:35 PM, Chris Adams wrote: Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query? That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service. Open a web browser, go to foo.bar.com for some hostname you own. Change the record on the authoritative server and clear the cache on the recursive NS. Reload the page. See if the browser goes to the new IP. Most desktop OSes do not re-query for the name again. Sometimes this is a browser issue. Sometimes it is an OS issue. Depends on too many variables to which, or both, is at fault in general. -- TTFN, patrick
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
- Original Message - From: Erik Amundson [EMAIL PROTECTED] To: nanog@merit.edu Sent: Monday, April 18, 2005 1:45 PM Subject: RE: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations Windows definitely caches DNS entries...but as far as I've seen, it does honor TTLs... from what i've seen, at least in xp, it will cache for 30 minutes and *then* obey the ttl. bad microsoft. -p --- paul galynin
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: Most desktop OSes do not re-query for the name again. Don't confuse apps and OSes. If I run lynx, it does a DNS lookup for each connect (even when it is the same hostname). -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
- Original Message - From: Chris Adams [EMAIL PROTECTED] To: nanog@merit.edu Sent: Monday, April 18, 2005 10:35 AM Subject: Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations snip That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service. from a windows command prompt, type ipconfig /displaydns it's also flushable using ipconfig /flushdns
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Apr 18, 2005, at 2:02 PM, Chris Adams wrote: Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: Most desktop OSes do not re-query for the name again. Don't confuse apps and OSes. If I run lynx, it does a DNS lookup for each connect (even when it is the same hostname). I wasn't. Notice I said: Sometimes this is a browser issue. Sometimes it is an OS issue. End of day, most OSes do cache DNS replies, and many apps further cache answers. -- TTFN, patrick
Re: cost of doing business
fwiw, 100mb to the home costs about that in japan We are talking of two different things here, traffic versus access bandwidth. It will be a while before the average household generates 5 megabit/s traffic. Even in Korea and Hong Kong, where the average broadband link is in the 5-10 Mbps range, average traffic is about 0.1 Mbps. The main purpose of high speed links is to get low transaction latency (as in I want that Web page on my screen NOW, or I want that song for transfer to my portable device NOW), so utilizations are low. For those of us that are already running triple play architectures and working on the data analysis related to the bandwidth usage growth (in my case over the last 18 months and adding services one after the other) I see this with a different light: I fully agree with the transaction latency syndrome, people are compulsive customers that want to buy right now and you (as a service provider) want to see to them purchase the service before they change their mind, just need to look at the ringtones market to see how much people are willing to spend within seconds for a piece of music they will replace in a few days/weeks with their next favorite tune from the charts that marketing is feeding them with. Where I don't agree is on the bandwidth usage analysis, once you add the IP based TV/VOD* services you will be carrying close to 5Mbps on average on your network in the near future. Either for the one of the TV channels (currently the market is talking about 2 concurrent TV channels down the same pipe to an end user's home in the North American model or 1 for the European) or the VOD. So agreed this is not Internet traffic but you will need to carry it beyond your access termination device (DSLAM/CMTS/ Ethernet switch) since the economics of the IPTV/VOD market and (current?) technical scalability will prevent you from being able to have a the full IPTV/VOD streaming (= unicast and/or multicast in this case) in each POP to keep the traffic as local as possible. So anyhow within your metro area network accessing and aggregating the customers the amount of bandwith required to service all customers will grow quite a bit with IPTV/VOD services. IMHO (of course) Thomas *Triple play IPTV/VOD = IP packets carrying a video signal using (name your favorite format) either as unicast or multicast stream. This excludes the current hybrid HFC networks that still provide digital TV via an HF stream using (insert your favorite standard here) and the Internet access and voice service over IP. Anyhow they will migrate once DOCSIS 3.0 and the wideband benefits have been marketed to all the cable operators as the next big thing they need to have and hence run an IP only service for all the triple play services.
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Aside from individual OS behavior, doesn't this seem like very bad advice? What sort of DNS cache poisoning attack could possibly work against a workstation that has a caching resolver but no DNS server? If a hacker really wished to do a name resolution attack against workstations, wouldn't they just write some spyware that injected a hosts file? Seems easier. At any rate, wouldn't disabling caching/not paying attention to TTLs have a truly adverse impact on the DNS infrastructure? What is the % difference in incremental DNS server load between a host that obeys TTLs and one that not, but makes a new query each time? A single host wouldn't have much impact - how about a couple million? Is there something I'm missing here that's motivating Yarden's advice? - Dan /head scratching On 4/18/05 1:35 PM, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: Depends on what you call caching. Does honoring a TTL qualify as caching? What other kind of DNS caching is there? Can you imagine what would happen if every time anyone ever looked up any hostname they sent out a DNS query? That's what most Unix/Linux/*BSD boxes do unless they are running a local caching name service of some time (BIND, nscd, etc.). I wasn't actually aware that Windows had a DNS cache service.
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On 4/18/05, Daniel Golding [EMAIL PROTECTED] wrote: Aside from individual OS behavior, doesn't this seem like very bad advice? I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is attackable) However, on the flip side, if nothing is ever cached, then I would expect a huge amount of bandwidth to be eaten up by DNS queries. I think a seasoned op knows when to use caching and when to not use caching, but the everyday Joe User has no idea what caching is. If they see a technical article telling them to turn off caching because it will help stop phishing attacks (which they know are bad because everyone says so), then they may try to follow that advice. Aside from the I broke my computer syndrome, I expect they'll be very disappointed when their internet access becomes visibly slower because everything requires a new lookup... Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Mon, 18 Apr 2005, Jason Frisvold wrote: Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? It would be very interesting in seeing the difference in DNS traffic for a domain if it sets TTL to let's say 600 seconds or 86400 seconds. This could perhaps be used as a metric in trying to figure out the impact of capping the TTL? Anyone know if anyone did this on a large domain and have some data to share? If one had to repeate the cache poisoning every 10 minutes I guess life would be much harder than if you had to do it once every day? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Mon, Apr 18, 2005 at 03:05:55PM -0400, Jason Frisvold said something to the effect of: On 4/18/05, Daniel Golding [EMAIL PROTECTED] wrote: Aside from individual OS behavior, doesn't this seem like very bad advice? I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is attackable) However, on the flip side, if nothing is ever cached, then I would expect a huge amount of bandwidth to be eaten up by DNS queries. You are right. Time spent in security for an ISP yielded many DoS-against-the-DNS-server complaints that turned out to be some query-happy non-cachers pounding away at the server. The solution: block the querying IP from touching the DNS server. Somehow, I think that might have hampered their name resolution efforts...? ;) cache me if you can, --ra I think a seasoned op knows when to use caching and when to not use caching, but the everyday Joe User has no idea what caching is. If they see a technical article telling them to turn off caching because it will help stop phishing attacks (which they know are bad because everyone says so), then they may try to follow that advice. Aside from the I broke my computer syndrome, I expect they'll be very disappointed when their internet access becomes visibly slower because everything requires a new lookup... Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] -- rachael treu gomes[EMAIL PROTECTED] ..quis custodiet ipsos custodes?.. (this email has been brought to you by the letters 'v' and 'i'.)
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
* Jason Frisvold: I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is attackable) I'm not sure if you can poison the entire cache of a stub resolver (which can't do recursive lookups on its own). I would expect that the effect is limited to a particular DNS record, which in turn should expire after the hard TTL limit (surely there is one).
Re: Memory leak cause of Comcast DNS problems
* Daniel Golding: I wouldn't rush to blame BIND for this. Maybe the leak wasn't in the DNS service, but some other software component which company policy required on each server (think of Tivoli, antivirus software, or CSA). Who knows? The possiblities are endless.
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
* Mikael Abrahamsson: If one had to repeate the cache poisoning every 10 minutes I guess life would be much harder than if you had to do it once every day? Not necessarily, because every cache refresh is a new attack opportunity. 8-)
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On 4/18/05, Mikael Abrahamsson [EMAIL PROTECTED] wrote: It would be very interesting in seeing the difference in DNS traffic for a domain if it sets TTL to let's say 600 seconds or 86400 seconds. This could perhaps be used as a metric in trying to figure out the impact of capping the TTL? Anyone know if anyone did this on a large domain and have some data to share? Our first foray into DNS was using a DNS server that defaulted to 86400 for new entries.. Not being seasoned, we left this alone.. Unfortunately, I don't have any hard data from that dark time in our past.. Windows 2000 DNS seems to set the ttl to 3600, which is a tad on the low side, I think... At least for mostly-static domains, anyways. But I believe the reasoning there was that they depended heavily on dynamic dns.. If one had to repeate the cache poisoning every 10 minutes I guess life would be much harder than if you had to do it once every day? I dunno.. how hard is it to poison a cache? :) -- Mikael Abrahamssonemail: [EMAIL PROTECTED] -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Memory leak cause of Comcast DNS problems
On 4/18/05, Florian Weimer [EMAIL PROTECTED] wrote: Maybe the leak wasn't in the DNS service, but some other software component which company policy required on each server (think of Tivoli, antivirus software, or CSA). Who knows? The possiblities are endless. There was, at one time, a fairly serious memory leak in Cisco CNR... I believe I saw a post indicating that CNR was possibly in use? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] Preventing poisoning attacks: I guess most attacks are against windows workstations. 1) Hide them behind a NAT-router. If they cannot see them, they cannot attack them. 2) Have your own DSN-server, root-server, authoritative server, cache. You can have your own root-server: b.root-servers.net and c.root-servers.net as well as f.root-servers.net allow cloning. Just run your Bind 9 as a slave for . . An authoritative server cannot be poisoned. Only resolvers can. When you have sensitive addresses put them into your /etc/hosts or clone their zone. Again Bind 9 allows it. Do their servers? Get the zone file via ftp or email. Authoritative servers cannot be poisoned. Have your own cache behind the NAT-router. If they cannot see you they cannot poison you. There is one exception from the rule: You browse www.bad.guy. The have a namesever ns1.bad.guy that returns something like ;; ANSWER SECTION: a.root-servers.net. 86268 IN A 205.189.71.2 Then your cache will be in the Public-Root.net . But remember - an authoritative DNS-server cannot be poisoned. Regards, Peter Dambier -- Peter und Karin Dambier Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-6252-599091 (O2 Genion) +49-6252-750308 (Sipgate VoIP) [EMAIL PROTECTED] www.peter-dambier.de peter-dambier.site.voila.fr
Verizon Offering Naked DSL in Northeast...
Wow -- I wish SBC would follow suit. :-/ http://apnews.myway.com/article/20050418/D89I0KP00.html - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Verizon Offering Naked DSL in Northeast...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fergie (Paul Ferguson) wrote: | | Wow -- I wish SBC would follow suit. :-/ | | http://apnews.myway.com/article/20050418/D89I0KP00.html | You can already get this from Covad through providers like Speakeasy. I recently switched from SDSL on a dedicated pair to ADSL. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCZB4WE1XcgMgrtyYRApdQAKCtSPzmEnmpe7m+rrllHNkmWiR9dgCfbKon 9UbB9kIWE0CXzoFdVtej8x8= =UJaD -END PGP SIGNATURE-
Re: Verizon Offering Naked DSL in Northeast...
I love this part: Tom Tauke, a senior Verizon executive, said stand-alone DSL would eventually be expanded to all of Verizon's territory and be available to anyone, regardless of whether they are a current customer. He said technical issues limited the company to a partial rollout. What possible technical issue could exist that to don't have to wire the dslam to a pots splitter? Actually, even if they did wire it to a pots splitter, and there was no pots line present, it'd still work. On Mon, 18 Apr 2005, Fergie (Paul Ferguson) wrote: Wow -- I wish SBC would follow suit. :-/ http://apnews.myway.com/article/20050418/D89I0KP00.html -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: Verizon Offering Naked DSL in Northeast...
On Mon, Apr 18, 2005 at 04:53:29PM -0400, Alex Rubenstein wrote: I love this part: Tom Tauke, a senior Verizon executive, said stand-alone DSL would eventually be expanded to all of Verizon's territory and be available to anyone, regardless of whether they are a current customer. He said technical issues limited the company to a partial rollout. What possible technical issue could exist that to don't have to wire the dslam to a pots splitter? Actually, even if they did wire it to a pots splitter, and there was no pots line present, it'd still work. I think we all know, it was about POTS revenue protection. It's fairly easy to see that the iLECs are the big players these days in the US/Domestic market. They control the last mile, and with that comes their distinct advantage. Look at how they played the rules to keep the LD carriers out of the local market, compete with Covad/Northpoint through removal of line sharing agreements, and other practices against CLECs in the past. This is a positive move, and will put some pressure on SBC to unbundle their services as well. Now if we could just get them to quit trying to keep everyone out of the local space with their extensive lobbying efforts. SBC and Verizon both seem to not want anything to do with my home state (Michigan) by not offering any of the FTTH services here and still do not deliver dialtone to some parts of the state. - jared (hoping for a more competitive local loop market for residences globally). -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Verizon Offering Naked DSL in Northeast...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You can already get this from Covad through providers like Speakeasy. I recently switched from SDSL on a dedicated pair to ADSL. I've has this with Covad, who in Las Vegas resells XO service, for years. Rock solid, and I get four static IP addresses. And since it runs on it's own line, you don't need those silly little DSL filters on all your house phones, or run VoIP if you like. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFCZCEYTs2s3OoD6D8RAvEhAJ9W+xieWGZB8H/TO1pxHErGomwBkACffNMl BwTsdtcI9Am6H6S2XGX/wuc= =P1Fg -END PGP SIGNATURE-
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On Monday, 2005-04-18 at 22:08 ZE2, Peter Karin Dambier [EMAIL PROTECTED] wrote: Preventing poisoning attacks: I guess most attacks are against windows workstations. I'm not sure what you mean by this. Cache poisoning applies to machines that are doing caching. It can affect any machine that depends on that cache. 1) Hide them behind a NAT-router. If they cannot see them, they cannot attack them. I certainly hope that this would not help. I hope that caching machines will not simply take a packet from a random address and source port 53 and use it to update their cache. I hope that the source address, source port, and destination port, at least, are checked to correspond to an outstanding dns query. If those all match, the packet will very likely get through a nat router. In other words, the nat router provides no protection from this attack at all. Why? Because it's an attack based on traffic that the natted machine has initiated. 2) Have your own DSN-server, root-server, authoritative server, cache. You can have your own root-server: b.root-servers.net and c.root-servers.net as well as f.root-servers.net allow cloning. Just run your Bind 9 as a slave for . . An authoritative server cannot be poisoned. Only resolvers can. Certainly authoritative servers can be poisoned, but not for the domains that they're authoritative for. Running your own root only provides protection for the root zone. If I make a query for www.badguy.com and the auth. server for badguy.com returns an answer for www.yahoo.com in the additional data, if I cache it, I'm likely poisoned. That can happen even if I'm auth. for root. Tony Rall
Re: Verizon Offering Naked DSL in Northeast...
On Mon, 18 Apr 2005, Andy Johnson wrote: Alex Rubenstein wrote: What possible technical issue could exist that to don't have to wire the dslam to a pots splitter? Actually, even if they did wire it to a pots splitter, and there was no pots line present, it'd still work. My speculation is that their billing/accounting system is based on a POTs number, and since these customers will not need one, they will have administrative errors managing accounts. that'd be unfortunate, what with number portability and all, yes?
Re: Verizon Offering Naked DSL in Northeast...
On Mon, 18 Apr 2005, Christopher L. Morrow wrote: that'd be unfortunate, what with number portability and all, yes? Until a couple of months ago, Cingular Wireless here was still determining whether or not to bill for mobile to mobile calls based on whether the called party's NPA was one of theirs. Never overestimate a telco.. matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: DSCP ECN bits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Christian, The ECN capable transport (ECT) bit would need to be set by the data sender to indicate that the end-points of the transport protocol are ECN-capable. The intermediate routers will need to honor these bits as well. Fore more information, checkout, http://www.faqs.org/rfcs/rfc2481.html regards, /vicky [EMAIL PROTECTED] wrote: | Hi, | | Is anyone using the DSCP ECN bits to any great extent? Does it require | end-host support in the stack to actually work? | | Cheers, | Christian | | | | This message and any attachments (the message) is | intended solely for the addressees and is confidential. | If you receive this message in error, please delete it and | immediately notify the sender. Any use not in accord with | its purpose, any dissemination or disclosure, either whole | or partial, is prohibited except formal approval. The internet | can not guarantee the integrity of this message. | BNP PARIBAS (and its subsidiaries) shall (will) not | therefore be liable for the message if modified. | | ** | | BNP Paribas Private Bank London Branch is authorised | by CECEI AMF and is regulated by the Financial Services | Authority for the conduct of its investment business in the | United Kingdom. | | BNP Paribas Securities Services London Branch is authorised | by CECEI AMF and is regulated by the Financial Services | Authority for the conduct of its investment business in the | United Kingdom. | | BNP Paribas Fund Services UK Limited is authorised and | regulated by the Financial Services Authority. | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCZCyZpbZvCIJx1bcRAnBdAKCIBOzBExnGSHKa3VvSN2gCbb/zUwCg6zJI AiguIwhvN6jIyu7/rri3s/c= =chxS -END PGP SIGNATURE-
Re: Verizon Offering Naked DSL in Northeast...
Andy Johnson wrote: My speculation is that their billing/accounting system is based on a POTs number, and since these customers will not need one, they will have administrative errors managing accounts. Yeahbut. SBC was happy to assign me something that looks like a phone number, but wasn't, so I could make monthly payments on a Yellow Pages ad a few years ago. I was in area code 216, and the account number was 216 R01 XXX (I forget what the rest of it was). So I'm not buying that argument. ;) -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED The wisdom of a fool won't set you free --New Order, Bizarre Love Triangle
Re: Verizon Offering Naked DSL in Northeast...
Date: Mon, 18 Apr 2005 16:14:01 -0700 From: Steve Sobol [EMAIL PROTECTED] To: North American Networking and Offtopic Gripes List [EMAIL PROTECTED] Subject: Re: Verizon Offering Naked DSL in Northeast... Andy Johnson wrote: My speculation is that their billing/accounting system is based on a POTs number, and since these customers will not need one, they will have administrative errors managing accounts. Yeahbut. SBC was happy to assign me something that looks like a phone number, but wasn't, so I could make monthly payments on a Yellow Pages ad a few years ago. I was in area code 216, and the account number was 216 R01 XXX (I forget what the rest of it was). So I'm not buying that argument. ;) Speaking from experience with Ameritech (pre-SBC, that is) in Illinois, *before* any form of shared-line DSL was available, the ILEC required a phone number _at_the_service_location_ -- for reasons of insuring that the DSL line was delivered to the right place. (I don't know what they did if the phone belonged to a CLEC; I _do_ know that no land-line service caused all sorts of commotion.) There _is_ a reason for that -- particularly in larger multi-family buildings, there may be _more_than_one_ service entrance for that building. With different parts of the building reachable only from a given service entrance point. Thus, a need to ensure that the DSL is provisioned on the right cable, going to the correct service entrance point. A phone number at the premises is something that the end-user _can_ reasonably be expected to know, and *does* uniuqely identify the path for service to reach that premises, *AND* can be reliably parsed by a computer. A 'street address' is considerably less reliable -- all sorts of inconsistant formats are used, user input may not match the structure in the database, etc., etc. Then you have the situation where a building may have multiple street addresses (e.g. a corner lot, and separate entrances), and the address for the 'service entrance' point is *not* the same as the service delivery address. There's a whole nother layer of database to rummage through, when there is no _existing_ service to a given location. One that is *not* -- at least anywhere near as easily -- amenable to automated 'validation' look-ups. It can be 'worked around', but it takes _manpower_ to do it. people time is _expensive_, vs machine time. I had an extended go-around on this with a DSL provider and the ILEC when I ordered DSL for a company employee who was using only a cell-phone -- no land- line service at all. The DSL provider computer wouldn't accept the order without a phone number -- so we gave it the landlord's number (the other side of the 2-flat). Then the ILEC computer wouldn't accept the order, because it _knew_ that there was no phone in service at that address. As I recall, this got escalated up the food chain, until a Sr. VP was talking to a Sr. VP, whereupon it _finally_ went through. The installers that came out (one from the ILEC to 'tag'/test the pair, and then the DSP provider guy to do the actual equipment hook-up) both remarked that they'd *never* seen an order like that one -- the 'premises phone number' read 000 000-. grin I suspect that the 'technical difficulties' that Verizon ran into, in implementation had to do with difficulties in _automating_ address-based queries into the physical plant database.
Qwest protests SBC-ATT merger as harmful to competition
One might wonder if Qwest is a little upset about being rebuffed by MCI in its efforts to merge the two companies. http://www.siliconvalley.com/mld/siliconvalley/11426726.htm - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
Mikael Abrahamsson wrote: On Mon, 18 Apr 2005, Jason Frisvold wrote: Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? It would be very interesting in seeing the difference in DNS traffic for a domain if it sets TTL to let's say 600 seconds or 86400 seconds. This could perhaps be used as a metric in trying to figure out the impact of capping the TTL? Anyone know if anyone did this on a large domain and have some data to share? First hand experience, I can tell you that decreasing the SORBS NS records TTLs to 600 seconds resulted in 90qps to the primary servers, increating the TTLs to 86400 dropped the query rate to less than 5 per second. (That's just the base zone, not the dnsbl NS records) Regards, Mat
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
It would be very interesting in seeing the difference in DNS traffic for a
domain if it sets TTL to let's say 600 seconds or 86400 seconds. This
could perhaps be used as a metric in trying to figure out the impact of
capping the TTL? Anyone know if anyone did this on a large domain and have
some data to share?
there is some good analysis in the classic paper
@inproceedings{ dnscache:sigcommimw01,
title = {DNS Performance and the Effectiveness of Caching},
author = {Jaeyeon Jung, Emil Sit, Hari Balakrishnan and Robert Morris},
booktitle = {Proceedings of the {ACM} {SIGCOMM} Internet Measurement Workshop
'01},
year = 2001,
month = {November},
address = {San Francisco, California},
url = {citeseer.ist.psu.edu/jung01dns.html} }
randy
