rbl.cluecentral.net is back in the air
Dear all, This is to let you know that I have resuscitated the DNSBL which lists all IPv4 space currently announced by ASN and country-code. For those of you who remember, I closed it down for personal reasons 18 months ago. The current version is light-coded, easy to maintain and almost fully-automatic. One of the main reasons to build it again was the high number of queries which was still incoming on the servers, so apparently it was very popular. More information on how to use it can be found on http://www.cluecentral.net/rbl/ If you reply or flame, please reply-to-poster. Thanks, -- Sabri
Re: ARIN sucks?
On Thu, Sep 14, 2006 at 01:56:29PM +0300, Hank Nussbacher wrote: Hi, I stated those numbers as a good example. My experience in RIPE is 3-4 months for the entire process. My last one in RIPE took 6 months for the IPv4, ASN and IPv6 allocations. It took me 2 days for a /22 and 1 day for an ASN. All I did was correctly fill out the requested forms and include the proper justification. But then again, I attended an LIR-course which explained RIPE's policies and procedures. These are free and the course-material is online for your convenience: http://www.ripe.net/training/lir/material/ HTH -- Sabri
Re: Net Neutrality Legislative Proposal
On Mon, Jul 10, 2006 at 03:25:55PM -0400, Seth Johnson wrote: Hi, So far, much of the argument over net neutrality has been over whether service providers should be allowed to favor one application, destination or Internet service over another. This is Net neutrality at the application layer. But the real issue is the neutrality of the IP layer where routers treat alike bits from every type of application. So, what happened to my network, my rules? Perhaps I'm not seeing the point here, but what on earth does a government has to do with the question wether or not a service provider implements QoS on his network? Thanks, -- Sabri ENOSUNSHINE when $SHE == gone
Re: NANOG Spam?
On Wed, Jul 05, 2006 at 05:20:04PM -0400, Jim Popovitch wrote: Hi, Finally, we crawled the archives of the big lists and have come up with a list of subscribers who haven't posted in over 9 months, we plan to set the mod bit on them too very soon. So people who are 'real' but lurk a loti should reply to this message so they don't get moderated :) -- Sabri Yes!! I just saved myself from being moderated (did I?)
Re: oh k can you see
On Mon, Oct 31, 2005 at 12:19:58PM -1000, Randy Bush wrote: Hi, this implies that a non-trivial part of the net can not see anycast services for which some of the servers are marking their announcements as NO_EXPORT. Is it an idea to have anycasted instances using NO_EXPORT announce /25's instead of /24's? That way you would still have global connectivity for the /24 and still respect the NO_EXPORT. Another possibility is for $LARGE_ISP to localpref the NO_EXPORTED down to $LOW value (some of you will go 'doh' now). Thanks, -- Sabri please do not throw salami pizza away
rbl.cluecentral.net will cease to exist
[ apologies for the wide distribution ] Dear reader, On november the 1st 2005, the rbl.cluecentral.net ip-to-country and ip-to-as DNS list will cease to exist. All queries will fail and on december the 1st 2005 I will remove the dns-servers from the machines they are running on. Important note: some users have been using this list for explicit whitelisting purposes of their own IP space. Please make absolutely sure that you have alternatives. Refer to http://moensted.dk/spam for a list of possible alternatives for your configuration. Any queries/flames/followups are welcome via private e-mail. Thanks, -- Sabri please do not throw salami pizza away pgphg9XbNUHRt.pgp Description: PGP signature
Re: h-root-servers.net
On Sun, Oct 23, 2005 at 04:07:03PM -0500, John Palmer (NANOG Acct) wrote: Dear John, No, why don't you stop insulting people, Niels. You attack Peter because of his involvment in the Inclusive Namespace. FYI: Public root servers are online and available. Maybe the h-root ops should ask the P-R technical committee for assistance if they cannot keep their servers up. Peter Dambier did post nonsense. In fact, it was total nonsense since the AMS-IX is not present in any KPN datacentre, *and* it is impossible for end-hosts to connect to the AMS-IX directly. Niels his post was correctly and imho not insultive. Niels wrote: * [EMAIL PROTECTED] (Peter Dambier) [Sun 23 Oct 2005, 22:34 CEST]: I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX. Peter, please stop posting nonsense. -- Niels. -- Sabri please do not throw salami pizza away pgpxHOjSsQzLK.pgp Description: PGP signature
Re: h-root-servers.net
On Mon, Oct 24, 2005 at 02:40:14PM +0200, Peter Dambier wrote: Sabri Berisha wrote: Dear Peter, Peter Dambier did post nonsense. In fact, it was total nonsense since the AMS-IX is not present in any KPN datacentre, *and* it is impossible for end-hosts to connect to the AMS-IX directly. Part of the traceroutes between me and the system I was talking of: 6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 18.334 ms 22.725 ms 4 ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2) 145.264 ms 152.212 ms 5 amx-gw2.nl.dtag.de (195.69.145.211) 14.737 ms 13.115 ms 11.501 ms 5 gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38) 169.072 ms I did not say the host was connected to the IX. I said it was living in a datacentre connected to Amsterdam IX. You said: I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX. Your own traceroute clearly shows that your host is not directly connected to the AMS-IX. Nor does the KPN datacenter it resides in. The AMS-IX has 4 datacenters where members can place equipment which can be directly connected to the AMS-IX: - GlobalSwitch; - Sara; - Nikhef; - Telecity2, Kuiperbergerweg; Every statement otherwise is bogus, nonsense, crap or whatever term you prefer to use for this. -- Sabri please do not throw salami pizza away
Re: Customer view vs. operator view was:( h-root-servers.net)
On Mon, Oct 24, 2005 at 03:06:35PM +0100, [EMAIL PROTECTED] wrote: Dear Michael, This is a good example of a useless argument caused when one person is speaking from a customer viewpoint and one customer is speaking from an operator viewpoint. Last time I checked, the O in [EU|NA|AFRI]NOG stands for 'operator'. Niels made a perfectly valid point by saying that it is impossible for an end-user to be connected to the AMS-IX and he was flamed for it. If Peter Dambier has no clue about end-hosts vs intermediate systems, let alone how to parse a traceroute with his grey mass, he needs to be educated. Just as I needed many years ago. Anyway, this is going way off-topic so this will be my last post in this subthread. Feel free to reply off-list. -- Sabri please do not throw salami pizza away
Re: The ORIGIN option on BGP - what is it for?
On Thu, Oct 20, 2005 at 10:34:35PM -0700, Peter Boothe wrote: So my question is: What do people use ORIGIN: EGP vs ORIGIN: IGP to distinguish? What makes a route EGP vs. IGP to you? Origin is a mandatory transitive attribute which is being used in the BGP decision algorithm. If you have a prefix with the same localpref and aspath-length, the decision will be made based on the lowest origin-value. IGP wins over EGP, EGP wins over incomplete. You might use it to influence your inbound traffic. -- Sabri please do not throw salami pizza away
Re: IPv6 news
On Fri, Oct 14, 2005 at 12:32:29AM +, Christopher L. Morrow wrote: As ted and others have already said: Show me the customers who are asking... so far the numbers are startlingly low, too low to justify full builds by anyone large. Just wait for a popular adult-content-provider offering website-access for free via IPv6.. -- Sabri please do not throw salami pizza away
Re: IPv6 news
On Fri, Oct 14, 2005 at 10:17:51AM -0400, Marshall Eubanks wrote: Dear Marshall, Just wait for a popular adult-content-provider offering website-access for free via IPv6.. Why ? Are you implying that there is unlimited free IPv6 bandwidth ? Nope. If not, why would they do that ? Imagine the following scenario: It's 2009, the world reaches the end of it's ipv4 supply. As large global networks are still struggling to implement ipv6 on their equipment, their customers are facing more and more problems to get additional IP-space from their RIR's and are forced to use ipv6. But due to the lack of planning, only a number of access-isp's have successfully deployed ipv6 on their networks and so we have shattered native ipv6 connectivity throughout the internet. To encourage the access- and carrierindustry, (adult)contentproviders in all continents decide to boost the demand for ipv6 connectivity and offer their services for free to ipv6 users, for a limited period of time. Why did the internet grow so fast in the 90's? The public was able to access the network and created the demand for more content. This content attracted more and more eyeballs, and thus more commercial activities were deployed, resulting in a exponential growth of the network. Without eyeballs, contentproviders are not encouraged to deploy ipv6. Without content, eyeballproviders are not encouraged to deploy ipv6. It's a matter of time before one of them will be forced to end this circle and there is only one way to attract a large audience: giving a way your service for (nearly) free. -- Sabri please do not throw salami pizza away
Re: Problems
On Tue, Oct 11, 2005 at 07:37:15AM -0700, Philip Lavine wrote: I am having problems with people connecting from the East Coast to my AS 17021 via qwest AS 209 on the West Coast. How do I troubleshoot this? I would suggest to check up on a view route-servers, do some traceroutes, etc. telnet route-views.oregon-ix.net telnet route-server.cerf.net and do some bgp queries (show ip bgp your address range) -- Sabri please do not throw salami pizza away
Re: [Misc][Rant] Internet router (straying slightly OT)
On Thu, Sep 29, 2005 at 05:39:30PM -0400, Mark Owen wrote: Any suggestions? Start with the OSI[1] model to grasp the fundamentals, next make sure you have a basic knowledge of how TCP/IP addressing works[2]. To get an understanding of routing-protocols, begin with RIP[3] and perhaps run your own RIP-lab by using Quagga[4] software on a Linux box. That will get you off the streets for a weekend :) Cheers, -- Sabri please do not throw salami pizza away [1] http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm [2] http://www.networkclue.com/routing/tcpip/addressing.php [3] http://www.livinginternet.com/i/iw_route_igp_rip.htm [4] http://www.quagga.net
Re: [Misc][Rant] Internet router (straying slightly OT)
On Fri, Sep 30, 2005 at 10:01:34AM -0400, Joe Abley wrote: Hi, RIP also has the advantage that a worked, non-trivial example of the protocol can fit on a whiteboard, which makes it a reasonable way to teach the concept of a routing protocol to a classroom full of people who have never heard of such at thing. Which is exactly the reason why I mentioned RIP as a routing protocol to start with. Using RIP instead of OSPF or IS-IS has 2 advantages: one is the simplyness of the concept and the second one you already mentioned: Absolutely agreed, however, that such teaching also necessarily involves emphatic shouting of YOU WILL NOT TURN THIS ON IN YOUR PRODUCTION NETWORK. You learn why not to use RIP in an early stage of your career. Mentioning the terms router-lsa, network-summary-lsa or nssa-lsa to a person who potentially does not even know the difference between a distance-vector and a link-state protocol has no positive effect on the learning curve. -- Sabri please do not throw salami pizza away
Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services
On Fri, Sep 30, 2005 at 02:33:13PM +0200, Niels Bakker wrote: Hi, To the public if it looks like internet they expect it to work like internet You are misunderstanding. The data in .gprs is used by infrastructure in the GSM networks to decide where a user's home station is. End users have no way of interacting with this infrastructure (beyond turning on their phones outside their home country). He has a point. Remember Het Net* as it was before they proxiet to the real internet. Users expected the internet and after a while, they got it. -- Sabri please do not throw salami pizza away * Het Net, translated as The Net was an attempt by the dutch national telco in the late 90's to come up with a big intranet where users could dialup, using RFC1918 addresses and visit community and commercial sites. After a few months, proxy-support to the real internet was added and even later it was integrated into Planet.nl, a dutch dsl-isp.
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 02:04:21PM -0700, Peter Boothe wrote: On Fri, 5 Aug 2005, Sabri Berisha wrote: Hi Peter, Everything can break. We want to know what will break less. http://soy.dyndns.org/~peter/projects/research/anycast/nanog/ So, since Daniel Karrenberg showed that there was at least a 1% difference between anycast and unicast reliability, and we showed that the median AS switches root clusters every 3 hours, anycast is still a net win for the median AS, even with TCP queries, and is probably a net win for everyone except the people who have severe extant route flapping issues. So what I understand from your slides is basically that you acknowledge the fact that it is theoretically possible for the setup to cause temporary loss of connectivity (very minor packetloss) which may result in DNS queries to timeout, but that the impact of such an event has no real-life damage. I thought that it would be virtually impossible to get this actually working outside of a lab-environment due to continuous route-changes on the net. I stand corrected. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: [EMAIL PROTECTED]| cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 12:05:08PM +0200, Iljitsch van Beijnum wrote: Hi, I'm not sure how much room additional records take up, but I think it's a little under 30 bytes. At this rate, there is no way you're going to run out of 512 bytes with less than 10 records. Then there is EDNS0, and failing that, TCP. With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: [EMAIL PROTECTED]| cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 04:10:46AM -0700, Bill Woodcock wrote: On Fri, 5 Aug 2005, Sabri Berisha wrote: With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS. Bzzzt. Try again. /--[cabernet]--[merlot]--[riesling]--[server 1] [end-host] - [shiraz] | \--[sangria]]--[chardonnay]--[bordeaux]--[server 2] Imagine a TCP session between end-host and server 1. The path is asymmetric: traffic from end-host to server 1 flows as shiraz-cabernet-merlot-riesling-server 1 traffic from server 1 to end-host flows as riesling-merlot-chardonnay-sangria-shiraz-end-host end-host does a dns request, and server 1 answers. There are now 2 things which can theoretically break: 1. route change Suppose merlot looses adjacency with riesling. It will then send the tcp-packets from end-host to server 2, which has now knowledge of the session and return a RST 2. mtu problems Suppose server 1 returns a packet with an size of X bytes. Suppose Chardonnay has an mtu of X-1 to Sangria. Chardonnay will then send a packet-too-large to the server 1. But what if Chardonnay has a better route via Bordeaux instead of via Merlot? The icmp packet will not arrive at server 1 and the request will time out. Yes, this is theoretically. Yes the request will definately be retransmitted. But it can brake, so imho anycast dns using tcp is not a wise thing to do. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: [EMAIL PROTECTED]| cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
Re: /8 end user assignment?
On Fri, Aug 05, 2005 at 11:51:53AM +, [EMAIL PROTECTED] wrote: Sabri Berisha [EMAIL PROTECTED] wrote: [...] With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS. Erm, bollocks. Just because a few nameservers are anycasted doesn't mean that the vast majority of non-anycasted servers may not use TCP. Oh I can't agree with that more. No problem in using tcp for non-anycasted servers.. Optimising the common case of simple lookups so they fit in a UDP request makes good sense, but an overzealous determination to stamp out TCP DNS is not helpful, since it is rather useful under certain circumstances. I agree here, -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: [EMAIL PROTECTED]| cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
Re: beware of the unknown packets
On Wed, Jan 26, 2005 at 11:12:19PM +0200, Petri Helenius wrote: Hi, http://www.kb.cert.org/vuls/id/409555 Did anyone here of any exploits being in the wild? -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net
Re: Smallest Transit MTU
On Wed, Dec 29, 2004 at 05:04:11PM -0500, Joe Abley wrote: On 29 Dec 2004, at 16:33, Tony Rall wrote: But that only affects tcp traffic - it does nothing to help other protocols. Are there any common examples of the DF bit being set on non-TCP packets? [EMAIL PROTECTED] sabri]# host -t ns verisign.com 192.5.6.30 Using domain server 192.5.6.30: verisign.com name server bay-w1-inf5.verisign.net [EMAIL PROTECTED] root]# tcpdump -Xn host 192.5.6.30 tcpdump: listening on fxp0 17:37:53.124955 217.69.153.39.55058 192.5.6.30.53: 58565+ NS? verisign.com. (30) 0x 4500 003a 5f10 4011 e312 d945 9927E..:[EMAIL PROTECTED]' 0x0010 c005 061e d712 0035 0026 8ac9 e4c5 0100...5... 0x0020 0001 0876 6572 6973 6967.verisig 0x0030 6e03 636f 6d00 0002 0001 n.com. 17:37:53.216656 192.5.6.30.53 217.69.153.39.55058: 58565- 3/0/3 NS[|domain] (DF) 0x 4500 00ca 4000 3111 1093 c005 061e[EMAIL PROTECTED] 0x0010 d945 9927 0035 d712 00b6 1b79 e4c5 8100.E.'.5.y 0x0020 0001 0003 0003 0876 6572 6973 6967.verisig 0x0030 6e03 636f 6d00 0002 0001 c00c 0002 0001n.com... 0x0040 0002 a300 001a 0b62 6179 2d77 312d 696e...bay-w1-in 0x0050 6635 f5 Here you go. A root-nameserver setting the DF-bit on its replies :) -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net http://www.bash.org/?78486
Re: I-D on operational MTU/fragmentation issues in tunneling
On Thu, Oct 14, 2004 at 06:05:06PM +0200, Mikael Abrahamsson wrote: On Thu, 14 Oct 2004, Sabri Berisha wrote: for the lack of knowledge of the end-user administrators or webmasters. ... or vendors of equipment that these people use. There are plenty of vendors out there who make loadsharing-equipment for the enterprise that doesn't handle all these cases. Unfortunately yes. In fact, I quite recently found a problem in Riverstone's SSR2000's which just drop host-unreachables on tcp-loadbalanced connection.. However, we still need to ask the question do we keep finding workarounds for other peoples poor administration/implementation of technical solutions?.. The technical solution for MTU problems is Path MTU Discovery. If a vendor fails to implement, one should not buy its equipment. If an end-user breaks his own connectivity, he/she needs education. That would be the ideal world. In the less-than ideal world we have to find a way to defeat the cluelessness (excuse the language) of vendors and end-users. -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net
Re: I-D on operational MTU/fragmentation issues in tunneling
On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote: Hi Pekka and others, Please send comments to me by the end of this week, either on- of off-list, as you deem appropriate. With the risk of stating the obvious I would say that normally, PMTUD should do the trick. Afterall, there is no real difference between the lower MTU of a tunnel and the lower MTU of any other link. With this in mind, the real problem can be found on networks and hosts that block ICMP-host-unreachables (or simply all ICMP traffic for security reasons). Taking this one step further, one might realise that we (as networking community) are looking for a technical solution to compensate for the lack of knowledge of the end-user administrators or webmasters. In my work I have been using tunnels quite a lot, and have delt with a lot if issues regarding PMTUD problems. For end-users behind a tunnel, the best solution is usually to turn PMTUD off completely, such as [EMAIL PROTECTED] root]# sysctl -w net.inet.tcp.path_mtu_discovery=0 net.inet.tcp.path_mtu_discovery: 1 - 0 on a FreeBSD box. I agree that this is far less efficient than it should be, but that's always the flipside of the tunnel-coin. Another option would be to simply strip the DF bit on your tunnel entrance point, but that would be rather undesirable.. -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net
Re: European Nanog?
On Sun, Sep 12, 2004 at 09:16:33PM +0200, Michel Renfer wrote: Hi, The NOG philosophy don't work in Europe. That's not correct. The concept works in switzerland with SwiNOG very well - at least two meetings every year and a good organized communitiy behind SwiNOG. Agree, here in .nl we have (how surpising) NLNOG. This is a semi-open forum (read access for everyone, posting for a limited group). From time to time we even have social meetings. No formal meetings (yet). Works like a charme! -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net
Re: (UPDATE) Can a Customer take their IP's with them? (Court says yes!)
On Tue, Jun 29, 2004 at 09:17:36PM -0400, Richard A Steenbergen wrote: Hi, There are many instances in the business world where a court prohibits you from disconnecting services to a customer so that their business can continue to operate, such as during chapter 11 bankruptcy proceedings. You should really be *glad* that they ARE paying you, and especially at the rates mentioned in their affidavit, for that much longer. Or perhaps you are seeing something in this that I am not? This is more than the court prohibiting NAC from terminating this customer (on their request!).. The TRO says: (f) NAC shall permit UCI to continue utilization through any carrier or carriers of UCI's choice of any IP addresses that were utilized by, through or on behalf of UCI under the April 2003 Agreement during the therm thereof (the Prior UCI Addresses) and shall not interfere in any way with the use of the Prior UCI Addresses. I don't know about you, but I read this as a court converting non-portable address space to portable address space, without looking at the consequenses for ARIN, NAC and network operators around the world who need to utilize more RAM in their routers to store additional routes simply because they are to ignorant to follow the technical guidelines and policies of ARIN. And I find this situation highly undesirable, regardless of any of the other facts mentioned in the legal documents (which I have read, thanks for those). And then I'm not even taking into account the fact that the UCI/Pegasus is a well-known spammer (http://www.spews.org/html/S2649.html). -- Sabri, I route, therefore you are Bescherm de digitale burgerrechten: http://www.bof.nl/donateur.html
Re: Can a Customer take their IP's with them? (Court says yes!)
On Tue, Jun 29, 2004 at 12:44:43AM -0400, Charles Sprickman wrote: Hi, As far as other ISPs helping out in the form of a letter to the court, what do you need beyond a well, this is one more route we need to carry that we shouldn't have to and How do I know how to properly report abuse issues regarding this block? I would go even further: if there is a dispute over the so-called ownership of a netblock, there is no party who can guerantee proper routability and technical responsability so I would probably blackhole it. As for the netblock: I just did a quick scan and here is what I found: 64.21.0.0/17 *[BGP/170] 3d 17:52:24, MED 64, localpref 210 AS path: 6320 8001 I 64.21.1.0/24 *[BGP/170] 3d 17:52:49, localpref 100 AS path: 3356 3561 6347 25702 I I'm not sure wether or not 64.21.1.0/24 is the disputed netblock, but this seems the only more specific without AS8001 in the path. -- Sabri, I route, therefore you are
Re: Can a Customer take their IP's with them? (Court says yes!)
On Tue, Jun 29, 2004 at 09:43:41AM +0200, Florian Weimer wrote: Hi, As for the netblock: I just did a quick scan and here is what I found: 64.21.0.0/17 *[BGP/170] 3d 17:52:24, MED 64, localpref 210 AS path: 6320 8001 I 64.21.1.0/24 *[BGP/170] 3d 17:52:49, localpref 100 AS path: 3356 3561 6347 25702 I I don't think it's this one: route: 64.21.1.0/24 origin: AS8001 I don't see this netblock originating from AS8001 anywhere, and I am rather curious which netblock it does concern. Does anyone know? :) -- Sabri, I route, therefore you are Bescherm de digitale burgerrechten: http://www.bof.nl/donateur.html
Re: Any way to P-T-P Distribute the RBL lists?
On Wed, Sep 24, 2003 at 10:30:16PM -0400, Drew Weaver wrote: Hi, I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry? Disregard this if im totally out of line, but it would seem to me that this would be possible. Whatever you come up with, it practically always has a downside: spammers can get the whole list as well. Image an open-proxy-dnsbl being distributed via peer to peer or via distributed means as usenet. Spammers would love it as they no longer have to scan for themselves, same for open relays. For some form of dnsbls, such as the geographical ones, it might be useful to simply have everyone generate their own copy using the code the creators use. An option could be to setup large DNS servers on various IXP's like is being done for other nameservers so you 'distribute' the same nameserver on different geographical locations. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant.
Re: What *are* they smoking?
On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant.
