September 2003 - Test - lists.nanog.org

Fwd: Re: Patching BIND (Re: What *are* they smoking?)
by Mark Vevers 16 Sep '03

16 Sep '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 16 Sep 2003 6:41 am, John Brown wrote: > we've burned a AS for this, ICK Yup - and 2 /24's .... #show ip bgp regexp _30060$ Network Next Hop Metric LocPrf Weight Path *>i12.158.80.0/24 xxx.xxx.xxx.xxx 305 100 0 1239 7018 26134 30060 ? *>i64.94.110.0/24 xxx.xxx.xxx.xxx 305 100 0 1239 7018 26134 30060 ? > based on the ASNAME, its seems a nice little route-map > /dev/null will be real easy. As long as they keep prefixs > used in this really dumb idea for this idea. If you have a full table (i.e. no default) just drop inbound routes with a AS path _30060$ Also .... <user>@dns0:/var/named/verisignwildcard#host 64.94.110.11 Host 11.110.94.64.in-addr.arpa not found: 3(NXDOMAIN) Oh dear, I wonder what happened to the reverse ..... looks like that doesn't resolve any more from here ;-) ... so we can still do reverse DNS checks.... Mark - -- Mark Vevers. mark(a)ifl.net / mark(a)vevers.net Principal Internet Engineer, Internet for Learning, Research Machines Plc. (AS5503) - -- GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3 Fingerprint: 85BA 30C4 9EC8 1792 4C8C C31E 58B5 3D1C B08F 3CA3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ZtFGWLU9HLCPPKMRApqHAJwJAxEbkUmKfUsuK4lOrrs5izPaRgCfePsT b0klVYOObpWZqQZIUd3TrJk= =gb31 -----END PGP SIGNATURE-----

6 5

Re: Verisign insanity - Distributed non-attack
by Stephen J. Wilcox 16 Sep '03

16 Sep '03

On Tue, 16 Sep 2003, John Palmer wrote: > Sorry to sound like a broken record, but we in the Inclusive Namespace > have been saying this all along. Yeah, cmon step down from your soapbox.. > How about a world with 1000's of TLDs all operated by different people > with NO restrictions imposed by a monopoly-supporting politburo (ICANN). No, you miss the point. There are 100s of TLDs already, the point here is that this is .com and .net, I dont care about .blah! Steve > > How about a root network operated under rules designed ONLY to > support the technical stability of the network and not under rules that > masquerade as such but are really designed to prop up a monopoly of > four organizations so that they can corner the market and shut out > all others. > > Imagine such a world. Some people are doing just that. Some people > with a LOT of money to spend on such a project. Stay tuned. > > In a free market namespace (which the ICANN/USG IS *NOT*), > with no un-neccessary barriers to entry, competition would weed > out the players that did anti-social, predatory things like VRSGN > is doing. > > Either a business changes its practices to be in tune with its customer > base or it vanishes. > > FYI: ADNS had wildcard records in the DNS for the .USA, .EARTH, .Z, > .LION and .AMERICA TLDs. They simply pointed to a page that said "This > domain has not been registered yet". Those records were removed > today because of the controversy surrounding wildcard records at the > TLD level. I see a valid use for such records but there is also potential > for abuse and perception is sometimes as important as reality. In the > Inclusive Namespace, competition is a reality because there are no > artificial barriers to entry in the marketplace and players had better listen > to the consumer's opinions or else they will not survive. Thats as it should > be. So, why isn't the #1 (in terms of traffic) root server network operated > that way? > > ----- Original Message ----- > From: "Richard Cox" <Richard(a)mandarin.com> > To: <nanog(a)merit.edu> > Sent: Tuesday, September 16, 2003 10:18 > Subject: Re: Verisign insanity - Distributed non-attack > > > > > > On Tue, 16 Sep 2003 17:02:59 +0200 "RoDent" <rodent(a)mighty.co.za> wrote: > > > > | Effectively this would amount to "denial of service" attack, but since > > | there is nothing illegal about making an http request to an invalid > > | hostname, Verisign will be bringing the denial of service attack upon > > | themselves, and unfortunately dragging ISP's with them. Why ISP's > > | haven't publically taken a stance against this yet is fascinating. > > > > While I completely share your concern about Verisign's behaviour, I have > > a higher level concern about anything seeking to disrupt services on the > > 'net. For some weeks now, several of the abuse-prevention organisations > > have been subjected to Distributed Denial-of-Service attacks; the attack > > on SORBS is still continuing, and very few of the networks carrying this > > DDoS traffic have lifted a finger to either limit or trace the attacking > > traffic. Which, I have to say, is *most* disappointing. > > > > -- > > Richard Cox > > > > > > >

1 0

Detroit Area
by frank＠try-us.de 16 Sep '03

16 Sep '03

Hello nanogers, thank you all for your fast and uncomplicated help. I'm overwhelmed about the respond. Thanks a lot -- Best regards, Frank Kuempel mailto:frank@try-us.de If it's there and you can see it - it's REAL If it's there and you can't see it - it's TRANSPARENT If it's not there and you can see it - it's VIRTUAL If it's not there and you can't see it - it's GONE

1 0

Verisign Countermeasures - BIND and djbdns patches
by Adam Langley 16 Sep '03

16 Sep '03

On Tue, Sep 16, 2003 at 04:03:08PM +0100, Adam Langley wrote: I'm collecting countermeasures to the verisign wildcard DNS records at http://www.imperialviolet.org/dnsfix.html. Currently there are patches for BIND 9.2.2 and djbdns (not authored by myself) and a Linux userland/netfilter program that rewrites DNS packets (which is). If anyone has other patches/countermeasures I'm happy to maintain a list of links at the above URL. -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

3 2

Verisign's legal woes???
by Roy 16 Sep '03

16 Sep '03

I am just wondering how long until some sharp lawyer sues the heck out of Verisign. While one could argue about who owns unregistered names, there is little or no question about who owns registered names. Verisign's current implementation breaks down for registered names that are not in the zone for some reason. The legal problems 1. This could be considered hijacking of the domain name 2. If the domain name is trademarked, it could be a trademark violation 3. If a registered name goes on HOLD for a day, mail service is suspended (most MTAs keep retrying when the name doesn't resolve). Under the new scheme it all bounces 4. By bouncing mail using the name, it could be the unauthorized use of a domain (that's a crime in California) If one wants to experiment, use dorkslayers.com as your test case. Its a valid paid-for active domain name with no nameservers. Might make a nice class action suit on behalf of all the owners of domain names that aren't in the zone. Could be worth a lot of legal fees.

3 2

Verisign's New Change and Outdate RBL's
by Patrick Muldoon 16 Sep '03

16 Sep '03

Was playing with a test box here at home. Installed SpamAssassian from a newely cvsup'd ports tree on a FreeBSD box, and was surprised to see messages getting marked as received in blacklists that no longer exist. Most noteably ORBS. Since this was a fresh Install I hadn't gone through and removed the dead RBL's from 20_head_tests.cf yet. Since dorkslayers doesn't exist. any queries for it are returning that infamous sitefinder address. [doon@fawkes doon]$ host 34.131.246.64.orbs.dorkslayers.com 34.131.246.64.orbs.dorkslayers.com has address 64.94.110.11 So anybody that hasn't update their SpamAssassian config, now has the added benefit of all ip's being tagged as an open relay. Just an FYI -Patrick

2 1

Verisign changes violates RFC2821
by Avleen Vig 16 Sep '03

16 Sep '03

Just to make it clear, RFC2821 is likely being violated: - The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used. This is *probably* being violated, but I'm not sure as it gets ambiguous later. However, returning a 550 is very wrong. The correct reply should be either: 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") or: 502 Command not implemented

1 0

Verisign HOWTO
by Chris Roberts 16 Sep '03

16 Sep '03

I've been asked to forward this here on behalf of Martin A Brooks martin(a)hinterlands.org: http://www.hinterlands.org/ver/txt It's a 'How to get your IP block removed from the list that Verisign will reply with SiteFinder for'. Cheers, Chris.

2 1

Re: What *are* they smoking?
by Miquel van Smoorenburg 16 Sep '03

16 Sep '03

In article <cistron.Pine.GSO.4.56.0309151931440.12273@westnet>, Christopher X. Candreva <chris(a)westnet.com> wrote: >This also blows away the whole idea of rejeting mail from non-existant >domains -- never mind all the bounces to these non-existant domains when the >spammers get ahold of them. Boy, I hope they have a good mail server >responding with the 550 on that IP ! Oh yes, top of the line: $ telnet ariekanariebla.net 25 Trying 64.94.110.11... Connected to sitefinder-idn.verisign.com. Escape character is '^]'. 220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready syntaxerror 250 OK quit 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host. Mike. -- The big problem with blacksmithing resumes is that most of them are forged. -- Joe Marshall

2 1

Re: Change to .com/.net behavior
by George William Herbert 16 Sep '03

16 Sep '03

I would like to make a few evolving observations about the wildcard DNS entries which Verisign initiated in .net and .com earlier today. 1) By all reasonable interpretations, Verisign is now operating in violation of the .com and .net Registry Agreements. Specifically, Sect 24 of the main agreement for .com and Sect 3.5.3, 3.5.5, and 3.6, 3.8 of the main agreement for .net, and the rather blank Appendix X. I believe it to be trivial to demonstrate that even if Verisign issued an ammended Appendix X, such a wildcard entry will exceed the numerical limits specified of 5000 domains, and that the anti-competitive and code of conduct sections will still apply and prohibit this behaviour. Explicitly. 2) By any reasonable interpretation this sort of change should have been clearly announced beforehand to technical communities that would be affected, including but not limited to NANOG, and was not. 3) By any reasonable interpretation this sort of change should have been clearly announced beforehand to policy communities that would be affected, and was not. 4) By any reasonable interpretation of safe and conservative operational procedure, when the various technical and policy issues which were raised over the course of today were made public, Verisign should have rolled the changes back out and announced so until such time as at least *proper* and extensive announcements were made, preferably until such time as Verisign obtained technical community and policy community approval. Verisign has not done so as of when this email was being prepared, at least not querying A.GTLD... 5) An organization which displays this sort of behaviour is not a reasonable candidate from an operational standpoint to stand as the manager of any GTLD. 6) An organization which displays this sort of behaviour is not a reasonable candidate from a legal standpoint to stand as the manager of any GTLD. 7) An organization which displays this sort of behaviour is not a reasonable candidate from a technical standpoint to stand as technical manager of any GTLD or the registrar coordination processes. 8) An organization which displays these sorts of behaviours clearly calls into question the operating assumptions about fair registrar behaviour in the .com and .net registry agreements and thus the entire validity of allowing one company to both manage and act as a registrar for those domains. 9) The apparent complete lack of clue on Verisigns' part as to the magnitude of the hornets nest that this change would kick over, and its lack of any appropriate responses even simply better wider information releases, calls into question the suitability of Verisign's staff and management structure for operating the key central registry functions. 10) Given items 1-9, I call upon ICANN to immediately launch an investegation into the validity and legality of Verisign's wildcard DNS entries; into the operational procedures Verisign is using; into the apparent material breach of Verisign's .com and .net management contracts; and into the suitability of Verisign to remain the .com and .net manager in the future and in pariticular the suitability of the current Verisign management team for participation in that key neutral operational role. I specifically request that ICANN initiate community policy discussions as to whether the GTLD management functions should be required to be spun off into a separate entity from Verisign and not sharing any ownership or management structure. 11) Given items 1-9, I call upon the Department of Commerce to immediately investigate whether Verisign is in material breach of its cooperative agreements and whether Verisign in its current form and with its current staff are suitable to remain manager of the .com and .net GTLDs, and the same set of questions I pose to ICANN, in such areas as DOC is engaged in policymaking regarding Internet Domain Names. -george william herbert gherbert(a)retro.com

1 0