a note to those who would automate their rejection notices
today AOL thoughtfully supplied the following to [EMAIL PROTECTED]: [EMAIL PROTECTED] SMTP error from remote mailer after initial connection: host mailin-02.mx.aol.com [64.12.137.89]: 554-(RLY:B1) The information presently available to AOL indicates this 554-server is generating high volumes of member complaints from AOL's 554-member base. Based on AOL's Unsolicited Bulk E-mail policy at 554-http://www.aol.com/info/bulkemail.html AOL may not accept further 554-e-mail transactions from this server or domain. For more information, 554 please visit http://postmaster.info.aol.com. this was in response to what the e-mail community refers to as a trivial forgery, whose salient headers were: Return-path: [EMAIL PROTECTED] Received: from port-212-202-52-233.reverse.qsc.de ([212.202.52.233] helo=1-online-poker-video.com) by mx01.qsc.de with esmtp (Exim 3.35 #1) id 1AQIw9-bF-00; Sun, 30 Nov 2003 05:11:58 +0100 Message-ID: [EMAIL PROTECTED] From: Ediva Clapp [EMAIL PROTECTED] so once again we see, as in the case of the anti-virus rejection notices, that my reward for having my domain name forged in spam that didn't come from here, is to get mail from AOL telling me that they rejected it. so, i'll add this pattern to my own drop silently filters along with chaff from symantec's products, network associates' products, and so on. of the foundational principles which made the internet possible and which made it different from alternatives such as OSI, very few remain. one of them was must scale indefinitely. a simple application of this principle toward anti-virus and anti-spam automated rejection notices is to ignore the envelope and ignore the header and just focus on the peer IP address: To: [EMAIL PROTECTED] would have been a better destination for this. it's standards-compliant, and if the sender isn't an open proxy then they'll be able to get it, and it will not needlessly increase the collateral damage toward the holders of domains that were forged. don't make me stop this car, kids. ...and to all a good night.
Re: a note to those who would automate their rejection notices
pv of the foundational principles which made the internet pv possible and which made it different from alternatives such as pv OSI, very few remain. Would SPF http://spf.pobox.com/ be a bit less destructive than many other proposals to counter trivial forgery. No. Nor will Yahoo's recently announced technology make any real difference. Preventing forgery is a way of protecting domain names as service marks and also ensuring that your own or your customers' non-spam output isn't snared in a bunch of false-positive trappery. But it won't stop or even slow the rate at which spam is sent or is received. Spammers still lie, but they are no longer as dumb as fence posts, and they can register throw-away domains whose crypto-authenticity is completely valid, even in the presence of wide scale wormspoor-proxy usage. It could be that I'm just especially irritable this year, or it could be that the reinvention frequency of bad ideas really is growing at the same rate as the internet's population. I no longer think that E-mail as we know it will survive. But I would be less irritable about it if the people who keep proposing to save it would (a) do their homework, (b) assume that spammers are going to try to adapt, and (c) think about the side effects of the tools they deploy. This is information warfare. Warfare. You aren't fighting the terrain or the elements or some mindless bacteria. You're fighting other humans, and they are armed, committed, dangerous, and adaptive. In that light, I look at things like Bayesian filters or Vipul's Razor and I wonder, why is the D in Vern's DCC (see www.rhyolite.com/dcc) so difficult to predict a need for? (Y'all already know my views on relay-probing without spam-in-hand, but the tie-in here is how can you fight spam if your principles aren't different from the people you're fighting? where exactly do you think it will end?) Anyway, I hope folks will stop sending automated rejection notices to domains who were not involved, other than by forgery, in the transmission of a virus or spam. In other words, there's relevant operational content in this thread, and when fighting spam it would be reasonable to avoid hurting uninvolved third parties. AOL, please listen.
Re: Root Authority
An interesting question I've dealt with a few times: From whom do the root nameservers derive their authority? we (i'm speaking for f-root here) have no authority. nobody has to listen to us, we are the most powerless bunch of folks you'll ever meet. now if you'd asked where we derive our *relevance*, i'd say the same as mr. bush and mr. kletnieks -- from all the root.cache files that point at us. and as long as we don't do anything stupid i guess (and hope) that this state of affairs will continue. (relevance trumps authority.) that having been said, f-root got its start as NS.ISC.ORG and the man who said it was ok for us to be a root name server was jon postel. i'm not sure he had any authority either, but folks pointed at him and so what he said was relevant in spite of any authority he mightn've had. -- Paul Vixie
Re: incorrect spam setups cause spool messes on forwarders
telling spammers 4xx or 5xx doesn't matter, they don't listen. yes, but interestingly, every smtp transport (remote ip address who connects to your tcp/25 service) who ignores 5XX (which you can tell because they come back and try the same thing again over and over) is either a spammer or the output side of a proxy (which might be hard to detect). so it turns out that ignoring 5XX is like sending up a flare, blackhole me!. -- Paul Vixie
Re: incorrect spam setups cause spool messes on forwarders
(susan, this is in a spam related thread but i'm adding offtopic remarks which i think are actually in-charter for nanog. --pv) Verizon does SMTP callbacks, connecting back to the MX of the envelope sender and trying to verify that the user exists while something like RMX or MAILFROM would probably be a more robust alternative, verizon's actions are not irrational on a purely cost:benefit basis when the costs and benefits being measured are only their own. however, cost and benefit are not isolatable in that way, and folks who try to isolate them end up causing others to pile workaround on top of workaround until the whole system is just gum and mud. if verizon wanted to jointly sponsor a clearinghouse of email senders who had passed the callback test, with appropriate caching and error analysis and robust global mirroring, i'm sure that there would be other isp's and large e-mail carriers who would want to help, and i'm sure that authors of mail software, both opensource and not, would want to offer the feature of checking such a ephemeral sender whitelist (ESW?) but as long as verizon acts alone, they're just hurting themselves, and the overall system. consider what would happen if everybody did callbacks; first, what would happen to the load on the world's nonabusing mail servers, and then, what would the spammers do in response if this was effective? -- Paul Vixie
Re: RBLs in use
and then there's the granddaddy of them all, MAPS. see www.mail-abuse.org. -- Paul Vixie
Re: looking for pull traffic
i'm sure search engines like google or altavista or microsoft or yahoo would happily charge you less for suck than your peers/transits would (like to) change you for blow. with transit-exchange businesses coming into existence, and with older peering-exchange businesses willing to support transit-exchange, there really ought to be a market for suck. there's certainly no reason for a search engine to pay for their suck; it's extremely valuable, no matter who they pull it through, big or small. and it's arguable that quality of suck will be less of a revenue driver than quality of blow, so arguments of the form you should suck through us because we have a better network aren't very weighty. my guess is that when isp's start paying customers for suck in order to balance their own ratios or to upset other people's ratios, that it will stabilize at about 10% of current blow-based transit pricing. and that there will all of a sudden be a lot more ddos'ing, fly-by-night crawlers, and whatnot than there are today. gads, what a world. (anybody have any guesses how much of the current ddos load is driven by ratio concerns? that is, now that we know spammers are hiring folks to ddos antispammers, can we finally admit that isp's are hiring folks to fix their ratios for them by ddosing from larger-provider networks? viva laissez faire, i guess.) re: [EMAIL PROTECTED] (matthew zeier) writes: Higher powers have decided our 95/5 traffic slit needs to move closer to 60/40 (transit pricing). I'm looking for legitimate ways to generate a significant amount of pull traffic, including partnerships with Southern California ISPs. Thanks. -- Paul Vixie
Re: looking for pull traffic
Ahh, but are you saying that current blow-based transit pricing is stable? ah. no. current transit pricing is way way lower than a non-bankrupt provider can afford to do it for on an ROI that the public markets would find worthy of their praise. eventually, all kinds of flies are going to hit all kinds of windshields. but there's so much bankrupt asset in the field right now that nobody still knows how much anything really costs them to produce. so it's apparently stable for now. Maybe I am exceptionally naive, but are DDOSes *REALLY* that consistent between providers to affect month-over-month or quarterly ratios? yes. because if you're a small provider then you only need a small flow to balance yourself. and the 95th percentile cuts both ways.
Re: The Internet's Immune System
here's what i learned about a white-hat registry. nobody cares. this is perceived as an assymetric benefit, where the costs (even if there's no money, there's still effort in registering initial and new address space or AS#'s or whatever) are borne by the network owner and the benefits are felt by victims of various forms of abuse (spam, ddos, virus, whatever.) now, anyone who thinks this through will realize that the benefit is NOT assymetric. this is a tide (storm) that can lift (destroy) all boats. a network owner who deals swiftly with abuse becomes an anathema for abusers and thus has lower overall abuse costs. and a network of network-owners who all behaved that way would make abuse rare enough to be worth tracking again. however, from a marketing/perception standpoint, the benefit appears to be assymetric, and in this economy, network owners don't feel generous. so the first task isn't upgrading incidents.org or mail-abuse.org to handle white-hat network owner registration, but rather, convincing network owners that it's in their own selfish best interests to receive rapid and reliable complaints when abuse comes from/through their customer. and frankly, if that were possible, the [EMAIL PROTECTED] would not be a blackhole with robothanks at the door. so, i'm not hopeful that the internet's immune system is simply in need of better incident reporting. we need a sea change in network-owner attitudes. if you're feeling holier than thou for any reason, find out if your peering agreements require your peers to permanently disconnect repeat abuse sources, and to temporarily disconnect first time abuse sources. assuming that $YOU do these things, but that $YOUR_PEERS do not, then what have you really accomplished? -- Paul Vixie
Re: Portscans/PROXY scans
[EMAIL PROTECTED] (Andrew D Kirch) writes: There are however legitimate reasons for a portscan, responding to incoming abuse and attack being one of them, automatically searching for openrealys used to send you spam is another. Curtailing scanning shouldn't be a priority here, nailing packet kids, spammers etc should be. Sadly both of these groups don't seem to be going to jail in droves. here's the way it works out. if a network is paying attention to complaints then it will shut down wormridden customer hosts based on some combination of complaints and observations, and there will be fewer legitimate port scans which if the network notices them they'll assume they're legitimate. if however a network is not paying attention to complaints then it will very likely become alarmed by their IDS when legitimate port scans come through, and then they'll (surprise!) call and complain about it. funny assymetry. anyway, when they call, and they learn that it was a legit port scan, then they can learn of the need to shut down wormridden customer hosts. so no matter what, it's good to listen to complaints, and good to complain. -- Paul Vixie
Re: Portscans/PROXY scans
[EMAIL PROTECTED] (Suresh Ramasubramanian) writes: Portscans on the internet are a fact of life - unpleasant, yes, but you can safely ignore them, and instead, concentrate on keeping your systems secured. that is certainly what the malware authors and users hope that we'll all do, so listen up. just because many of the infected hosts won't be disinfected, don't assume that there's no value in tracking and reporting them, or that there's no reason to spend money listening to and acting on complains about them. the internet's immune system needs *more* resources, not fewer. -- Paul Vixie
Re: 'Net security gets root-level boost
BW Love this quote from Verisign: BW BW We tested Anycast for about a year...to monitor its behavior, BW Silva says. These are important servers, and we didn't want to BW make any rash decisions about deploying it. *gag* And wildcard entries? at the icann-secsac meeting in wdc on 15oct03, verisign said that they had turned the wildcard on several times, for a minute or two each time, without notice to the community, in order to ensure that there were no operational problems with it. so, apparently, testing is a way of life. (sadly for me personally, they didn't give dates or times that these tests had been run, nor did they say they would preannounce future tests, so nobody but verisign will be able to synchronize other measurements with these tests.) -- Paul Vixie
opinions on the com/net wildcard issue
my survey is over. see http://sa.vix.com/~vixie/comnetsurv/ for the results.
Re: False information: CEO of Versign facts are wrong
http://d.root-servers.org/october21.txt: 2.1. Some root name servers were unreachable from many parts of the global Internet due to congestion from the attack traffic delivered upstream/nearby. While all servers continued to answer all queries they received (due to successful overprovisioning of host resources), many valid queries were unable to reach some root name servers due to attack- related congestion effects, and thus went unanswered. While I'm not trying to act as Sclavos' apologist, I think you have to be careful about how you respond to this particular claim of his. You can't dismiss it out-of-hand. Misleading? Yes. Flat out false? You'd have to be more convincing. Can Sclavos prove that the same thing did not happen to Verisign's root servers? no. first, because it's impossible to prove a negative. second and moreso, because rob thomas and other public root server monitors showed congestion and loss toward a-root and j-root during that attack, depending on where they were coming from. that was true of all 13 server addresses, and the question is one of impact and degree, not one of 9 vs 13. but that's not even relevant. a ddos is as much an attack on its roads than on its destination. if there's a DS3 bottleneck somewhere between a querier and a responder, and if that DS3 has to carry more than ~45Mbits/second of ddos traffic due to the placement of attacking drones, then that querier is going to experience congestion and loss toward that responder. it makes no difference how much money is spent on the endpoints, there's no way to upgrade OPN's (other people's networks). that's why ultradns, and nominum before that, and several root server operators, are using anycast routing. (and even with anycast there can still be path congestion/loss, but those effects will be more isolated than without anycast.) by casting robustness in terms of investment, sclavos in his interview blurred three important points. first, that point-source investment cannot scale as well as multipoint investment -- i'm sure that more money is spent on f-root than on j-root, it's just that there are now 15 companies worldwide doing the paying, and we don't have a way to account for it. secondly, there have been many cases where less total investment in a root name server has led to higher observed robustness -- so investment isn't a direct issue. finally, sclavos described their investment in their gtld servers and then acted as if this investment had been solely for the benefit of their a-root and j-root servers, which is not the case at all. all in all a most disappointing exposition. -- Paul Vixie
Re: False information: CEO of Versign facts are wrong
oops! [EMAIL PROTECTED] (me) wrote: ... that's why ultradns, and nominum before that, and several root server operators, are using anycast routing. i meant ultradns, and nominum before they sold their dns ops biz to ultradns obviously ultradns was doing it before nominum was doing it. sorry rodney. sloppy editing. -- Paul Vixie
Re: [Fwd: [IP] VeriSign to revive redirect service]
lots of misconceptions here today. declan, you ought to pay closer attention. verisign didn't say at the meeting yesterday that they were planning to revive the redirect service, in fact they used the term if or when when describing their plans in that area. furthermore they did not commit to a notification period, they only pointed out that 60 to 90 days notice seemed reasonable if or when the service was reenabled. check the icann site for transcripts. but wait, it gets better: If everyone who attends NANOG goes to the 9:15 session on Monday morning and takes a single large tomato into the session with them, that this will make a VISIBLE sign to Verisign. no, it really won't. straton sclavos' statements about technical zealots mean that anything nanog en masse might do has been pre-label-engineered. if anything, bringing a pile of tomatos would just make his point for him, helping to convince the press that only fringe-dwelling pinko loonies have any disagreement with the sitefinder redirection effort. my advice: *don't*. wait, wait, don't tell me: To change this: what else can we do to prevent this? Does the last BIND version truly break sitefinder? in my last conversation with a verisign executive, i learned that there is a widely held misconception that the last BIND patch truly breaks sitefinder, and now here you go proving it. the last BIND patch adds a feature, whose default is OFF, that can make non-delegation data from specified domains disappear (or in other cases, non-delegation data from non-specified tld's.) let me just emphasize that the default is OFF. BIND doesn't break sitefinder; nameserver adminstrators break sitefinder. be mindful of that difference! hit D now if you're bored, because i'm still not done: ... I have got to ask just one question. Can these people at Verisign really think that they know better than all of the real experts that have worked with/on the DNS over the years. It seems rather silly to assume that a few people have more knowledge than the collective community. silly or not, they actually do believe it. verisign positions itself, both in high level discussions with government and security and financial agencies, and in its edgar filings, as being the major brain trust for DNS expertise. (otoh, exodus and abovenet both said the same thing about their BGP expertise so perhaps this is just how things go for publically traded companies.) just one more thing: While I agree that handling of NXDOMAIN needs to improve, such handling must be done by the application. Popular browsers have already started ... i think i agree with where this was going, but it would be a fine thing if we all stop calling this NXDOMAIN. the proper term is RCODE 3. when you say NXDOMAIN you sound like you've only read the BIND sources and not the RFC's. NXDOMAIN is a BINDism, whereas RCODE 3 refers to the actual protocol element. -- Paul Vixie
Re: [Fwd: [IP] VeriSign to revive redirect service]
i just got done reading http://news.com.com/2008-7347_3-5092590.html, so now at least i know why my phone was ringing so much earlier today. anyway, [EMAIL PROTECTED] (ken emery) quotes me as saying... let me just emphasize that the default is OFF. BIND doesn't break sitefinder; nameserver adminstrators break sitefinder. be mindful of that difference! and then adds: Paul, you've just bought into the Verisign propaganda here. The BIND modification does NOTHING to break Sitefinder. One can still go to http://sitefinder.verisign.com/ and use the web page without any interference from BIND. What the latest release does is to break the redirection of RCODE 3 to http://sitefinder.verisign.com/. It is just semantics, but there is a HUGE difference. ken is right and i apologize for the confusion. most of the early patches to bind8 and djbdns that i saw were dependent on the sitefinder address, and as such, would have enabled nameserver administrators to break _sitefinder_. isc's patches for bind9 enable nameserver administrators to break only the _redirection_ to sitefinder. -- Paul Vixie
i'd like to know your opinions on the com/net wildcard issue
see http://sa.vix.com/~vixie/comnetsurv/ this is not an icann thing btw, it's just me.
Re: i'd like to know your opinions on the com/net wildcard issue
see http://sa.vix.com/~vixie/comnetsurv/ An incentive to take the survey: If you fill it out, it'll tell you the aggregated results so far, which are, lemme tell you, pretty surprising. Who knew that NANOG subscribers would anonymously admit they were clueless? :-) that's just bad ui on my part. this is a two hour perl script and probably ought to allow people to fix their mistakes but that would be Hard, so no.
i'm missing my copy of why a wildcard MX won't help sitefinder
at the meeting yesterday, verisign said they were considering the benefits of a wildcard MX RR whose target was a nonexistent name, as a way to keep smtp traffic from having to come to sitefinder for rejection. i recall a very good posting on this topic and i think it was on nanog but i can't find it now. can someone privately send it to me if you've got it? -- Paul Vixie
Re: Will reverting DNS wildcard have any adverse affects?
And what possible problems are you expecting with leaving
zone com { type delegation-only; };
zone net { type delegation-only; };
in the configuration?
They should be delegation-only in any case, shouldn't they?
that was the basis of the enhanced version of the feature, which is spelled
root-delegation-only. non-delegation data in root or toplevel domains is
possibly useful (like www.$TLD) but not necessary (an NS can be put in to
achieve the same effect with an extra hop.)
well, thats up to the zone admin. :)
my concern is mostly along the lines of folks who will do things like:
zone waw.pl { type delegation-only; };
to random zones that they think -SHOULD- be delegation-only, regardless
of what the zone admin specifies.
and remember, kids, all power tools can kill.
--
Paul Vixie
Re: Will reverting DNS wildcard have any adverse affects?
Paul, I would not call root-delegation-only an enhancement. it's an enhancement in the sense that it's more complicated and it's more code and it came later in response to complaints about the earlier feature. With type delegation-only, you had to specifically name these and only these zones you wanted restricted. With the latter, you need to be alert all the time, keep an eye on all TLDs, whether they are legally using delegations. If I am not mistaken, exclude statement to this option had four revisions already. Four revisions in the first two days, none since. -- Paul Vixie
Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)
whats disturbing is how many contact addresses for both whois and AS#'s bounce sure, i agree, that's disturbing. however, it's a different problem than having mail get ignored or ignorebotted and then depref'd so low that nobody even bothers to call you or let you know whether a human ever say the message. when it's a spammer then i can understand that there might be money lost if the isp disco's them. that's evil and rude, but i understand it. when it's unwanted packet-level traffic, though, there is no revenue stream to be protected by the simple expedient of ignoring complaints -- ddos'ers do not pay for their outgo. what's happening in this case is simply that there isn't enough staff to deal with every issue that affects outside complainers. it turns out that this lack scales nicely, creating the same lack elsewhere, due to competitive pressure, general apathy toward whole classes of problems, and so forth. branding program. we need a branding program. is there still an isp consortium in existence or did they all just die like cix? we need a better netkeeping seal of approval stamp before the worseness goes through its next geometric progression.
Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)
... probably most of the Abuse issues (especially via email) would continue to be ignored. Noone wants to handle that stuff. But someone(s) must handle that stuff. the underlying question is, or else what? this is an assymetric-benefit situation. when folks ignore reports from noncustomers the people they are hurting are those noncustomers. as sean and others have pointed out, there's no incentive-stick in that equation. someone asked me privately: and why would anyone care about branding? what would it gain them? until theres financial penalties for being a bad netizen, there wont be any incentive to follow the rules. if it were a checklist item for government/military/largecommercial contracts then you can bet that the sales team in every large/medium isp would beat the drum internally to ensure qualification and compliance. given the somewhat direct relationship between insider (customer) service, outsider responsiveness, and network uptime, this isn't a hard sell. what's hard is figuring out who can host the brand and what collection of people (network owners and their customers) can be trusted to define it. i'm thinking the new NRO (joint project by apnic/lacnic/ripe/arin) might be the right place to home a responsible-network-ownership branding program.
Re: Annoying dynamic DNS updates (was Re: someone from attbi please
PS. why is this so hard? Are you talking about the kitchen sink protocol called DNS, or ... Specifically, I want to know why Comcast makes itself so hard to reach. I'll bet I could get them to talk to me about this host if it were DDoS'ing me, or if I aggressively NMAP'd it at 25Mbits/sec for 48 hours straight. But because the problem is non-serious they do not even reply to e-mail. Trouble is, it's *their* definition of serious being applied, while *I* am the one receiving this traffic. What this has in common spam is that a company wants margin from last mile transit but won't incur the reasonable and customary costs of policing their customers. They expect to get margin on 10,000,000 customers but only incur customer care costs on a 10,000 customer basis. This is what I meant in the bad old days when I called spam a form of cost shifting or conversion. Simply put, because Comcast can't be bothered, everyone else on the 'net pays their avoided costs in various indirect ways. In amusement parks there's often a sign saying you must be at least 42 inches tall to ride this roller coaster. Sadly, there is no equivilent in ISPland, and anybody who can accrete or capture customers is allowed to ride. Why is dynamic DNS update enabled by default on some operating systems? Microsoft's culpability in this mess is not even on my mind today. They will at least talk about their role in the situation, so they're more responsible than Comcast this week. -- Paul Vixie
Re: Annoying dynamic DNS updates (was Re: someone from attbi please contact me ...)
Back in beta days, the official explanation given was that the DNS updating was a value add and that it would never be disabled as a default as a courtesy to corporate customers. Furthermore, MSFT folks have repeatedly said that the workaround is to simply configure your nameserver to silently ignore the error logs. Well, I'm not going to disable that logging since it has been useful in signalling real attacks in the past. But the thing Microsoft needed to do with this was ensure that whoever is pirating my domain names on their home PCs get error message popups telling them to go to MSN and buy a real domain name. That is, they could be making money here rather than just giving my syslogd a headache. If MSFT would behave more greedily then their customer PCs would be contacting them rather than me, right? -- Paul Vixie
Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)
How should an ISP tell the difference between good DNS packets and bad DNS packets? the bad ones are the ones people complain about. You aren't complaining about your dynamic update packets or even all dynamic updates. You are complaining about someone sending you packets you don't want. And more precisely, you are complaining that Comcast is failing to send you other packets you want to receive, i.e. a response to your e-mail packets. yup. where packets i do not want could as easily be ddos (zwil) or spam. I've been thinking how to use ICMP to signal different types of responses; and even how smart edges on both ends of a communication could establish and enforce policies. Most of these are non-malicious communications involving misconfigured systems. Edge communications avoids problems with the host system, but has problems with multi-path communications and source validation. the whole end-to-end argument depends on uniform clue distribution for scale.
Re: ISPs blocking port 53? (was Re: Annoying dynamic DNS updates)
the whole end-to-end argument depends on uniform clue distribution for scale. ... Getting vendors to supply more appropriate defaults offers better scaling possibilities. Your complaint might fix one user's computer, Microsoft updating the default behaivor would fix tens of millions of users' computers. Which scales better? you've got a real mad on about software monopolies, and i guess i ought to join you since on any other day i'm just as worried. (the fact that dan geer lost his job over this issue makes it even more painful.) but in this case microsoft's culpability is toward their user, whereas the isp's culpability is toward me, so there are two culpability segments in the path, and i can't really complain to microsoft about these updates even if, as you point out, they are the ones who would find fixing it easiest, among all involved parties. How can a Windows system have a fatal error every hour for days and months, and the user not be aware of it until someone else calls them? from microsoft's point of view, the failure in that case is that they are not monetizing a condition which is very common amongst their users. MSN has the ability to sell domain names. windows has the ability to tell that a microsoft customer does not have a domain name, or does not own the one they are pretending to be in, or whatever. microsoft should not be waiting on complaints, nor should they have to feel any remorse before they fix this. the verb they should be considering is monetize. If Dynamic DNS Update is so critical that Microsoft feels the need to enable it by default, why doesn't Microsoft pop an error dialog window on the user's machine every time it fails? Then the user could decide to fix the problem, or stop doing it. If the user doesn't know there is a problem, why should he fix it? that's an excellent question, especially since it could have a click here to send microsoft more of your money button. but no matter how good an idea it is, my complaint is still that sending e-mail toward the whois contact for a network or AS# should elicit a clueful reply, and if it doesn't, then the key word we're looking for is cost shifting. (and that, in case y'all wondered, is why this is relevant to [EMAIL PROTECTED])
Re: Unauthorized DNS updates
Is there a way to configure bind so that when an **unauthorized** update comes in it enstates an address of the owner's choice? well, i'm thinking of setting up a wildcard A RR pointing at 127.255.255.255. -- Paul Vixie
Re: A list of (mostly) technical consequences of TLD wildcards
Makes me wonder why Verisign didn't use a (less harmful?) CNAME wildcard ... The CNAME algorythm in RFC1034 looks for CNAMEs before it looks for wildcards, meaning that the target of a CNAME could end up matching a wildcard, but the CNAME owner itself won't be found using the wildcarding rules. see [4.3.2]. What this means is, there is no such thing as a wildcard CNAME. -- Paul Vixie
Re: A list of (mostly) technical consequences of TLD wildcards
What this means is, there is no such thing as a wildcard CNAME. Funny... $ host -t cname \*.TD *.TD is an alias for www.nic.TD. just because bind does it doesn't make it a standard. -- Paul Vixie
someone from attbi please contact me regarding host 24.129.84.175
noc@ and abuse@ are ignoring me as usual, so i'm spamming nanog@ in hopes of locating attbi clue. i need somebody who can educate one of your customers who is dns-updating me. re: [fh:i386] grep -c 'client 24.129.84.175.*update.*denied' messages 74 [fh:i386] zgrep -c 'client 24.129.84.175.*update.*denied' messages.?.gz messages.0.gz:67 messages.1.gz:43 messages.2.gz:106 messages.3.gz:206 messages.4.gz:215 messages.5.gz:104 PS. why is this so hard?
Re: Verisign Responds
See the NANOG archives for my post reguarding wildcard caching and set comparison with additional resolver functionality for requesting if the resolver wishes to receive wildcards or NXDOMAIN. oh... that wasn't a joke, then? there won't be a protocol change of that kind, not in a million years.
Re: Verisign Responds
oh... that wasn't a joke, then? there won't be a protocol change of that kind, not in a million years. It doesn't have to be a protocol change. Strictly an implementation change. you are confused. and in any case this is off-topic. take it to namedroppers, but before you do, please read rfc's 1033, 1034, 1035, 2136, 2181, and 2317. -- Paul Vixie
Re: New CA Law
Word is Gray Davis signed [sb186]. that's most unfortunate. It seems to be a pretty strong anti-spam bill. it's not. Given all the talk of black lists and DDOS's and the like does anyone think this will make a difference? Is anyone planning on using the law to recover damages? since this law legitimizes most forms of spam while attempting to delegitimize only the kinds of spam where you can't get recourse because of untraceability, it will do far far far more harm than good. the time is now coming when actions which prevent (or actors who prevent) the forms of spam which are legitimized in sb186 may be civilly penalizable. OUCH. when i read heinlein's magic, inc. i thought there actually had to be underworld demons in political power before this kind of thing could happen, but i now see that i completely missed the point of the story. but like most threads on nanog this week, this one is offtopic. -- Paul Vixie
workaround published for BIND8 and delegation-only
so far, the BIND8 code itself has been resistant to this feature, but... see the current http://www.isc.org/products/BIND/delegation-only.html page.
Re: Verisign Responds
ISC has made root-delegation-only the default behaviour in the new bind, actually, though, we havn't, and wouldn't (ever). the feature is present but must be explicitly enabled by a knowledgeable operator to have effect. how about drafting up an RFC making it an absolute default requirement for all DNS? this is what the icann secsac recommendation... http://www.icann.org/correspondence/secsac-to-board-22sep03.htm ...says that ietf/iab should look into: We call on the IAB, the IETF, and the operational community to examine the specifications for the domain name system and consider whether additional specifications could improve the stability of the overall system. Most urgently, we ask for definitive recommendations regarding the use and operation of wildcard DNS names in TLDs and the root domain, so that actions and expectations can become universal. With respect to the broader architectural issues, we call on the technical community to clarify the role of error responses and on the separation of architectural layers, particularly and their interaction with security and stability. and it does seem rather urgent that if a wildcard in the root domain or in a top level domain is dangerous and bad, that the ietf say so out loud so that icann has a respected external reference to include in their contracts. -- Paul Vixie
Re: bind 9.2.3rc3 successful
Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. oh hell. thanks for the kind words, but we just released rc4. Are others having similar luck? What needs to be done to make this a standard feature set? Is somebody working on an RFC? i do not expect the ietf to say that root and tld zones should all be delegation-only. but good luck trying. -- Paul Vixie
Re: Verisign Responds
... We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed.
Re: bind 9.2.3rc3 successful
Now all I need is a patched version of the 9.3 snapshot tree, so I don't need to kill my dnssec stuff :P (And it's time for a non-snapshot bind version with full dnssec capabilities anyway :) if you ask that question on [EMAIL PROTECTED], i promise to answer. but i do not think details of that nature are interesting on [EMAIL PROTECTED]
Re: bind patches++ (Re: Wildcards)
Hello Paul , All , Is there a url listing the TLD's that officially use wild cards in their deployment ? nope. right now you just have to know. we're trying to keep a list of places that either use wildcards and have been accepted by the community, or don't use wildcards but run bind8 or other old broken software that incorrectly sends answers rather than referrals when queried for data held as subzone glue... see www.isc.org/products/BIND/delegation-only.html for details. ...and that's where you'll find it. it's very possible that declaring a small number of zones delegation-only will be less work and less intrusive than trying to find/list the exceptions.
Re: Verisign Responds
I wonder btw why Verisign didn't catch the typo's in their own domains if they think it is that important: ... ;; QUESTION SECTION: ;.verisign.com. IN A wildcards don't work that way. there are ns rr's in .com for verisign.com, so you get a referral to those servers no matter whether a *.com wildcard exists or not.
Re: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
[EMAIL PROTECTED] (Matthew Sullivan) writes: ... That leave 2 proxy DNSbls left - SORBS and DSBL... well, and, there's the MAPS OPL, which is also part of the RBL+. (just 'cuz i'm not operationally involved with maps doesn't mean i stopped subscribing.) -- Paul Vixie
Re: Verisign Responds
It's still to be seen if ISC's cure is worse than the disease; as instead of detecting and stoping wildcard sets, it looks for delegation. that's because wildcard (synthesized) responses do not look different on the wire, and looking for a specific A RR that can be changed every day or even loadbalanced through four /16's that may have real hosts in them seems like the wrong way forward. -- Paul Vixie
Re: When is Verisign's registry contract up for renewal
This sort of not-for-profit is exactly what I proposed when the VeriSign discussion started. A non-technical response to a non-technical problem. Since my inital email, I've recruited a few other NANOG folks and put up a website: www.alt-servers.org. what a BAD idea. worse than anything else on the table or in existence today. -- Paul Vixie
Re: When is Verisign's registry contract up for renewal
website: www.alt-servers.org. what a BAD idea. worse than anything else on the table or in existence today. Splitting the root you mean? I'm not sure there was enough info on that site to come to any other conclusion, but I wanted to make sure. this is just dns piracy, dressed up in a morality play. it won't hold.
bind patches++ (Re: Wildcards)
if you installed the first isc wildcard patch you probably want the second.
see www.isc.org/products/BIND/delegation-only.html for details. the first
patch didn't handle NS lookups (which don't occur in nature but it's sort of
unnerving when they don't work in dig).
in addition to the type delegation-only zones, the latest release candidate
has an additional root-delegation-only option. this looks like:
options {
root-delegation-only exclude { de; museum; };
};
thus the delegation-only behaviour becomes the default for the root domain,
and all tld's except those listed. DE has no wildcards but they do put
customer A RRs into the DE zone itself. MUSEUM has a wildcard but this was
part of their application and it was approved and has not been a problem.
f.6to4-servers.net is now running this if you want to try before you, um, buy.
thanks very much to the membership of the bind forum who make this possible.
--
Paul Vixie
Re: bind patches++ (Re: Wildcards)
this feature is only in the latest release candidate is 9.2.3rc3. our patches to 9.2.2 and 9.1 only support delegation-only zones. to get the root-delegation-only option you need 9.2.3rc3. see www.isc.org/products/BIND/delegation-only.html for details. re: Date: Sat, 20 Sep 2003 14:22:57 -0400 (EDT) From: Mr. James W. Laferriere [EMAIL PROTECTED] To: Paul Vixie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: bind patches++ (Re: Wildcards) Hello Paul , Am I correct in the understanding that the below tells me that 9.2.2p2 does NOT contain the ablility to do root-delegation-only ? Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | P.O. Box 854 | Give me Linux | | [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP | +--+
Re: VeriSign SMTP reject server updated
[EMAIL PROTECTED] (Matt Larson) writes: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. is it? right now there are a lot of unintended consequences and several of them are rather painful. for example, let's say you were using a friend as your backup MX and he got put on domain-hold. or in the more common case you misspell your backup mx. either way mail that should be queued and then later would have been successfully delivered will bounce at the verisign server. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. no matter what you do you're turning nonfatal error conditions into fatal ones. i'm not sure it matters which kind of fatal condition you cause, or the specific smtp messages you use to cause it. either way you're in the loop and there's no good that can come of it from an e-mail p-o-v. before we deployed root-delegation-only here, i was also annoyed that my e-mail tool could not tell me about misspelled domain names at send time and i had to wait for the wildcard mail servers to bounce the traffic. i am much happier with nxdomain than i was with the wildcard. it's just sad that i'm going to have to move vix.com to a different parent domain name to get that behaviour to work for me as a recipient and others as senders. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. i chose to send this to the list since some folks have been wondering if i'm a verisign apologist lately and i believe that open debate is better for this kind of thing. -- Paul Vixie
Re: VeriSign SMTP reject server updated
Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer? no. If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers. right.
Re: When is Verisign's registry contract up for renewal
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry. Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. [...] frankly i am mystified as to why icann awards registry contracts to for-profit entities. registrars can be for-profit, but registries should be non-profit or public-trust or whatever that specific nation's laws allow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie
Re: Appreciation for Bind patches
I have been following the various threads relating to Verisign and wanted to make one comment that I feel has been missing. Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. I'm fairly new to NANOG, but I'm sure that others beside myself also feel a thank you is appropriate. thanks for those kind words, but rapid response of this kind is one of our obligations to the bind forum, and it's only because of our members that we're able to serve the community in this way. btw: here's the short term results of me deploying root-delegation-only on my personal mail server at home: Sep 20 22:06:25 named: enforced delegation-only for 'com' (ok61930.com) Sep 20 22:06:25 named: enforced delegation-only for 'com' (ok61930.com) Sep 20 22:08:23 named: enforced delegation-only for 'com' (helimore574.com) Sep 20 22:08:23 named: enforced delegation-only for 'com' (helimore574.com) Sep 20 22:08:42 named: enforced delegation-only for 'com' (netscape1008.com) Sep 20 22:08:43 named: enforced delegation-only for 'com' (netscape1008.com) Sep 20 22:16:02 named: enforced delegation-only for 'com' (aagf91512.com) Sep 20 22:16:02 named: enforced delegation-only for 'com' (aagf91512.com) Sep 20 23:11:48 named: enforced delegation-only for 'com' (ok62928.com) Sep 20 23:11:48 named: enforced delegation-only for 'com' (ok62928.com) Sep 20 23:14:51 named: enforced delegation-only for 'com' (2mails235.com) Sep 20 23:14:51 named: enforced delegation-only for 'com' (2mails235.com) Sep 20 23:19:44 named: enforced delegation-only for 'com' (gratis-gratiss.com) Sep 20 23:19:44 named: enforced delegation-only for 'com' (gratis-gratiss.com) Sep 20 23:31:22 named: enforced delegation-only for 'com' (bosfvp.com) Sep 20 23:31:22 named: enforced delegation-only for 'com' (bosfvp.com) Sep 20 23:31:26 named: enforced delegation-only for 'com' (xvarnf.com) Sep 20 23:31:27 named: enforced delegation-only for 'com' (xvarnf.com) Sep 20 23:31:31 named: enforced delegation-only for 'com' (abdknt.com) i send this just in case anyone doubts that spammers forge sources. after the wildcard went in and before i deployed root-delegation-only at home, those would have been spams reaching my inbox. this is not much compared to a real mail server, but it is after all just my family here. (and i can assure you all that nobody typo'd the above domain names here.)
Re: Root Server Operators (Re: What *are* they smoking?)
Following Internet Standards and to improve performance for all Internet users, what if Verisign decided to start including other A records directly in the .COM/.NET zones? For example, the A records for the servers for the .COM/.NET zones? funnily enough, that would work fine, since it would be in-zone glue, and would arrive in referrals, rather than arriving in answers. the zone would still be delegation-only according to the functionality we're releasing. Or interesting sites that Verisign has a relationship with? that would not work very well for a recursive server who had declared com or net to be delegation-only. I wouldn't be surprised if tomorrow, Verisign is the playing the victim and calling ISC the out-of-control hooligans. that's doubtful. i've seen people here today advocate wet teams, null routing, patches that hard coded A RR values, cutting off uncooperative root name server operators from internet connectivity, and even writing letters to congress. isc's actions are at best a minor sideshow here. the question you should be asking yourselves is, what will aol and uSoft do? will microsoft add delegation-only features to its recursive dns implemenation? will aol or msn enable this in the recursive servers that face their customers? i guess what i'm trying to say is, the folks who are complaining about this wildcard on nanog, are not the ones verisign was probably hoping would buy stuff. these aren't the eyeballs you're looking for. the real action is occuring somewhere else entirely.
Re: Root Server Operators (Re: What *are* they smoking?)
: zone com { type delegation-only; };
: zone net { type delegation-only; };
My first reaction to this was: 'yuck'.
mine also.
I'm not sure of the side-effects this will introduce. Anyone?
if verisign served a subdomain of com or net on the same server they use
for com or net, and if they issue minimal responses (no ns rrs) then
this patch would be a barrier.
Re: Root Server Operators (Re: What *are* they smoking?)
Something like this can be seen on www.airow.com: $ dig www.airow.com @a.gtld-servers.net ... looks good to me, man. ; DiG 8.3 @f.6to4-servers.net www.airow.com a ; (2 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUERY SECTION: ;; www.airow.com, type = A, class = IN ;; ANSWER SECTION: www.airow.com. 2D IN A 66.82.206.10 ;; AUTHORITY SECTION: airow.com. 2D IN NSns1.rfwwp.com. airow.com. 2D IN NSwww.airow.com. ;; ADDITIONAL SECTION: ns1.rfwwp.com. 2D IN A 208.191.129.185 ;; Total query time: 37 msec ;; FROM: stick.isc.org to SERVER: f.6to4-servers.net 2001:4f8:0:2::14 ;; WHEN: Wed Sep 17 14:31:48 2003 ;; MSG SIZE sent: 31 rcvd: 101 After delegation-only, they will start to return 208.191.129.189. Which is probably an improvement, but a change no less. see above. So I'm unsure about ISC's approach. me too.
Re: public resolver (was: bind patch? (Re: What *are* they smoking?))
But I think your patch is working a little too well: sequoia# host nanog.org. nanog.org has address 198.108.1.50 nanog.org mail is handled (pri=0) by mail.merit.edu sequoia# host nanog.org. F.6TO4-SERVERS.NET Using domain server: Name: F.6TO4-SERVERS.NET Addresses: 2001:4f8:0:2::14 204.152.184.76 Host not found, try again. that's certainly not from the patch, since org isn't delegation-only there. Just when I thought I had a DNS server I could point my IPv6-only hosts to... that's the purpose of the f.6to4-servers.net server, and if it's not working for you then please send dig results and we'll check it out. (not host, and probably not to nanog.) -- Paul Vixie
Re: Change to .com/.net behavior
I've implemented the official ISC Bind hack on every single one of my name servers and am pushing it and the configuration changes out to my customers as a *required* upgrade. that seems a bit extreme. shouldn't they get to decide this for themselves? -- Paul Vixie
BIND 9 (Re: ISC Patches)
I know you aren't favorable to doing the work internally to ISC, but has anyone scoped out the effort involved in backporting this to BIND 8? it's under consideration now. bind8 is not a priority for the bind forum, and isc would rather put it in feature-freeze, but we're looking into it. bind9's internals make delegation-only easy to implement. bind8's internals are pretty twisty. I'm interested in that as well (BIND 9 as a recursive server on Tru64 doesn't work in my experience), works fine here. bind9 is what f-root runs, and also all of our recursive servers, some of which are tru64. try it, you'll like it. but I would suggest any discussion about that move over to the BIND list or the USENET gateway comp.protocols.dns.bind. agreed, other than to clear up the above in the same forum where it was heard. -- Paul Vixie
Re: Change to .com/.net behavior
... shouldn't they get to decide this for themselves? Returning NXDOMAIN when a domain does not exist is a basic requirement. Failure to do so creates security problems. It is reasonable to require your customers to fix known breakage that creates security problems. that sounds pretty thin. i think you stretched your reasoning too far. VeriSign has a public trust to provide accurate domain information for the COM and NET zones. They have decided to put their financial interest in obscuring this information ahead of their public trust. i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. but, given that this is in some dispute, it again seems that your customers should decide for themselves which side of the dispute they weigh in on. Microsoft, for example, specifically designed IE to behave in a particular way when an unregistered domain was entered. Verisigns wildcard record is explicitly intended to break this detection. The wildcard only works if software does not treat it as if the domain wasn't registered even though it is not. then microsoft should act. and if it matters to you then you should act. but this is not sufficient justification to warrant a demand by you of your customers that they install a patch (what if they don't run bind?) or that they configure delegation-only for particular tld's (which ones and why not others?) Verisign has created a business out of fooling software through failure to return a 'no such domain' indication when there is no such domain, in breach of their public trust. As much as Verisign was obligated not to do this, others are obligated not to propogate the breakage. ISPs operate DNS servers for their customers just as Verisign operates the COM and NET domains for the public. the obligations you're speaking of are much less clear than you're saying.
Re: Change to .com/.net behavior
How about rewriting all DNS responses to your liking? :-) Like if you ask for www.register.com, you would get the A record for www.verisign.com ? done. #fh:i386# ping -c 1 www.register.com PING www.register.com (216.21.229.101): 56 data bytes 64 bytes from 216.21.229.101: icmp_seq=0 ttl=234 time=79.703 ms --- www.register.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 79.703/79.703/79.703/0.000 ms #fh:i386# echo 65.205.249.60 www.register.com /etc/hosts #fh:i386# ping -c 1 www.register.com PING www.register.com (65.205.249.60): 56 data bytes ^C --- www.register.com ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss next? the point i'm illustrating is, as an end user, i'm in charge of my own name-address translations. Responses for the highest bidder! that would be an interesting form of symbol democracy, if it scaled to all end users. instead we have a relatively nondemocratic namespace.
Re: Change to .com/.net behavior
i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. If there's a disagreement on this concept, we have *BIGGER* problems than just DNS b0rkage. yes. i'm sorry, i thought you knew that. well, come to san diego for usenix next month and i'll tell you all about it in my invited talk there.
Re: Root Server Operators (Re: What *are* they smoking?)
i don't think so. verisign is on public record as saying that the reason they implemented the wildcard was to enhance the services offered to the internet's eyeball population, who has apparently been clamouring for this. My question is, if this was to serve some need of internet users, why does port 25 work and not port 80? i wouldn't speak for verisign on that point even if i knew the facts (which i don't) but i'm guessing that the internet today has mostly just got web browsers on it, and verisign is principally concerned with those people. So, I'm curious as to your opinion about the bigger issue. Maybe it has been stated somewhere else, and if it has, please direct me to it. I've read all of your posts about this on nanog, and you do an excellent job of staying neutral. You point out that what Verisign is doing is technically valid and therefore shouldn't be addressed with a technical solution, but you also release a patch for Bind to accomodate obvious demand (and to save users the hassle of implementing half-assed patches with hardcoded A records). However, you do so without actually stating whether or not you think the wildcards are a (policy) problem or not. let me be clear on that point, then. i've now heard some people from icann's various committees and boards say that they either were not consulted, or that they were consulted and they advised against this, and they feel rather strongly that these wildcards should not have been put in. so, there is a policy problem, which is that folks don't agree as to whether verisign is the owner or the steward for .com and .net, and folks don't agree on whose permission is needed for what. i would like to see that policy problem resolved, but i have no part in it, and i don't actually care which way it's resolved, so long as it is resolved. we all need to know whether verisign is the owner or steward, and we all need to know whose permission is needed for what, and we all need to know what to expect. resolving the policy problems will give us all those things. so, i hope that someone (else) resolves those policy problems. (if y'all need me i'll be out washing my cat.) You point out that there is high-level ambiguity about the relationship between DOC, ICANN, and Verisign, and about whether or not Verisign should have the public's interest in mind. speaking as an individual, and not as a party to policy discussions between the people who need to set and follow policies in this arena, i can say: Do you think they should have the public's interest in mind? yes. because any tld who does not do this gives ammo to the kooks who want to set up their own alternative namespace. that would be bad for the public since it would be even more chaotic than what we have now, and chaos is expensive and painful. And do you think the wildcards are in the public's interest? no. i liked it better when vix.com's parent domain (com) had no wildcard, so that if someone mistyped my domain name they got a hard dns error rather than a verisign search page or mail error. I can certainly empathize with wanting to stay neutral, but I think we need somebody who carries substantial influence in the name resolution community to have strong opinions about such a poor policy decision. i sure hope you find her (or him). good luck with that. see you all in san diego (usenix) next month, when i shall joyously lampoon all of this bitrot during my invited talk on the subject of internet governance.
Re: Root Server Operators (Re: What *are* they smoking?)
actually, i had it convincingly argued to me today that wildcards in root or top level domains were likely to be security problems, and that domains like .museum were the exception rather than the rule, and that bind's configuration should permit a knob like don't accept anything but delegations unless it's .museum or a non-root non-tld. i guess the ietf has a lot to think about now. re: Date: Wed, 17 Sep 2003 09:58:40 -0500 From: Jack Bates [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 To: Paul Vixie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Root Server Operators (Re: What *are* they smoking?) Sender: [EMAIL PROTECTED] Paul Vixie wrote: no. not just because that's not how our internal hashing works, but because hosted tld's like .museum have had wildcards from day 1 and the registrants there are perfectly comfortable with them. there's no one-policy-fits-all when it comes to tld's, so we would not want to offer a knob that tried to follow a single policy for all tld's. I agree Paul. This is a policy issue and not a technical issue. TLDs that are sponsored or setup with a specific design sometimes do and should be allowed to use the wildcard for the tld. The issue has become that net and com are public trusts and changes were made to them without authorization by the public and damage was caused as a result. Just as root server operators are subject to operating as IANA dictates, so should Verisign be subject to operating as IAB and ICANN dictate. The Internet as a whole depends on the predictability of TLDs. It is impossible to maintain a security policy based on unpredictable information. I would recommend that the TLDs which do utilize wildcards setup or restrict such use in a predictable manner. While historically it has not been an issue, such as nonexistant .museum domains being forged in email envelopes, such practices could be exploited at a later time. The ability to recognize that a domain is not registered and should not be used is paramount in basic forgery detection. One method that might be considered for recursive servers as well as resolvers, is the ability to specify if a wildcard entry will be accepted or not, perhaps at any level or just at the 2nd level. Cached records which are wildcards could be marked as such so that subsequent queries could specify desire of accepting or not accepting the wildcard entry. A web browser, for example, which supports its own redirections for NXDOMAIN, might wish to ignore the wildcard records, as would smtp servers. While I believe that net and com should never have wildcards, the ability to detect, cache, and override wildcards for tld's such as museum when the application requires it is paramount. I realize that the client software can perform the queries and detection itself, but in many cases, there wouldn't be an effecient way to cache the information without the resolver and recursive cache being aware of the process and performing such detection would require two queries versus one. -Jack
bind patch? (Re: What *are* they smoking?)
I took a look at the Bind 8.3.4 code this afternoon, but couldn't readily find where to do it. I'll take another look later. isc's patch is running internally. if anyone wants to try out our public recursive server, it's name is F.6TO4-SERVERS.NET, and it's running the patch. (we'll release it as soon as we get done with some release engineering goo.) ((no fair declaring a forward zone for com/net pointing at us, by the way.)) (Last time I tried it Bind 9 sucked up twice as much server CPU as 8.x) we run bind9 on f-root, and it's fine. you should give it another try, since it has gotten faster of late, and so have cpus/memory/motherboards. -- Paul Vixie
Re: News of ISC Developing BIND Patch
The next version of the root-servers.net hints file should not have any netSOL owned root servers in it. That will make the transition easier. excuse me for the harsh language, but that's just silly. verisign's root name servers (a-root and j-root) are professionally run by some of the best dns techs in the industry. nothing that's happening with dot-com or dot-net should be considered relevant to verisign's *root* servers in any way. the *root* servers do not carry dot-com or dot-net, they just carry . itself, and arpa, and in-addr.arpa, and in some cases root-servers.net. -- Paul Vixie
Re: Root Server Operators (Re: What *are* they smoking?)
[dot-net, dot-com] is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file. that's nonsequitur. root server operators do not carry the dot-com or dot-net zone files. therefore there will never be an opportunity to refuse (or accept) it. root server operators (see www.root-servers.org for details) include verisign as one of 11 organzations worldwide. the dot-com and dot-net zones, by comparison, are only served by verisign's own servers, and i do not think that verisign will refuse to accept them. -- Paul Vixie
Re: Not the best solution, but it takes VeriSign out of the loop
Who's up for creating a network of new gTLD servers? This would require cooperation from the root-servers operators. speaking for f-root, we won't be cooperating with anything like that. we do not edit the zone files we serve. they come from iana, and if you want something different served, you'll have to talk to iana. i cannot speak for the other rootops but i suspect that their answers might be compatible with, if not downright similar to, f-root's. And a serious effort from ISP/NSP community to block network access to root-servers that don't cooperate. I agree that it's a good idea at this point. I see nothing else as a serious long-term technical solution. sounds like mob rule to me -- count me out. so, block me first, i guess? -- Paul Vixie
Re: Root Server Operators (Re: What *are* they smoking?)
Anyone have a magic named.conf incantation to counter the verisign
braindamage?
zone com { type delegation-only; };
zone net { type delegation-only; };
Or does this require a patch to bind?
yes, it does. to be released shortly.
--
Paul Vixie
Re: News of ISC Developing BIND Patch
I trust your assessment of the DNS techs. But what about [their] bosses? the ones i've met in recent years seemed like reasonable people. They ordered some pretty lumpy things be done with .com and .net. Given that track record, whats to stop them from ordering [the techs] from doing something equally lumpy. root zone content is tied up in all kinds of red tape. the root server operators won't modify it in any way; we publish only what we get from iana. iana and verisign and the united states department of commerce all have to agree on changes to it. imagine a mexican standoff with three people and six guns. with the ietf/iab as referee and scorekeeper, and the rootops as an interested audience. (entertain me!) i'll say it again. nothing that happens in dot-com or dot-net has any relevance at all to the root zone, or to the root server operators.
Re: Root Server Operators (Re: What *are* they smoking?)
Can you also program something to do this for all root zones,
i.e. something like 'zone .* { type deligation-only; };'
no. not just because that's not how our internal hashing works, but
because hosted tld's like .museum have had wildcards from day 1 and
the registrants there are perfectly comfortable with them. there's
no one-policy-fits-all when it comes to tld's, so we would not want
to offer a knob that tried to follow a single policy for all tld's.
And make it default configuration for new bind releases...
never. not for your example, nor for any set of tld's. the default for
bind will be what it's always been -- to respect the autonomy of the
zone administrator/publisher. overriding that autonomy has to be a
local act by a local name server administrator who is fully conscious of
the impact of their configuration change. once, with check-names, isc
was accused of legislating from the bench. never again.
Re: Root Server Operators (Re: What *are* they smoking?)
So, Verisign just returns a NS pointer to another name server Verisign controls which then answers the queries with Verisign's helpful web site. Half-life of the patch: 1 day? i don't think so. verisign is on public record as saying that the reason they implemented the wildcard was to enhance the services offered to the internet's eyeball population, who has apparently been clamouring for this. in this story, for example... http://story.news.yahoo.com/news?tmpl=storyu=/ap/20030916/ap_on_hi_te/internet_typos_4 ...it was thus spake: VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual service providers were free to configure their systems so customers would bypass Site Finder. But he questioned whether releasing a patch to do so would violate Internet standards. Vixie acknowledged that it could -- standards call for operators like VeriSign to have complete control over their directories -- but he said not releasing a patch would create greater chaos. therefore i believe that while they may have to change the A RR from time to time according to their transit contracts, verisign won't insert an NS RR into the sitefinder redirection. if they do, and if bind's user community still wants to avoid sitefinder, they can declare the second server bogus, with no new code changes from isc. but that all seems terribly unlikely.
Re: What were we saying about edge filtering?
(i know i said i wouldn't comment on this, but that was yesterday.) At the edge, very near the originating host there is no reason not to filter these, if you find the sources you might consider asking them why they didn't filter these for you... i've asked. answers are usually of the form huh? what's that? unless it's a relatively smart person with the misfortune to be working at a bankrupt backbone with short staff and no equipment budget in which case the answer is some variation of well that's fine at the edge but not in the core. in fact, see above :-). And what is the reason to not filter these in the backbone? Full spoof protection at some levels is near impossible. However, bogon filtering is not. loose-rpf is a start. none of the packets shown below came to me from a peer or transit who runs loose-rpf in their backbone. however, loose-rpf only solves a small part of the source address ambiguity problem, since the niks can still source their zwil from (other people's) routed cidr blocks. with respect to the trace below, this is one f-root out of about 25, and while we normally have to sanitize the source addresses of our traces before we make them public, as you can see it's really not nec'y for this one: #sfo2a.f:i386# tcpdump -n src net \( 10 or 172.16/12 or 192.168/16 \) tcpdump: listening on fxp0 16:34:44.982330 172.20.1.1.3436 192.5.5.241.53: 4072[|domain] 16:34:45.027735 172.16.1.13.53 192.5.5.241.53: 21659 A? updatekeepalive.mcafee.com. (44) 16:34:45.053542 10.10.220.10.32769 192.5.5.241.53: 52143 NS? . (17) (DF) 16:34:45.084594 10.23.1.40.1024 192.5.5.241.53: 7932 NS? . (17) 16:34:45.832620 192.168.0.2.1133 192.5.5.241.53: 8690 A? g-images.amazon.com. (37) 16:34:45.837360 192.168.0.2.1133 192.5.5.241.53: 12795 A? g-images.amazon.com. (37) 16:34:45.841734 192.168.0.2.1133 192.5.5.241.53: 512 A? g-images.amazon.com. (37) 16:34:45.846085 192.168.0.2.1133 192.5.5.241.53: 6665 A? g-images.amazon.com. (37) 16:34:45.850969 192.168.0.2.1133 192.5.5.241.53: 12820 A? g-images.amazon.com. (37) 16:34:45.871451 192.168.0.63.1105 192.5.5.241.53: 84 PTR? 8.0.168.192.in-addr.arpa. (42) 16:34:45.924779 10.2.3.39.1030 192.5.5.241.53: 57 A? www.symantec.com. (34) 16:34:45.926582 10.2.3.39.1030 192.5.5.241.53: 6208 A? time-a.timefreq.bldrdoc.gov. (45) 16:34:45.931745 10.2.3.39.1030 192.5.5.241.53: 12361 A? time-a.timefreq.bldrdoc.gov. (45) 16:34:46.096376 192.168.1.113.32830 192.5.5.241.53: 18162 [1au] MX? networkoptservices.net. OPT UDPsize=4096 (51) (DF) 16:34:46.098370 192.168.1.113.32830 192.5.5.241.53: 9520 MX? activision.info. (33) (DF) 16:34:46.801114 172.30.60.229.53 192.5.5.241.53: 1400 SOA? 150.118.162.in-addr.arpa. (42) 16:34:46.828786 192.168.104.10.1097 192.5.5.241.53: 1290 A? images.daemon.sh. (34) 16:34:46.830733 192.168.104.10.1097 192.5.5.241.53: 11542 A? images.daemon.sh. (34) 16:34:46.832704 192.168.104.10.1097 192.5.5.241.53: 1305 A? images.daemon.sh. (34) 16:34:46.833516 192.168.104.10.1097 192.5.5.241.53: 13600 A? images.daemon.sh. (34) 16:34:46.834898 192.168.0.2.1133 192.5.5.241.53: 10777 A? g-images.amazon.com. (37) 16:34:46.834905 192.168.104.10.1097 192.5.5.241.53: 15659 A? images.daemon.sh. (34) 16:34:46.839097 192.168.0.2.1133 192.5.5.241.53: 544 A? g-images.amazon.com. (37) 16:34:46.843399 192.168.0.2.1133 192.5.5.241.53: 552 A? g-images.amazon.com. (37) 16:34:46.848108 192.168.0.2.1133 192.5.5.241.53: 14902 A? g-images.amazon.com. (37) 16:34:46.853027 192.168.0.2.1133 192.5.5.241.53: 6718 A? g-images.amazon.com. (37) 16:34:46.898737 192.168.203.7. 192.5.5.241.53: 3150 A? microsoft.com.mailwell.com. (44) 16:34:46.900221 192.168.203.7. 192.5.5.241.53: 5206 A? microsoft.com.mailwell.com. (44) 16:34:46.926334 10.2.3.39.1030 192.5.5.241.53: 4182 A? www.symantec.com. (34) 16:34:46.926721 10.2.3.39.1030 192.5.5.241.53: 2143 A? www.symantec.com. (34) 16:34:47.018181 192.168.100.24.1102 192.5.5.241.53: 16356 A? sbasupport. (28) 16:34:47.828700 192.168.104.10.1097 192.5.5.241.53: 15668 A? rsthost1.ods.org. (34) 16:34:47.829026 192.168.104.10.1097 192.5.5.241.53: 5439 A? rsthost1.ods.org. (34) 16:34:47.892288 10.81.0.22.1069 192.5.5.241.53: 6014 SOA? 0.81.10.in-addr.arpa. (38) 16:34:47.905254 192.168.128.4.53 192.5.5.241.53: 614 PTR? 30.128.168.192.in-addr.arpa. (45) 16:34:47.919143 10.1.0.3.53 192.5.5.241.53: 26579 A? www.symantec.com. (34) 16:34:47.926353 10.2.3.39.1030 192.5.5.241.53: 12388 SOA? 12.2.10.in-addr.arpa. (38) 16:34:47.981405 172.20.1.1.3436 192.5.5.241.53: 8189[|domain] ^C 3205 packets received by filter 0 packets dropped by kernel -- Paul Vixie
Re: On the back of other 'security' posts....
Ok, so we seem to have a general agreement that anti-spoof BGP prefix filtering on all standard customer edge links is a worthwhile practice. actually, we don't. what we've achieved is that gray area / middle ground where the people who don't think it's important are mostly afraid to speak out against it. while this is an important milestone, it's not nearly the same as general agreement. Now what? Is there any hope of this ever happening on a very large scale without somehow being mandated? (Not that it necessarily should be mandated.) there is no way to mandate it. even if it were somehow a full standard in the ietf, network owners who didn't want to do it wouldn't have to do it. How much success have Barry Green and co. had? Is there something the rest of us could be doing? i'm thinking we may need some kind of branding campaign, so that rfp authors can refer to a set of good practices like terminating spammers, not writing pink contracts, not hosting spamvertised web sites, publishing in the radb, filtering customer routes by rir, running full uprf on customer-facing links, and so on down the line. i'm not sure that we (isc) would be the best people to run an isp branding/certification programme, so i'm hoping someone else steps up, like maybe the rirs or isp/c or maps or whatever. but once the sales people inside isp's have to contend with this as a checklist item in incoming rfp's, it'll see fast deployment even in bankrupt high-inertia backbone networks like uunet. -- Paul Vixie
Re: On the back of other 'security' posts....
... That depends on your definition of edge, I suppose. ... in SAC 004 (http://www.icann.org/committees/security/sac004.txt) we see: 1 - Connection Taxonomy 1.1. The Internet is a network of networks, where the component networks are called Autonomous Systems (AS), each having a unique AS Number (ASN). 1.2. Connections inside an AS are called Interior (or sometimes backbone), and their security policies are set according to local needs, usually based on business or technical requirements. 1.3. Connections between ASs are called Border (or sometimes peering), and their security policies are set bilaterally according to the joint needs of the interconnecting parties. 1.4. Connections between an AS and its traffic sources (generators) and traffic sinks (consumers) are called Edge (or sometimes customer), and their security policies are generally, by long standing tradition, inconsistent. the rest of the paper is also germane to this thread. just fya, we keep rehashing the UNimportant part of this argument, and never progressing. (from this, i deduce that we must be humans.) -- Paul Vixie
Re: What do you want your ISP to block today?
... Micr0$0ft's level of engineered-in vulnerabilities and wanton disregard for security in the name of features. ... i can't see it. i know folks who write code at microsoft and they worry as much about security bugs as people who work at other places or who do software as a hobby. the problem microsoft has with software quality that they have no competition, and their marketing people know that ship dates will drive total dollar volume regardless of quality. (when you have competition, you have to worry about quality; when you don't, you don't.) -- Paul Vixie
Re: On the back of other 'security' posts....
[EMAIL PROTECTED] (Matthew Sullivan) writes: ..and if the perps are on this list, keep going if you want, the more you do the more likely you'll get caught. You will not force SORBS off the net like you have Osirusoft. I and SORBS will leave when we are good and ready, and not because of some infantile spotty faced 15 year old nerd without a clue on life. these aren't script kiddies, in fact i don't think they're kids. these seem to be professional spammers whose revenue is being hurt by sorbs. the kids i've talked to think that the blackhole lists are good things, since these kids are usually spam victims and almost never spam perps. -- Paul Vixie
Re: Fun new policy at AOL
But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. a fine idea. thank jim miller for it if you see him. For AOL and the likes this would also help against spam as they can rate limit incoming mail from unknown domains. Spammers are forced to register new domains all the time in addition to having to find abusable IP addresses so hopefully life for them will be a little more miserable too. (Could reuse MX for this if a new RR is too much hassle, but large ISPs don't use the same SMTP servers for incoming as for outgoing.) see below. IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition this e-mail came from where it says it came from. 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to reject all e-mail claiming to be from HOTMAIL.COM since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form use PGP and use SSL are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid (wanted) e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in we can be sure that this did not come from where it claims and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is MAIL-FROM, whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from [EMAIL PROTECTED], the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4 So, the inbound mail server set partially overlaps with, but differs from, the example outbound mail server set. This is quite common in the Internet, and is the reason why the normal inbound mail server set described by a domain's apex MX RRset cannot
Re: GLBX ICMP rate limiting (was RE: Tier-1 without their own backbone?)
Along these lines, how does this limiting affect akamai or other 'ping for distance' type localization services? I'd think their data would get somewhat skewed, right? using icmp to predict tcp performance has always been a silly idea; it doesn't take any icmp rate limit policy changes to make it silly. other silly ways to try to predict tcp performance include aspath length comparisons, stupid dns tricks, or geographic distance comparisons. the only reliable way to know what tcp will do is execute it. not just the syn/synack as in some blast protocols i know of, but the whole session. and the predictive value of the information you'll gain from this decays rather quickly unless you have a lot of it for trending/aggregation. gee, ping was faster to A but tcp was faster to B, do you s'pose there could be a satellite link, or a 9600 baud modem, in the system somewhere? -- Paul Vixie
Re: Fw: GLBX ICMP rate limiting (was RE: Tier-1 without their own backbone?)
As attacks evolve and transform are we really to believe that rate limiting icmp will have some value in the attacks of tomorrow? no. nor those of today. the only way we're going to flatten the increase of attack volume, or even turn it into a decrease, is with various forms of admission control which are considered the greater evil by a lot of the half baked civil libertarians who inhabit the internet at layer 9. for example, edge urpf. for example, full realtime multinoc issue tracking. for example, route filtering based on rir allocations. for example, peering agreements that require active intermediation when downstreams misbehave. you can have peace. or you can have freedom. don't ever count on having both at once. -LL (RAH) -- Paul Vixie
Re: Fun new policy at AOL
Play with DNS MX records like QMTP does. Something like crocker.com. MX 65000 trusted-mx.crocker.com. MX 66000 untrusted-mx.crocker.com. there are at least two problems with this approach. one is that an mx priority is a 16 bit unsigned integer, not like your example. another is that spammers do not follow the MX protocol, they deliberately dump on higher cost relays in order to make the victim's own inbounds carry more of the total workload of delivery. (additionally, many hosts do more spam filtering on their lower cost MX's than on their higher cost (backup?) MX's, and the spammers know this, and take advantage of it.) -- Paul Vixie
Re: Fun new policy at AOL
I think the inherent mantra and wise philosophy that gets tossed out the window by AOL in this policy change is be strict in what you send, and liberal in what you accept. that policy was wiser when everyone who could get an internet connection saw the merits of it. in an assymetric warfare situation where the good guys follow the above policy and the bad guys do not, it's a slaughter. -- Paul Vixie
Re: Fun new policy at AOL
That's why we must encourage all ISPSs to be good guys, because we don't want Government Regulators setting standards in these areas, do we? if recent activity in the VoIP market is any indication, then we here won't have much input as to when and how the ISP market gets regulated. -- Paul Vixie
Re: Re[2]: relays.osirusoft.com
ok so this part does not mystify me... Someone has been in contact with Joe via phone and posted to another mailing list That Zhall Not Be Named that exactly that is happening. The zone is dead, ... ...because running blackhole lists is surprisingly more hard than most people think. (witness the sorbs.net message here a few hours ago complaining of 50Kpkt/day query loads.) i've paid some dues in this area, so i feel qualified to say that i told you so on this topic. but at least there's no mystery. this part, on the other hand... he's put *.*.*.* in, he's asking people not to use it anymore. ...mystifies me. anyone who has read rfc1034 or rfc1035, even if they did not also read rfc2181 or rfc2136 or rfc2308, knows that in a zone containing the following wildcardish data: $ORIGIN example.vix.com. * 1H IN A 127.0.0.1 *.* 1H IN A 127.0.0.2 *.*.* 1H IN A 127.0.0.3 *.*.*.* 1H IN A 127.0.0.4 the result will be that only the top one will match: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 16926 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUERY SECTION: ;; 40.30.20.10.example.vix.com, type = A, class = IN ;; ANSWER SECTION: 40.30.20.10.example.vix.com. 1H IN A 127.0.0.1 and that in a zone containing only this data: $ORIGIN example.vix.com. *.*.*.* 1H IN A 127.0.0.4 the result will be that none of them ever match: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 44811 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 40.30.20.10.example.vix.com, type = A, class = IN you don't even need to read draft-ietf-dnsext-wcard-clarify-01.txt to know that putting *.*.*.* into a zone won't actually mean, or do, *anything*. It may be back in the future with a new network setup, but right now consider it down. i'm not completely sure, but i don't think this list will see much action in the future from the sysadmins who had to make emergency config changes today to avoid bouncing all their e-mail. once burned, twice shy, eh? when i deprecated the old $foo.maps.vix.com zones in favour of the their corresponding replacements $bar.mail-abuse.org some years ago, i had the foresight to ensure that no mail would be blocked by people who failed to put in the configuration change. now you can all see why that was nec'y. -- Paul Vixie
Re: relays.osirusoft.com
Someone has suggested 'anycasting' what do people (particually you Paul) think of using anycasting for a DNSbl? (- AS112 anyone?) unowned anycast, such as that used in as112, is only possible when the replies have no value (and thus need not be synchronized or centrally authorized.) conversely, unowned anycast only adds value if the replies really ought to be sent anonymously. in the case of sorbs, you can enumerate authorized servers and thus get better management and control than you would with unowned anycast. now, that doesn't mean anycast per se is a bad idea for sorbs. it's just that you'd want to own or at least manage and control each instance. this is what we do for f-root and it's what ultradns and nominum and i think akamai have been doing for some years now. I think it may work well... however I am a novice in terms of BGP... As far as I can tell it involves getting a portable address block (somone suggested anything less than a /24 would get filtered) and announcing it in various locations around the Net with local servers behind each of those announcements is this fundamentally correct? yes. see http://www.isc.org/tn/ for some background materials on all this. Assuming I am right in my current understanding, I am about to start looking at the proceedure to get an ASN and then I'll be looking for some portable IP space if the consensus and thoughts are this will work. I am thinking along the lines of talking with the other large DNSbls (particually Easynet (wirehub) and DSBL) about setting up a set of combined DNSbl servers all anycast'd. This after all will bring an DDoS machines to the attention of the local networks they are attacking ;-) putting multiple dnsbl's on the same /24 sounds like a lot of eggs for only one basket. among the root server operators, we like to chant that diversity is good.
Re: XO as Backbone provider - try again
[EMAIL PROTECTED] (Bil Herd) writes: Anyone have positive or negative experiences with XO as a 'tier1' provider? We are re-evaluating orur backbone connections. xo seems to have pretty good splay and we've seen no congestion or instability. -- Paul Vixie
anybody know the owner of 209.251.0.0/19?
i'm getting spammed from there...
[sa:i386] ./find-spam.pl 209.251.0.0/19
SELECT HOST(s.relay) AS relay, s.entered, s.md5, s.body_md5,
LENGTH(s.header)+LENGTH(b.body)+1 AS size, s.header
FROM spam s LEFT JOIN bodies b ON s.body_md5 = b.md5
WHERE relay = '209.251.0.0/19'
ORDER BY entered
LIMIT ALL
spam: [002515 2001-12-09 23:37:37+00 209.251.20.7]
lart: {12370209.251.20.7 source mailer}
mail: (0 007557 )
spam: [005626 2003-07-31 22:14:54.367173+00 209.251.28.142]
lart: {316925 209.251.28.142 source mailer}
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
spam: [001260 2003-08-13 14:28:06.363234+00 209.251.28.142]
lart: {332664 209.251.28.142 relay mailer}
mail: (0 002207 [EMAIL PROTECTED])
...but there is no whois...
[sa:i386] whois -h whois.arin.net 209.251.28.142
No match found for 209.251.28.142.
# ARIN WHOIS database, last updated 2003-08-18 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.
...and they seem to have transit through both AS209 and AS6076...
[EMAIL PROTECTED] show route 209.251.28.142
...
209.251.0.0/19 *[BGP/170] 2w3d 23:55:24, MED 2147483647, localpref 100
AS path: 209 11036 I
to 198.32.176.52 via ge-2/1/0.6
[BGP/170] 1w2d 10:47:58, MED 2147483647, localpref 100
AS path: 3549 8011 6076 11036 I
to 208.50.13.57 via ge-1/3/0.501
[BGP/170] 2w3d 23:55:12, MED 10, localpref 90
AS path: 2914 209 11036 I
to 129.250.16.157 via so-1/2/2.0
[BGP/170] 1w4d 16:20:31, MED 10, localpref 90
AS path: 701 209 11036 I
to 198.32.176.2 via ge-2/1/0.6
[BGP/170] 04:33:44, MED 10, localpref 90
AS path: 6453 209 11036 I
to 207.45.196.65 via so-1/2/0.0
...although both AS11036 (the origin) and AS6076 (one of the transits) are
in the same geo area, one of them (voyager.net) was i thought out of business.
am i being spammed from pirated address space?
Re: AOL breaking dns spoof protection
[EMAIL PROTECTED] (Petri Helenius) writes: I´m constantly seeing responses to queries for AOL servers which come in from different IP addresses than the query was sent to. due to the weakness of the 16-bit query id field, bind will throw that stuff away. the source address and port has to match the destination of the query, and the question section has to be copied in its entirety. i don't know who aol is going to be able to send responses to who won't apply those same restrictions.
Re: WANTED: ISPs with DDoS defense solutions
More and more there is less and less spoofing, its just not required and it causes more damage with less effort :( Why spoof when you have 1000 machines pumping 1 packet per second? (or 10) leaving the spoofing option open for future generations of attacks, rather than having a witch-hunt and tracking down and upgrading every insecure edge, is just about the worst thing we could do. because when an attacker wants an extra edge, they'll add spoofing to their attack profile, and the core's immune system will be totally unprepared. knowing this, and knowing that spoofing isn't actually necessary right now, the current generation of attackers would be well advised to stop spoofing for a while so that nobody makes any serious attempt to plug the hole. (and, it sounds like that strategy might already be working.) could someone here who can write win32 apps, and someone else who can write cocoa apps, please volunteer short executables that will try to spoof a few packets through some well known server, and then report as to whether the current computer/firewall/cablemodem/isp/core permitted this or not? isc would be happy to host the server component of this, as long as source code for the executables is available under a bsd style copyright, and the executables are released without any fee. this is so the community can gather compelling evidence for the witch-hunt. (i expect we'd have to come up with a web button campaign to brand isp's who dtrt. sort of like the old squid-era cache now! thing.) -- Paul Vixie
Re: Server Redundancy
[EMAIL PROTECTED] (Jason Robertson) writes: If you go out and spend a few thousand you can also get Allied Telesyn L2-L4 products that now support Load Balancing. Actually the rapier 24i is about $2000 Canadian. (I'd have to check the VAR pricing) how much would i have to pay to not have that extra powered box between my data and my customers? oh, i forgot, it's zero, isn't it? re: Using outboard appliances for server load balancing is unnecessary, and it adds more powered boxes (thus decreasing theoretical reliability). If your upstream router can speak OSPF and is made by either Cisco or Juniper then it will implement ECMP (equal cost multipath). If you put your service address on lo0 as an alias, and you run Zebra or GateD on the service hosts which possess that alias address, then each such host will appear to be a router toward the service address as a stub host and your upstream routers will dtrt wrt flow hashing for udp or tcp traffic (that is, the udp/tcp port number will figure into the hash function, so you won't multipath your tcp sessions.) This is how f-root has worked for years. Look ma, no appliances. -- Paul Vixie
Re: Electrical Engineering Firm Recommendation
[EMAIL PROTECTED] (Dan Lockwood) writes: To clarify, i'm looking for electrical and control system engineering. Thanks! -Original Message- Can someone recommend an electrical engineering firm in the middle to north part of California that has experience with NOC design? See http://www.rls.com/. Randy Sparks and Associates, in San Francisco. -- Paul Vixie
Re: WANTED: ISPs with DDoS defense solutions
I don't believe I ever said that the edges shouldn't filter... did I? nope. but you said that backbones couldn't/wouldn't/shouldn't, and i showed that transitivity = laundering, which means backbones MUST filter, to within the best capabilities of current technology.
Re: WANTED: ISPs with DDoS defense solutions
How would the spoofing program, or its user, be able to tell if it was successful? Unless I'm very confused, the definition of spoofing is that the return packets aren't going to come back to you. the whole thing would have to take place during a tcp control session which used d-h to scramble itself, sort of the same way ssh does. the random address/addresses would be chosen by the server. the only info the initiator would gain is a count of how many spoofed packets made it in; this could be left out if we feared that bad people would profit from being able to use this tester. (we don't, though, since they have their own ways of knowing whether spoofing is working from a given source, and we don't think they'd want us to know what sources they were testing.) I can imagine a packet format where the real source address was in the data, but with no authentication this would itself be subject to abuse. ... Doing this from behind a NAT would be difficult. one hopes that a nat box would also complicate the lives of spoofers.
Re: Server Redundancy
Using outboard appliances for server load balancing is unnecessary, and it adds more powered boxes (thus decreasing theoretical reliability). If your upstream router can speak OSPF and is made by either Cisco or Juniper then it will implement ECMP (equal cost multipath). If you put your service address on lo0 as an alias, and you run Zebra or GateD on the service hosts which possess that alias address, then each such host will appear to be a router toward the service address as a stub host and your upstream routers will dtrt wrt flow hashing for udp or tcp traffic (that is, the udp/tcp port number will figure into the hash function, so you won't multipath your tcp sessions.) This is how f-root has worked for years. Look ma, no appliances. -- Paul Vixie
Re: WANTED: ISPs with DDoS defense solutions
[EMAIL PROTECTED] (Christopher L. Morrow) writes: There are many cases in which the backbone can't determine the 'proper' traffic an edge is sending in. i'd like to discuss these, or see them discussed. networks have edges, even if some networks are edge networks and some are backbone networks. bcp38 talks about various kinds of loose rpf, for example not accepting a source for which there's no corresponding nondefault route. Not to mention the problems of filtering on an edge device with 100's or 1000's of interfaces. The proper and simple place for this filtering is as close to the end device as possible. Backbones just aren't made to filter traffic, edge networks are. so, the problem is transitive. you might have a multihomed customer whose network spans some of the same peerography as yours, and if you both use hot potato there will be path assymetry, such that your route back to a source might be through pop A while they deliver that source's traffic to you at pop B. your only recourse is to get them to filter at their edge, which you hope is less ambiguous than yours. but they might have the same situation with their downstream. and you're not requiring them to do edge filtering as a contract/peering term, nor are you requiring them to require their downstreams to do so. this means the problem goes from transitive to laundered in about one AS hop or so. i don't consider this a healthy situation, and i'd like to hear you list the kinds of rpf you know of and why none can be used on a backbone. -- Paul Vixie
Re: Complaint of the week: Ebay abuse mail (slightly OT)
[EMAIL PROTECTED] writes: And so we should do nothing? of course not. but the first thing to do is ignore naysayers. anybody who tells you something can't be done should be suspected of extreme and pervasive laziness until either they or you prove otherwise. -- Paul Vixie
Re: Complaint of the week: Ebay abuse mail (slightly OT)
... ebay now requires that you fill in their lovely little web form to send them a note. Even if, say, you're trying to let them know about another scam going around that tries to use the machine www.hnstech.co.kr to extract people's credit card information. one can easily imagine that their abuse@ alias was receiving so much spam that it was too costly to read it all and fish out the valid complaints. (this is a ~recent spammer tactic, clogging the metadata paths to make it harder for network owners to discuss spammer activities.) however, the real reason is likely to be lack of uniformity in complaints. among the population who complains to abuse@, there isn't a single definition of spam or abuse or hack or scam or what have you. a complaint that is about a credit card scam is only differentiable from a complaint that is about a spamvertised web site after a fairly expensive human has seen both and made a determination. at ebay's transaction volume i'm sure that the aggregate costs of those humans was looking pretty large. so it was for all the other companies who have tried to manage their abuse costs by making people go to web sites. most of these companies were not as financially successful as ebay, though, and the unwillingness of the public to fire up a web browser in order to give the valuable gift of feedback about customer activity turned into a larger cost than the one they were avoiding. ebay is a different animal, and i'll take bets that the potential complainants who send enough abuse complaints overall that they have to prefer e-mail and say no to web forms, is not even part of their target audience. that means they don't care if you stop using their service, or blackhole all mail from them, or whatever you have to do to protect yourself from their other customers... because they will still have tens of millions of other customers who don't send abuse complaints or who are willing to deal with web forms. this sounds like i'm defending them. i'm not. but while reprehensible and irresponsible and socially radical, the web form approach's only real cause for failure is when the lack of a useful feedback channel curtails complaints which the network owner would find valuable. that's just not provably true in the case of ebay. we all knew that profitable large network owners would change the landscape compared to merely ebitda-positive large network owners, and here's an example of how big company cost management practices can go up against reasonable and customary internet behaviour and pretty much ignore it. this won't be a case where taking your complaint to the peering/backbone folks can result in a policy change, either. to get the attention of the people who make this kind of decision in a company like ebay, you'd have to go to the better business bureau, or congress. good luck storming the castle, boys. -- Paul Vixie
Re: WANTED: ISPs with DDoS defense solutions
1) The OS/software/default settings for a lot of internet connected machines are weak, making it easy to attack from multiple locations. I´ll start looking for this to happen when Microsoft manages to release an OS version which does not contain remote exploitable flaw before the boxes hit the store self. lots of late night pondering tonight. the anti-nat anti-firewall pure-end-to-end crowd has always argued in favour of every host for itself but in a world with a hundred million unmanaged but reprogrammable devices is that really practical? if *all* dsl and cablemodem plants firewalled inbound SYN packets and/or only permitted inbound UDP in direct response to prior valid outbound UDP, would rob really have seen a ~140Khost botnet this year? -- Paul Vixie
Re: WANTED: ISPs with DDoS defense solutions
However, since improvements are always welcome, please recommend tools which would allow us to progress above and beyond C and it's deficencies. I've never been able to program a buffer overrun vulnerability in Modula 3, or Perl, or any version of Lisp or Scheme. It's possible that the physics has advanced enough that low level programming now costs more than it saves.
Re: WANTED: ISPs with DDoS defense solutions
Private deployment of software written in C is very different from a major public release, especially so when included with source code. you're right. when i've been involved in non-opensource products which were written in C and then shipped as binaries, i was scared to death about the lack of public review relative to the size of the user base, and i always argued for rather expen$ive SQA to make up for the weakness of not getting free SQA from all those security companies looking to make a name for themselves by being first to discover a vulnerability. or was that not what you meant?
Re: Is there a technical solution to SPAM?
Spammers are like roaches. They are here to stay. They are aggressive. They adapt. spam is a drug, and spammers will do anything, anything at all, for a fix. We need to respond with a variety of mechanisms, preferably coordinated to maximize the aggregate effect. i still disagree. we need to call smtp a total loss and start over, from the basic question: how can mutual consent be prerequisite to communication? the difference between spam and ddos is a matter of statefulness -- but the motives for sending it are essentially the same: asymmetric benefit to the sender, and without consent of the recipients. watching the growth of the anti-ddos and anti-spam industries makes the internet look like a grade school science fair project run amok. -- Paul Vixie
