Re: Any workarounds for Verisign .com/.net highjacking?
[obligatory From: address is IPv6-only; to obtain IPv4-mailable address, remove hostname part. Even then no guarantee mail won't bounce -- I follow the list archives in my copious offline time] In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of I have no idea of how well either of these work. Use your own discretion at applying them. djbdns-1.05-ignoreip2.patch seems to work very well here, on three A stupid question, no less, since I see this being discussed here -- is it correct that the ISC BIND patch does not work with a nameserver that's set up as a forward-only box? I've applied the patch to a random BIND successfully, but I'm configured as forward-only for the domains I don't dish out, being on the unpleasant end of a PPP dial-in and trying to do my part to keep the root nameservers' load down. I nab the ISP-provided DNS addresses during the PPP handshake, configure them as forwarders (plus one or two backups) and restart named, but still I was able to resolve a made-up com domain to the Usual Address. This tells me I need to use the DNS machines of an ISP with Clue as static forwarder addresses, not those provided by ISP-of-the-day (and the last ISP seemed to give horribly broken machines anyway), if this reaches a point where I actually want to do something about these wildcards. Provided the ISP allows outgoing DNS queries too. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Fri, Sep 19, 2003 at 12:09:22PM +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2003-09-16 16:58:06 -0400: At 10:23 AM -1000 9/16/03, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? The story at http://daily.daemonnews.org/view_story.php3?story_id=4068 notes that there is a patch for dnscache at: http://tinydns.org/djbdns-1.05-ignoreip.patch see this one: http://tinydns.org/djbdns-1.05-ignoreip2.patch and this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/56951 I have no idea of how well either of these work. Use your own discretion at applying them. djbdns-1.05-ignoreip2.patch seems to work very well here, on three boxes; fourth one will follow later today. Belated followup to this: The above-mentioned DJBDNS patch has been working great for me. I worked it into my local copy of the ports tree. Things are much better now... -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
# [EMAIL PROTECTED] / 2003-09-16 16:58:06 -0400: At 10:23 AM -1000 9/16/03, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? The story at http://daily.daemonnews.org/view_story.php3?story_id=4068 notes that there is a patch for dnscache at: http://tinydns.org/djbdns-1.05-ignoreip.patch see this one: http://tinydns.org/djbdns-1.05-ignoreip2.patch and this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/56951 I have no idea of how well either of these work. Use your own discretion at applying them. djbdns-1.05-ignoreip2.patch seems to work very well here, on three boxes; fourth one will follow later today. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
Clifton Royston wrote: For those who don't know what I'm talking about, try executing host thisdomainhasneverexistedandneverwill.com, or any other domain you'd care to make up in .com or .net. Verisign has abused the trust placed in them to operate a root name server, by creating wildcard A records directly under .com and .net, which point to Verisign's search website. If you get their A record in your resolver, pretend you got the standard error instead. It's a really easy resolver hack. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, 16 Sep 2003, M. Warner Losh wrote: I think we should put a filter for this nonsense into the base system. ISC is in the process of releasing patched versions of BIND, which I plan to take advantage of. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, Sep 16, 2003 at 10:23:56AM -1000, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. These records aren't in the root zone. Ceri -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
Doug Barton wrote:
ISC is in the process of releasing patched versions of BIND, which I
plan to take advantage of. :)
Doug
Patch to port dns/bind9 to upgrade bind9 to 9.2.2-P1:
http://www.isc.org/products/BIND/delegation-only.html
--- bind9.patch begins here ---
diff -u Makefile.orig Makefile
--- Makefile.orig Sat Sep 6 02:05:46 2003
+++ MakefileWed Sep 17 13:06:06 2003
@@ -19,6 +19,11 @@
MASTER_SITE_SUBDIR= bind9/${ISCVERSION}
DISTFILES= bind-${ISCVERSION}.tar.gz
+PATCH_SITES= ${MASTER_SITES}
+PATCH_SITE_SUBDIR= ${MASTER_SITE_SUBDIR}
+PATCHFILES=patch.9.2.2-P1
+PATCH_DIST_STRIP= -p1
+
MAINTAINER= [EMAIL PROTECTED]
COMMENT=Completely new version of the BIND DNS server
diff -u distinfo.orig distinfo
--- distinfo.orig Tue Mar 4 10:44:15 2003
+++ distinfoWed Sep 17 13:06:14 2003
@@ -1 +1,2 @@
MD5 (bind-9.2.2.tar.gz) = 6ea7d64a0856893ab3eb541ab7bbc725
+MD5 (patch.9.2.2-P1) = 063edc41c756ffc6a1051d5f1937fa2c
--- bind9.patch ends here ---
put
zone com {
type delegation-only;
};
zone net {
type delegation-only;
};
in your named.conf:
hasta la vista, 64.94.110.11
Have fun
Oliver
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Any workarounds for Verisign .com/.net highjacking?
For those who don't know what I'm talking about, try executing host thisdomainhasneverexistedandneverwill.com, or any other domain you'd care to make up in .com or .net. Verisign has abused the trust placed in them to operate a root name server, by creating wildcard A records directly under .com and .net, which point to Verisign's search website. This kind of abuse, which I don't think was ever anticipated as coming from an authorized root name server, is busting all manner of things in DNS. To name just a couple at this site, it's a bonanza to spammers because it breaks all the antispam measures which depend on validating the sender or hello domain, and it's screwing up the proxy-autoconfigure script for our webcache (which uses Javascript to check if a domain exists so that the user can get an in-browser error rather than a web-cache error page on typos) I'm sure there are other little things that it will break to have every possible .com or .net domain resolve. To add insult to injury, the site is slow as molasses to come up, taking literally minutes to finally appear in a browser. I filed a personal complaint to ICANN asking that they revoke Verisign's right to operate a root name server and to be a registrar for .com and .net. (If you think this is overly harsh, check the requirements for TLD managers given in RFC 1591 and for root name server operators in RFC 2870.) Given the rate at which ICANN moves, maybe I'll get an initial response that they've read my message in the next 2 years. In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On 16 Sep 2003 at 10:23, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? Sorry, only for bind8, as was posted to my local LUG list: http://achurch.org/bind-verisign-patch.html -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
At 10:23 AM -1000 9/16/03, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? The story at http://daily.daemonnews.org/view_story.php3?story_id=4068 notes that there is a patch for dnscache at: http://tinydns.org/djbdns-1.05-ignoreip.patch someone also posted a likely update for bind 9 to slashdot: http://slashdot.org/comments.pl?sid=78637cid=6973033 (also available in a uuencoded version at: http://slashdot.org/comments.pl?sid=78637cid=6972991 ) I have no idea of how well either of these work. Use your own discretion at applying them. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, 16 Sep 2003, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? http://www.imperialviolet.org/dnsfix.html A few hack-arounds have been posted here. ...david --- david raistrick [EMAIL PROTECTED] http://www.expita.com/nomime.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
* Dan Langille [EMAIL PROTECTED] [030916 16:46]: On 16 Sep 2003 at 10:23, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? Sorry, only for bind8, as was posted to my local LUG list: http://achurch.org/bind-verisign-patch.html And from NANOG, here are workarounds for Bind9 and djbdns. http://www.imperialviolet.org/dnsfix.html pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On 16-Sep-2003 Dan Langille wrote:
On 16 Sep 2003 at 10:23, Clifton Royston wrote:
In the meantime I'm trying to figure out if there's some simple hack
to disregard these wildcard A records, short of requesting zone
transfers of the root nameservers (e.g. via peering with
f.root-servers.net) and purging those records out of the zone before
loading it. Any ideas, either under djbdns or Bind 9?
Sorry, only for bind8, as was posted to my local LUG list:
http://achurch.org/bind-verisign-patch.html
I think the patch will cause named to leak memory, though, unless you
add a call db_detach(dp); somewhere before the continue. I think
the corrected patch should look like this:
Index: ns_resp.c
===
RCS file: /home/ncvs/src/contrib/bind/bin/named/ns_resp.c,v
retrieving revision 1.1.1.2.2.10
diff -u -r1.1.1.2.2.10 ns_resp.c
--- ns_resp.c 25 Aug 2003 21:07:49 - 1.1.1.2.2.10
+++ ns_resp.c 16 Sep 2003 21:37:56 -
@@ -955,6 +955,16 @@
type = dp-d_type;
if (i ancount) {
/* Answer section. */
+ /* HACK to kill Verisign stupidity
+* [EMAIL PROTECTED]
+* see http://www.imperialviolet.org/dnsfix.html */
+ static char IP_TO_KILL[] = {64,94,110,11};
+ if (type == ns_t_a
+ memcmp(dp-d_data, IP_TO_KILL, 4) == 0) {
+ db_detach(dp);
+ validanswer = 0;
+ continue;
+ }
/*
* Check for attempts to overflow the buffer in
* getnameanswer.
That's just from looking at the nearby code. I haven't tested it
extensively.
I have notified the original author of the patch about this.
John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On 16-Sep-2003 M. Warner Losh wrote: I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. I think so too, in principle. But we need something better than a hard-coded IP address. It would take Verisign about an hour to figure out they need to change the address frequently. (Well, OK, a day ... it's Verisign, after all.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
In message: [EMAIL PROTECTED] John Polstra [EMAIL PROTECTED] writes: : On 16-Sep-2003 M. Warner Losh wrote: : I think we should put a filter for this nonsense into the base : system. Hack the resolve to filter out the adddress, and hack bind to : filter it out too. that way we can leverage our position in the name : servers in the world to do something about this BS. : : I think so too, in principle. But we need something better than a : hard-coded IP address. It would take Verisign about an hour to figure : out they need to change the address frequently. (Well, OK, a day ... : it's Verisign, after all.) Agreed. but it wouldn't be too hard to determine at boot/hourly doing a bogus query to find the address of the moment. Even they would be hard pressed to change things more than hourly. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
* M. Warner Losh [EMAIL PROTECTED] [030916 20:12]: I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. ISC claims they'll have a patch ready for the stock BIND sometime in the next few days for this. All we need to do is import it :) --Mike pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
* John Polstra [EMAIL PROTECTED] [030916 20:14]: On 16-Sep-2003 M. Warner Losh wrote: I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. I think so too, in principle. But we need something better than a hard-coded IP address. It would take Verisign about an hour to figure out they need to change the address frequently. (Well, OK, a day ... it's Verisign, after all.) The best idea I had seen floated around was to cache the response to the lookup of *.net for a given period of time inside the resolver. [EMAIL PROTECTED]:~$ host *.net *.net has address 64.94.110.11 --Mike pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, Sep 16, 2003 at 05:55:58PM -0600, M. Warner Losh wrote: I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. IMHO the correct behavior would be to discard any wildcard RR at any TLD zone. I found most of the discussion seems to be going on on NANOG. (Apparently they're not the first, BTW; some CC TLDs have been doing it for a while, as have some of the new TLDs like .museum. It's just that it was a noise-level problem until it affected .com and .net) The ISC has announced it expects to have a patch by Wednesday. That's better than I'd hoped. Thanks for all the feedback I've got, BTW. http://apnews.excite.com/article/20030916/D7TJOF3G0.html -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
* Michael Edenfield [EMAIL PROTECTED] [030916 20:21]: * M. Warner Losh [EMAIL PROTECTED] [030916 20:12]: I think we should put a filter for this nonsense into the base system. Hack the resolve to filter out the adddress, and hack bind to filter it out too. that way we can leverage our position in the name servers in the world to do something about this BS. ISC claims they'll have a patch ready for the stock BIND sometime in the next few days for this. All we need to do is import it :) In particular, see: http://apnews.excite.com/article/20030916/D7TJOF3G0.html Though running the software update is optional, Vixie expects many customers will. The consortium was testing the patch Tuesday and planned to release it by Wednesday. --Mike pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On Tue, Sep 16, 2003 at 06:04:17PM -0600, M. Warner Losh wrote: Agreed. but it wouldn't be too hard to determine at boot/hourly doing a bogus query to find the address of the moment. Even they would be hard pressed to change things more than hourly. In the document VeriSign distributes on the *.com spam portal, titled Site Finder Developer's Guide (an entertaining read): http://sitefinder.verisign.com/pdf/sitefinderdevguide.pdf they describe the procedure for applications to determine if a match is the result of an actual domain record or the wildcard. This consists of comparing the returned address to the record for *.com. If the resolver could cache this value, it would be easy to keep up with VeriSign's current canonical spam host: % host -t a \*.com *.com has address 64.94.110.11 -- || Seth Kingsley || [EMAIL PROTECTED] || || http://www.meowfishies.com/ | Meow ^_^ || pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Polstra [EMAIL PROTECTED] writes: : On 16-Sep-2003 M. Warner Losh wrote: : I think we should put a filter for this nonsense into the base : system. Hack the resolve to filter out the adddress, and hack bind to : filter it out too. that way we can leverage our position in the name : servers in the world to do something about this BS. : : I think so too, in principle. But we need something better than a : hard-coded IP address. It would take Verisign about an hour to figure : out they need to change the address frequently. (Well, OK, a day ... : it's Verisign, after all.) Agreed. but it wouldn't be too hard to determine at boot/hourly doing a bogus query to find the address of the moment. Even they would be hard pressed to change things more than hourly. They will then be able to make this router to filter out the better half of Internet after a while. -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
* Clifton Royston [EMAIL PROTECTED] [030916 20:22]: I found most of the discussion seems to be going on on NANOG. (Apparently they're not the first, BTW; some CC TLDs have been doing it for a while, as have some of the new TLDs like .museum. It's just that it was a noise-level problem until it affected .com and .net) In particular, many of the countries where domain names are their primary export (think .nu, .cc, etc) do this. Some of them have seperate MX records, too, so all mail to non-existant domains gets shunted off somewhere. On the flip side, the people who run .bix and .info (?) tried the same stunt as Verisign a few months back, and if I remember my news blurbs right, the US Gov't asked them to stop. --Mike pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On 17-Sep-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Polstra [EMAIL PROTECTED] writes: : On 16-Sep-2003 M. Warner Losh wrote: : I think we should put a filter for this nonsense into the base : system. Hack the resolve to filter out the adddress, and hack bind to : filter it out too. that way we can leverage our position in the name : servers in the world to do something about this BS. : : I think so too, in principle. But we need something better than a : hard-coded IP address. It would take Verisign about an hour to figure : out they need to change the address frequently. (Well, OK, a day ... : it's Verisign, after all.) Agreed. but it wouldn't be too hard to determine at boot/hourly doing a bogus query to find the address of the moment. Even they would be hard pressed to change things more than hourly. True, we could probably do it. I guess we'd have to generate a few random and unlikely queries, try them, and see if all/most of them resolve to the same address. Or maybe the to the same small set of addresses, depending on how determined Verisign is to make this work. I just _love_ how Verisign doesn't even have a reverse DNS record for that address. Jerks. I sincerely hope that for once, the herds of cattle who use AOL and MSN and think internet and web are synonyms will realize this just ain't right and raise a fuss about it. But given their meek response to spam, pop-ups, and spyware, I'm not all that optimistic. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
* John Polstra [EMAIL PROTECTED] [030916 21:27]: True, we could probably do it. I guess we'd have to generate a few random and unlikely queries, try them, and see if all/most of them resolve to the same address. Or maybe the to the same small set of addresses, depending on how determined Verisign is to make this work. *.net should work, since they basically added a * A record to .com and .net. I just _love_ how Verisign doesn't even have a reverse DNS record for that address. Jerks. [EMAIL PROTECTED]:/usr/src# host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com --Mike pgp0.pgp Description: PGP signature
Re: Any workarounds for Verisign .com/.net highjacking?
On 17-Sep-2003 Michael Edenfield wrote: * John Polstra [EMAIL PROTECTED] [030916 21:27]: True, we could probably do it. I guess we'd have to generate a few random and unlikely queries, try them, and see if all/most of them resolve to the same address. Or maybe the to the same small set of addresses, depending on how determined Verisign is to make this work. *.net should work, since they basically added a * A record to .com and .net. Yep, that should work. I just _love_ how Verisign doesn't even have a reverse DNS record for that address. Jerks. [EMAIL PROTECTED]:/usr/src# host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com When I wrote the above, host 64.94.110.11 didn't return anything. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
