Re: public resolver (was: bind patch? (Re: What *are* they smoking?))
On woensdag, sep 17, 2003, at 19:32 Europe/Amsterdam, Paul Vixie wrote: 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.) It wouldn't talk to me or some others who were helpful enough to send me dig output yesterday. Works fine now, though.
Re: Root Server Operators (Re: What *are* they smoking?)
Paul Vixie wrote: 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. Paul, I would argue as seen in some of my other posts, that the wildcard feature of .museum is not always wanted either. Would it not be wise to push forward into the future with support for software to request if it wants a wildcard or not? While a wildcard bit is ideal, there are methods of determining wildcard programatically. Being able to cache and handle such information is important as different applications have different requirements. After all, is this the Internet or just the World Wide Web? wildcards at the roots are catering solely to the web and disrupting other protocols which require NXDOMAIN. -Jack
Re: Root Server Operators (Re: What *are* they smoking?)
* [EMAIL PROTECTED] (Jack Bates) [Thu 18 Sep 2003, 16:41 CEST]: After all, is this the Internet or just the World Wide Web? wildcards at the roots are catering solely to the web and disrupting other protocols which require NXDOMAIN. Wildcards anywhere are problematic. I've yet to encounter a situation where they didn't cause extreme operational brokenness. -- Niels.
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, Sep 17, 2003 at 01:39:56AM -0400, Sean Donelan wrote: I wouldn't be surprised if tomorrow, Verisign is the playing the victim and calling ISC the out-of-control hooligans. Paul an out of control hooligan, say it isn't so ! :) Actually I'd trust ISC/Vixie/ to always do the real right thing when it comes to root-ops and global DNS. and I'd trust the Verisign people that run A and J to do reasonable things with those boxes. They are good people, when they wear those hats. I'd almost never trust Verisign to do whats right for the public / internet when it comes to dealing with .COM, .NET and such. Thats their cash cow and they will milk it for all its worth, and then some. speaking as a shareholder of Verisign, I'm NOT HAPPY with the way they handled this wildcard deal, nor am I happy about them doing it all. As a *shareholder* I'd cast my vote that they *remove* it.
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?)
On Wed, 17 Sep 2003, John Brown wrote: speaking as a shareholder of Verisign, I'm NOT HAPPY with the way they handled this wildcard deal, nor am I happy about them doing it all. As a *shareholder* I'd cast my vote that they *remove* it. You have no control over operations of the company. However, you may vote Verisign officers out of the office... if you can get other shareholders to see the benefits of giving business ethics preference over short-term profits. --vadim
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, Sep 17, 2003 at 05:13:45AM +, Paul Vixie wrote: 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. I for one expect a small arms race over this - I'm not implementing the end-all solution quite yet as I expect some further moves by VRSN. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO
Re: Root Server Operators (Re: What *are* they smoking?)
There is an article on it here: http://online.wsj.com/article/0,,SB106375269188678100,00.html?mod=technology_main_whats_news but I think it requires a paid subscription Christopher X. CandrevaTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: m Subject: Re: Root Server Operators (Re: What *are* they smoking?) Sent by: [EMAIL PROTECTED] .edu 09/16/2003 05:21 PM On Tue, 16 Sep 2003, Eric Gauthier wrote: On the other hand, a headline of Internet Providers Worldwide block access to Verisign in Effort to Protect the Public is very easily understood. I was contacted a little while ago by a reporter from the Wall Street Journal, based on my Nanog posts. We'll see what the headline reads. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: public resolver (was: bind patch? (Re: What *are* they smoking?))
On woensdag, sep 17, 2003, at 06:15 Europe/Amsterdam, Paul Vixie wrote: 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. So far so good: sequoia# host nanog.net. nanog.net has address 64.94.110.11 sequoia# host nanog.net. 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. 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. Just when I thought I had a DNS server I could point my IPv6-only hosts to...
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Sean Donelan wrote: What would it do to website's Keynote performance to eliminate another name lookup by having their www.something.com records served directly from Verisign's gtld-servers? Now, that would be a real problem, considdering the person who owns something.com is a good friend of mine, and hosts it on my servers. If they start touching actual registered and in-use domains I believe they will loose their contract. :-) (Which also means PLEASE don't use something.com to test !) -Chris == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Paul Vixie wrote:
: Anyone have a magic named.conf incantation to counter the verisign
: braindamage?
:
: zone com { type delegation-only; };
: zone net { type delegation-only; };
What's to stop VRS from countering with:
*.com. IN A ipaddr
*.com. IN NS letter.gtld-servers.net.
? (Yup, then there's checking SOA, but there's always the chance that they
can synthesize that too, and move the A record inside it.)
Downward spiral, here we come...! 8-)
--
-- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, Sep 17, 2003 at 09:27:13AM -0400, Todd Vierling wrote:
On Wed, 17 Sep 2003, Paul Vixie wrote:
: Anyone have a magic named.conf incantation to counter the verisign
: braindamage?
:
: zone com { type delegation-only; };
: zone net { type delegation-only; };
My first reaction to this was: 'yuck'. I'm not sure of the
side-effects this will introduce. Anyone?
Stefan
--
Stefan Baltus [EMAIL PROTECTED]XB Networks B.V.
Manager Engineering Televisieweg 2
telefoon: +31 36 54624001322 AC Almere
fax: +31 36 5462424 The Netherlands
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, Sep 17, 2003 at 03:35:31PM +0200, Stefan Baltus wrote:
On Wed, Sep 17, 2003 at 09:27:13AM -0400, Todd Vierling wrote:
On Wed, 17 Sep 2003, Paul Vixie wrote:
: Anyone have a magic named.conf incantation to counter the verisign
: braindamage?
: zone com { type delegation-only; };
: zone net { type delegation-only; };
My first reaction to this was: 'yuck'. I'm not sure of the
side-effects this will introduce. Anyone?
The only thing I am slightly worried about is setups that currently work
because they rely on glue. Nothing is to stop someone from doing:
yourdomain.com IN NS www.yourdomain.com.
yourdomain.com IN NS yourdomain.com.
www.yourdomain.com IN A 1.2.3.4
yourdomain.com IN A 1.2.3.4
And not run a nameserver at all and completely rely on glue.
Something like this can be seen on www.airow.com:
$ dig www.airow.com @a.gtld-servers.net
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 24292
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;www.airow.com. IN A
;; ANSWER SECTION:
www.airow.com. 172800 IN A 66.82.206.10
Note the lack of 'aa' bit - but I wonder how many resolvers were accepting
this answer. I know pdns_recursor does, it trusts glue to be right. In this
case, if we actually bother to ask the nameserver www.airow.com for the IP
address of www.airow.com, we don't get an answer. If we ask the other listed
nameserver for airow.com (ns1.rfwwp.com), we get a different IP address,
208.191.129.189.
Different recursors that are publically (130.161.180.1, 195.96.96.97)
available appear to return the first address when currently queried for
www.airow.com, so they trust the glue too.
After delegation-only, they will start to return 208.191.129.189. Which is
probably an improvement, but a change no less.
So I'm unsure about ISC's approach.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing Traffic Control HOWTO
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: Root Server Operators (Re: What *are* they smoking?)
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
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
Eric Germann wrote: And whats to say they don't get around our methods of blacklisting it by changing the IP around every zone update? result=query domain.tld wild=query *.tld if result=wild dontwantwild then result=NXDOMAIN -Jack
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Jack Bates wrote: 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. Verisign is at least using 15 minute ttls on the wildcards. Not that I think a wildcard in .com/.net is a great idea, but with the low ttls, it won't cache that long. 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. What if there was a requirement to add something that would work as a wildcard, but also be easily detected as a wildcard with one additional query? thisisawildcard.*.com IN A 127.0.0.1 or something. One additional query, and applications can decide whether they want a wildcard result or not. That could be added to spam filters to make them work again. I'm not sure if one can use wildcards in that way, but that would solve the problem and let them keep their wildcards, and put the ball into the court of the application developers. Aaron
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Jack Bates wrote: Aaron Dewell wrote: What if there was a requirement to add something that would work as a wildcard, but also be easily detected as a wildcard with one additional query? thisisawildcard.*.com IN A 127.0.0.1 or something. One additional query, and applications can decide whether they want a wildcard result or not. That could be added to spam filters to make them work again. One additional query is the problem. For example, a mail server running sendmail with a bind recursor. If sendmail has to check for the wildcard, it will have to check for *.com as well as example.com and do a set comparison to see if example.com is a wildcard. For every new process, this has to be repeated, doubling the number of queries on the recusor. The comparison could be eliminated with the thisisawildcard flag or similar, but either way, yes, it doubles the number of lookups. Not ideal, but it works, and given that Verisign is going to continue to do what they are doing unless DoC or ICANN tells them not to (may or may not happen), this makes a reasonable backup plan. If DoC and ICANN won't tell them to knock it off, they might tell them to make it more obvious in this way. Yes, it's more overhead for everyone else to make up for their brilliant marketing idea, but it would work. What other plan does everyone have if ICANN says Oh, it's ok, we don't mind, whatever they want to do is fine? How many people (realistically) are going to deploy the ISC patch? When Paul Vixie says he doesn't really like it? And it's only available for BIND 9? As someone else pointed out, this battle is in a completely different arena. MSN and AOL aren't going to implement the patch, guarenteed. They _might_ redirect traffic to that IP to their own site. And only that until a lawsuit gets filed. The point is, this makes a reasonable backup plan. Far from ideal, but we're dealing with a state-supported monopoly who can do whatever they want. Get this in place, then think about how to throw the monopolies out. This works in the meantime. They will likely compromise this far, even if they won't back down. If the IPv6 specs were modified somewhat, one could assign a prefix to everyone and every organization, and use a registry to map them, like the ID system that someone else mentioned (sorry, I don't have the email in front of me). Those projects could be combined to solve the problem for all time. That's a separate issue that needs more research. If, however, the recursor performed the processes, caching *.com for the TTL and recognizing that all domains resolving to its set is also a wildcard, and caching/marking them as such, then the resolver can request the record, without wildcards, on behalf of sendmail. This means one query to the recursor who has properly cached 1) the domain record, 2) if the domain record is a wildcard, and 3) the wildcard set. This is about the minimal number of queries that can be performed across the board. Applications that want to accept the wildcard would ask the record normally (accepting wildcard). The TTL is 15 minutes, so your hypothetical server would be throwing away it's cache every 15 minutes. Then re-querying everything. You'd have to have a _lot_ of outgoing email to justify that. This solution still requires increased overhead, and more modifications to BIND. Which has more impact on your server, this BIND overhead, or one additional query from your MTA? My guess is the query is cheaper overall. And you have to convince ISC to implement these changes, or write them yourself, then you have the potential cost of an unstable nameserver. Overall, I'd take the one addition query based on the compromise solution. Aaron
Re: Root Server Operators (Re: What *are* they smoking?)
Aaron Dewell wrote: The point is, this makes a reasonable backup plan. Far from ideal, but we're dealing with a state-supported monopoly who can do whatever they want. Get this in place, then think about how to throw the monopolies out. This works in the meantime. They will likely compromise this far, even if they won't back down. I'm thinking security for the long term. Even if com and net are returned to their non-wildcard states, there are other tld's which will continue using wildcards. Subject to a wildcard bit being implemented to DNS, my suggested method allows for optimum performance and functionality when DNS is being used as part of a security model. The TTL is 15 minutes, so your hypothetical server would be throwing away it's cache every 15 minutes. Then re-querying everything. You'd have to have a _lot_ of outgoing email to justify that. I don't know about you, but I don't want to cache bogus information for longer than 15 minutes. If someone sends random-string domains as the envelope from to my mail server, I want the cache to purge itself quickly. Yet, if they are sending the same bad address to my mail server repetitively, I want my cache to hold the record briefly; say 15 minutes. I'd hate to see a spammer issuing jlkfsjklfsj.com 5,000 times to my mail server in rapid succession and my recursor have to ask for it every time. On the other side, I would hate to cache 100,000 bogus domains for 1 day, wasting cache. This solution still requires increased overhead, and more modifications to BIND. Which has more impact on your server, this BIND overhead, or one additional query from your MTA? My guess is the query is cheaper overall. And you have to convince ISC to implement these changes, or write them yourself, then you have the potential cost of an unstable nameserver. Overall, I'd take the one addition query based on the compromise solution. My mail server doesn't use a bind recursor, so I'll end up making the change myself for that particular system. However, a solution needs to be devised for the long term. The best solution is a wildcard bit. Second to that, smart recursors and resolvers that can detect the wildcard. -Jack
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: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Paul Vixie wrote: 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? 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. 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. Do you think they should have the public's interest in mind? And do you think the wildcards are in the public's interest? 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. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
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
Re: Root Server Operators (Re: What *are* they smoking?)
amen. of course the security problems are inherent in the use of wildcards at all, not just at delegations at/near the root. One would hope that the folks who use wildcards or are IMPACTED by wildcards would review the current IETF ID on wildcard clarification that is approching last-call. 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
Re: What *are* they smoking?
In the immortal words of Wayne E. Bouchard ([EMAIL PROTECTED]): So then now instead of mail to misspelled domains, instead of bouncing, now goes to /dev/null and you have no idea that your critically important piece of information didn't get through? You _hope_ it goes to /dev/null. It might be interesting to seed a few pieces of accidentally typo'ed mail to .net domains and see how many of the From addresses get sales email from Verisign in the coming year. And I'm sure that the Department of Homeland Security would not be even slightly interested in performing signal analysis on the vast majority of mis-typed emails in this and most other countries. Interesting times. -n ---[EMAIL PROTECTED] So perhaps the factor constraining the Internet's growth is good taste. (--Paul Vixie) http://blank.org/memory/---
Re: What *are* they smoking?
Subject: Re: What *are* they smoking? Date: Tue, Sep 16, 2003 at 03:13:49AM +0200 Quoting Tomas Lund ([EMAIL PROTECTED]): On Mon, 15 Sep 2003, Chris Adams wrote: It appears that the most reliable way to detect a wildcard response for 'somedomain.tld' is to query for '*.tld'; if the results match, then 'somedomain.tld' doesn't really exist. Just make up a number of fake domains and resolve them. If they return the same answer, thats the answer to change back into NXDOMAIN. More precise: dig @ns.nic.nu. '*.nu' ANY The quotes mean that the string '*.nu' will be passed straight to the name server. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE I'm EMOTIONAL now because I have MERCHANDISING CLOUT!! pgp0.pgp Description: PGP signature
Re: What *are* they smoking?
In article [EMAIL PROTECTED], Christopher X. Candreva [EMAIL PROTECTED] 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
Fwd: Re: Patching BIND (Re: What *are* they smoking?)
-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 HopMetric LocPrf Weight Path *i12.158.80.0/24 xxx.xxx.xxx.xxx 305100 0 1239 7018 26134 30060 ? *i64.94.110.0/24 xxx.xxx.xxx.xxx 305100 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.[EMAIL PROTECTED] / [EMAIL PROTECTED] Principal Internet Engineer, Internet for Learning, Research Machines Plc. (AS5503) - -- GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=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-
Re: What *are* they smoking?
Miquel van Smoorenburg([EMAIL PROTECTED])@2003.09.16 08:43:26 +: Oh yes, top of the line: [...] Mike, even better: it's answering in an unconditional mode! --- [EMAIL PROTECTED]:datasink[2]% telnet jhsdfajjkasfjkjkasf.net 25 Trying 64.94.110.11... Connected to jhsdfajjkasfjkjkasf.net. Escape character is '^]'. 220 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 ready ehlo sucker 250 OK mail from: [EMAIL PROTECTED] 250 OK rcpt to: [EMAIL PROTECTED] 550 User domain does not exist. data 250 OK bla 221 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host. [EMAIL PROTECTED]:datasink[2]% telnet jhsdfajjkasfjkjkasf.net 25 Trying 64.94.110.11... Connected to jhsdfajjkasfjkjkasf.net. Escape character is '^]'. 220 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 ready 250 OK 250 OK 550 User domain does not exist. 250 OK 221 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host. --- At least it leads to momentary amusement. Mad scientists or propellerheads at work there? /k -- Beware of bugs in the above code; I have only proved it correct, not tried it. --Donald Knuth webmonster.de -- InterNetWorkTogether -- built on the open source platform http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 Please do not remove my address from To: and Cc: fields in mailing lists. 10x
Re: What *are* they smoking?
At 12:46 AM 16/09/2003, [EMAIL PROTECTED] wrote: On Tue, 16 Sep 2003 14:31:53 +1000, Matthew Sullivan said: Worse than that - it's a fixed sequence of responses... $ telnet akdjflasdf.com 25 Trying 64.94.110.11... Connected to akdjflasdf.com. Escape character is '^]'. 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready sdfg 250 OK Well.. at least now we know how they *intended* to only affect HTTP traffic. I am sure they will never create a list of email addresses based of the From: address to share with select partners. After all, Verisign is an honorable company. ---Mike
Re: What *are* they smoking?
On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant.
RE: What *are* they smoking?
And then Verisign starts using multiple IP addresses and rotating through them. And then they stop giving any other clues that it is a wildcard record. Great. Just what we need... To be in an escalating war with the people running the root nameservers. Since it is clearly in Verisign's business interest to make it impossible for you to tell when you've been handed one of the wildcard replies, I don't see this stopping any time soon. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomas Lund Sent: Monday, September 15, 2003 6:14 PM To: Chris Adams Cc: [EMAIL PROTECTED] Subject: Re: What *are* they smoking? On Mon, 15 Sep 2003, Chris Adams wrote: It appears that the most reliable way to detect a wildcard response for 'somedomain.tld' is to query for '*.tld'; if the results match, then 'somedomain.tld' doesn't really exist. Just make up a number of fake domains and resolve them. If they return the same answer, thats the answer to change back into NXDOMAIN. //tlund
Re: What *are* they smoking?
Just noticed this: verisign is redirecting queries for dorkslayers.com's old RBL, even though dorkslayers.com is a registered and active domain. It just has no name servers. I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: [EMAIL PROTECTED] Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 10:37:35AM -0500, Marius Strom wrote: So it seems they're doing this to billing-active domains as well. On Tue, 16 Sep 2003, Sabri Berisha wrote: On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant. -- /- Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-| Alan Frame |--
Re: What *are* they smoking?
Just noticed this: verisign is redirecting queries for dorkslayers.com's old RBL, even though dorkslayers.com is a registered and active domain. It just has no name servers. So it seems they're doing this to billing-active domains as well. On Tue, 16 Sep 2003, Sabri Berisha wrote: On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. -- Sabri Berisha I route, therefore you are Wij doen niet aan default gateways - anonymous engineer bij een DSL klant. -- /- Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-| Alan Frame |--
RE: What *are* they smoking?
On Tue, 16 Sep 2003, Matthew Kaufman wrote: record. Great. Just what we need... To be in an escalating war with the people running the root nameservers. Please note that the people running the root nameservsers are a different set from the people who run the .com and .net nameservers. Please use the slightly more accurate term 'gTLD nameservers' instead of tarring the 'root' nameservers with the same brush. --==-- Bruce.
Re: What *are* they smoking?
On Tue, 16 Sep 2003, Haesu wrote: I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?
Re: What *are* they smoking?
Here is one solution - replace all of your root.cache files with: (root) nameserver = C.ROOT-SERVERS.ORSC (root) nameserver = D.ROOT-SERVERS.ORSC (root) nameserver = E.ROOT-SERVERS.ORSC (root) nameserver = F.ROOT-SERVERS.ORSC (root) nameserver = H.ROOT-SERVERS.ORSC (root) nameserver = I.ROOT-SERVERS.ORSC (root) nameserver = K.ROOT-SERVERS.ORSC (root) nameserver = L.ROOT-SERVERS.ORSC (root) nameserver = M.ROOT-SERVERS.ORSC (root) nameserver = A.ROOT-SERVERS.ORSC C.ROOT-SERVERS.ORSC internet address = 199.166.28.10 D.ROOT-SERVERS.ORSC internet address = 204.80.125.130 E.ROOT-SERVERS.ORSC internet address = 195.117.6.25 F.ROOT-SERVERS.ORSC internet address = 199.166.31.3 H.ROOT-SERVERS.ORSC internet address = 199.5.157.128 I.ROOT-SERVERS.ORSC internet address = 204.57.55.100 K.ROOT-SERVERS.ORSC internet address = 199.166.27.4 L.ROOT-SERVERS.ORSC internet address = 199.166.29.2 M.ROOT-SERVERS.ORSC internet address = 195.206.104.13 A.ROOT-SERVERS.ORSC internet address = 199.166.24.12 - Original Message - From: Greg Maxwell [EMAIL PROTECTED] To: Haesu [EMAIL PROTECTED] Cc: Marius Strom [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 11:23 Subject: Re: What *are* they smoking? On Tue, 16 Sep 2003, Haesu wrote: I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?
Re: What *are* they smoking?
On Tue, 16 Sep 2003, Greg Maxwell wrote: On Tue, 16 Sep 2003, Haesu wrote: I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings? My customers. -mark -- Mark Jeftovic [EMAIL PROTECTED] Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237
Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
Has anyone thought through the DNSsec implications of this? (spool up the black helicopters) Greg Maxwell wrote: On Tue, 16 Sep 2003, Haesu wrote: I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
yes. you might want to view/review http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt DNSsec will work properly with wildcards, regardless of where they are in the DNS. Has anyone thought through the DNSsec implications of this? (spool up the black helicopters) Greg Maxwell wrote: On Tue, 16 Sep 2003, Haesu wrote: I must ask the subject again. What in the name of censored *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?
Root Server Operators (Re: What *are* they smoking?)
Bruce Campbell wrote: On Tue, 16 Sep 2003, Matthew Kaufman wrote: record. Great. Just what we need... To be in an escalating war with the people running the root nameservers. Please note that the people running the root nameservsers are a different set from the people who run the .com and .net nameservers. True, these days, at least in part. Since the latest zone for .net (and maybe .com according to the announcement) contains data that * indicates existance for domains that actually do not exist, and * incorrect addresses for domains that exist, but are not using the name service of netSOL cum verisign, it is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file. Please use the slightly more accurate term 'gTLD nameservers' instead of tarring the 'root' nameservers with the same brush. We are about to empirically determine the independence of the root server operators. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: What *are* they smoking?
Once upon a time, John Palmer [EMAIL PROTECTED] said: Here is one solution - replace all of your root.cache files with: (root) nameserver = C.ROOT-SERVERS.ORSC Since the ORSC servers still refer com and net to the GTLD servers, this will have no impact on the issue at hand. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
[EMAIL PROTECTED] wrote: yes. you might want to view/review http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt Wow. That's supposed to clarify? Needs serious editting! (heck, there are typos in the first sentence of the first paragraph of the introduction, and it gets worse from there.) DNSsec will work properly with wildcards, regardless of where they are in the DNS. Well, maybe. Only when the world changes to follow this internet-draft. But at least it's good that somebody is thinking about it -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Root Server Operators (Re: What *are* they smoking?)
Since the latest zone for .net (and maybe .com according to the announcement) contains data that * indicates existance for domains that actually do not exist, and * incorrect addresses for domains that exist, but are not using the name service of netSOL cum verisign, it is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file. We are about to empirically determine the independence of the root server operators. I'm sure that 5, 10, or 50 phone calls from Nanog-ers to the FTC, Congress, Dept of Commerce, ICANN, the US Post Office, or any other large organization will be completely ignored in the likely wash of everyday phone calls. We can talk about violations of RFCs and ask them to cease this stupidity, but I doubt that will work because there doesn't appear to be any consequences. Verisign is a business and its goal is to make money. More importantly, its a publically traded company whose goal is to make its stock value go up. So, if we're interested in having them listen, we should be targeting their stock value. Right now, I really can't think of a headline that the NY Times or CNN could run that would make ordinary people understand what's going on and encourage them to bring pressure on Verisign. Besides, Verisign would obviously counter with the junk in their release. On the other hand, a headline of Internet Providers Worldwide block access to Verisign in Effort to Protect the Public is very easily understood. Verisign can say anything that they want, but the public gets the idea that people in the know think this is such a bad idea that they took action against it. I'm a stupid network engineer that typically leaves the money stuff up to my finance geek friends, but even I know that (well most of the time): Bad Press == Stock Go Down So, if collectively we think this is determinental to the stability and security of the Internet, then we should either take steps to block it or, more importantly, issue press releases and statements to reporters stating that we will. I think this is the only way to effectively reverse Verisign's poor decision. I think its time for the Root Server operators to step up or at least say that they are going to step up. Eric :)
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 2003-09-16 at 18:50, William Allen Simpson wrote: Please note that the people running the root nameservsers are a different set from the people who run the .com and .net nameservers. True, these days, at least in part. Since the latest zone for .net (and maybe .com according to the announcement) contains data that * indicates existance for domains that actually do not exist, and * incorrect addresses for domains that exist, but are not using the name service of netSOL cum verisign, it is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file. Whether the .net and .com zone files are valid or not is really irrelevant for your argument - since the zone file served by the root servers is only for the . zone, not the .net or .com zones any more. The zone file the _root servers_ hold IS therefore a valid zone file. Whatever junk Verisign puts into the com. and net. zones does not implicate the . zone servers at all. /leg
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 16 Sep 2003 13:31:19 EDT, Eric Gauthier said: it. I'm a stupid network engineer that typically leaves the money stuff up to my finance geek friends, but even I know that (well most of the time): Bad Press == Stock Go Down I wish this explained SCO's stock price... ;) pgp0.pgp Description: PGP signature
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
On Tue, 16 Sep 2003 09:59:40 PDT, [EMAIL PROTECTED] said: DNSsec will work properly with wildcards, regardless of where they are in the DNS. Which means that a rogue DNS can lead you down the garden path and DNSsec won't give you a clue that you're being lied to. It's the same question as the what happens to SSL to a phantom site? - Verisign can provide an A record for the server and an SSL cert that will work. pgp0.pgp Description: PGP signature
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
On Tue, 16 Sep 2003 09:59:40 PDT, [EMAIL PROTECTED] said: DNSsec will work properly with wildcards, regardless of where they are in the DNS. Which means that a rogue DNS can lead you down the garden path and DNSsec won't give you a clue that you're being lied to. It's the same question as the what happens to SSL to a phantom site? - Verisign can provide an A record for the server and an SSL cert that will work. thats one aspect yes. the valdiation chain should tell you who signed the delegations. It won't lie. you will know that V'sign put that data there. --bill
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
On Tue, 16 Sep 2003 11:08:11 PDT, [EMAIL PROTECTED] said: On Tue, 16 Sep 2003 09:59:40 PDT, [EMAIL PROTECTED] said: thats one aspect yes. the valdiation chain should tell you who signed the delegations. It won't lie. you will know that V'sign put that data there. How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them. What's next? pgp0.pgp Description: PGP signature
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
thats one aspect yes. the valdiation chain should tell you who signed the delegations. It won't lie. you will know that V'sign put that data there. How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them. What's next? 'splain braindamage in this context please. DNSSEC - signed data in the zone. wildcards - part of the spec. if vt.edu wants to place a: * in a 198.82.247.53 in the vt.edu zone, why should anyone complain that now vt.edu doesn't return NXDOMAIN for all un-delegated entries? You want that everyone should hack the DNS to force NXDOMAINS for your wildcard? Feh. DNSSEC will tell a validating resolver the signature of each party that signed part of the chain. If Verisign wishes to sign bits of data that might exist under the delegation point they have responsibility for, I'm in favor. Its not make-believe ... or perhaps I don't understand your angst.
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
[EMAIL PROTECTED] wrote: How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them. What's next? You mean that you don't like it when the Authority the community places its trust in abuses that power? heh. Go figure. I hope they are sued out of existance. At the least, ICANN needs to do its job. I have a severe issue with changes being made that cause a lot of damage. -Jack
Re: What *are* they smoking?
VeriSign stands to gain financially, take a look at this excerpt from an AP news blurb published yesterday: Ben Turner, VeriSign's vice president for naming services, described the service as a way to improve overall usability of the Internet. People mistype .com and .net names some 20 million times daily, Turner said, and internal studies show the vast majority of users prefer a page like this than what they are getting today. ... Currently, Site Finder sends lost Web surfers to both regular search results and pay-for-placement listings, which are marked as such. Turner said VeriSign was partnering with two search companies he would not name. He would not disclose how much VeriSign would earn from those companies, with which it has revenue-sharing arrangements. Anyone find out any details of the contracts which VeriSign has apparently signed to profit from this little venture? -rich
Re: What *are* they smoking?
On Tue, 16 Sep 2003, Mark Jeftovic wrote: It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings? My customers. End users don't figure out DNS settings on their own, either a network operator picks what roots they use (by say accepting a default root cache in a resolver package) or they obtain configuration directives from an upstream network.
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 16 Sep 2003, Eric Gauthier wrote: Verisign is a business and its goal is to make money.More importantly, its a publically traded company whose goal is to make its stock value go up. So, if we're interested in having them listen, we should be targeting their stock value.Right now, I really can't think of a headline that the NY Times or CNN could run that would make ordinary people understand what's going on and encourage them to bring pressure on Verisign.Besides, Verisign would obviously counter with the junk in their release. So far up 1.7% today: http://finance.yahoo.com/q/bc?s=VRSNt=1d Looks like they are winning. -Hank
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 16 Sep 2003, Damian Gerow wrote: How about, 'Internet Operators Across North America Struggle to Deal with Impact of Business Decision: Internet Functionality Worldwide Tampered With by Verisign'? There doesn't really appear to be a unified decision to do one thing, there's a lot of bandying ideas around, and 'wouldn't-it-be-cool-if's being thrown out. I'm partial to Verisign Hijacks Internet as a good headline. - Robert ip route 64.94.110.11 255.255.255.255 null0
Re: Root Server Operators (Re: What *are* they smoking?)
Anyone have a magic named.conf incantation to counter the verisign braindamage? Or does this require a patch to bind? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Root Server Operators (Re: What *are* they smoking?)
Just came across this: http://www.washingtonpost.com/wp-dyn/articles/A996-2003Sep12.html
Re: What *are* they smoking?
On Tue, 16 Sep 2003, Rich Braun wrote: VeriSign stands to gain financially, take a look at this excerpt from an AP news blurb published yesterday: [...] Anyone find out any details of the contracts which VeriSign has apparently signed to profit from this little venture? It looks like Overture is doing the paid listings: Compare http://sitefinder.verisign.com/spc?kw=Travel withhttp://www.overture.com/d/search/?Keywords=travel You can also see this by looking at the links on the results page. www.expedia.com is actually http://www3.overture.com/d/sr/?... And Inktomi is the provider of non-paid listings: Compare http://sitefinder.verisign.com/spc?sb=verisign+sucks withhttp://www.hotbot.com/default.asp?query=verisign+sucks Both Overture and Inktomi are now owned by Yahoo. Anyone with an Overture account can see what the high bids on the keywords Travel, Entertainment, Gambling, Shopping, Gifts, Computers, Autos, Insurance, Small Business, and Investing are now. From a SEC filing a while ago, I seem to recall that something near half of the money from each click goes back to the search engine in question, in this case Verisign. -- Aaron
Re: Root Server Operators (Re: What *are* they smoking?)
Robert A. Hayden [EMAIL PROTECTED] 9/16/03 2:07:08 PM On Tue, 16 Sep 2003, Damian Gerow wrote: How about, 'Internet Operators Across North America Struggle to Deal with Impact of Business Decision: Internet Functionality Worldwide Tampered With by Verisign'? There doesn't really appear to be a unified decision to do one thing, there's a lot of bandying ideas around, and 'wouldn't-it-be-cool-if's being thrown out. Given the technical nature of the issue perhaps someone from the list with excellent writing skills could author the 'press release'. Then, if someone else has some media or press contacts they could simply pass the release along to them. To be sure, that idea has a few problems but at least you have a chance to make sure the release contains factual information while still conveying the importance of the issue, two things that wouldn't be guaranteed if this were written up by a non-technical member of the press. Anybody know someone that works for AP or Reuters? Or maybe Wall Street Journal? :-) John --
Re: Root Server Operators (Re: What *are* they smoking?)
http://www.iab.org/Documents/icann-vgrs-response.html
Root Server Operators (Re: What *are* they smoking?)
[EMAIL PROTECTED] 9/16/03 2:18:58 PM Just came across this: http://www.washingtonpost.com/wp-dyn/articles/A996-2003Sep12.html Interesting and well-written. And ICANN had no comment. John --
Re: Root Server Operators (Re: What *are* they smoking?)
Damian, You wrote: Damian But any journalists snooping around sure could help out Damian a bit, at least by indicating that there /is/ a Damian problem with this decision, Damian and that Operators are still trying to figure out a) *why* it happened, and Damian b) the best way to 'fix' it. How about writing up a simple explanation and sending it to some folks over at lightreading. That'll get some coverage. Ben.
Re: What *are* they smoking?
$ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness. No, no, no. Here is what you do - you redirect this traffic to your own server and monetize it. Alex
Re: What *are* they smoking?
At 12:07 PM 9/16/2003, Rich Braun wrote: VeriSign stands to gain financially, take a look at this excerpt from an AP news blurb published yesterday: ... Anyone find out any details of the contracts which VeriSign has apparently signed to profit from this little venture? No, but check this out: http://sitefinder.verisign.com/spc?sb=bulk+emailsearchboxtype=2 http://sitefinder.verisign.com/spc?sb=bulk+mailerssearchboxtype=2 Not that I am shocked. ~Ben --- Ben Browning [EMAIL PROTECTED] The River Internet Access Co. WA Operations Manager 1-877-88-RIVER http://www.theriver.com
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 16 Sep 2003, Eric Gauthier wrote: On the other hand, a headline of Internet Providers Worldwide block access to Verisign in Effort to Protect the Public is very easily understood. I was contacted a little while ago by a reporter from the Wall Street Journal, based on my Nanog posts. We'll see what the headline reads. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: Root Server Operators (Re: What *are* they smoking?)
Thus spake Christopher X. Candreva ([EMAIL PROTECTED]) [16/09/03 17:24]: On the other hand, a headline of Internet Providers Worldwide block access to Verisign in Effort to Protect the Public is very easily understood. I was contacted a little while ago by a reporter from the Wall Street Journal, based on my Nanog posts. We'll see what the headline reads. Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large.
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 16 Sep 2003, Damian Gerow wrote: Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large. One other thing to do -- call the technology writer for your local paper, if you know who that is. Which you should. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
RE: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
Title: Re: Verisign brain damage and DNSSec.Was:Re: What *are* they smoking? And whats to say they don't get around our methods of blacklisting it by changing the IP around every zone update? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]Sent: Tuesday, September 16, 2003 2:18 PMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: Re: Verisign brain damage and DNSSec.Was:Re: What *are* they smoking? On Tue, 16 Sep 2003 11:08:11 PDT, [EMAIL PROTECTED] said: On Tue, 16 Sep 2003 09:59:40 PDT, [EMAIL PROTECTED] said: thats one aspect yes. the valdiation chain should tell you who signed the delegations. It won't lie. you will know that V'sign put that data there. How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them. What's next?
Re: Verisign brain damage and DNSSec.....Was:Re: What *are* they smoking?
On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote: How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them. What's next? Well, you can always vote... http://www.forbes.com/2003/05/01/cx_ceointernetpoll.html Link courtesy of inet-access. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/
Re: What *are* they smoking?
Here is one solution - replace all of your root.cache files with: 1) it doesn't solve the problem of the .com and .net registry handing out addresses 2) It creates whole new sets of problems Please continue to go off and skulk in a corner dangerous and broken settings snipped
Re: Root Server Operators (Re: What *are* they smoking?)
Speaking on Deep Background, the Press Secretary whispered: Right now, I really can't think of a headline that the NY Times or CNN could run that would make ordinary people understand what's going on and encourage them to bring pressure on Verisign. Verisign Move to Mean More Spam Will that do for a hook? -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Root Server Operators (Re: What *are* they smoking?)
DL Date: Tue, 16 Sep 2003 21:20:08 -0400 (EDT) DL From: David Lesher DL Verisign Move to Mean More Spam DL DL Will that do for a hook? s,to,could, and I'll bite. Gotta keep it factual. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
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: 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: 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: Root Server Operators (Re: What *are* they smoking?)
On 17 Sep 2003, Paul Vixie wrote:
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.
With enough levels of indirection any computing problem can be solved.
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?
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; };'
And make it default configuration for new bind releases...
On 17 Sep 2003, Paul Vixie wrote:
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.
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: Root Server Operators (Re: What *are* they smoking?)
At 05:26 PM 16-09-03 -0400, Damian Gerow wrote: Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large. http://news.com.com/2100-1032_3-5077530.html -Hank
Re: Root Server Operators (Re: What *are* they smoking?)
SD Date: Wed, 17 Sep 2003 00:48:09 -0400 (EDT) SD From: Sean Donelan SD So, Verisign just returns a NS pointer to another name server SD Verisign controls which then answers the queries with SD Verisign's helpful web site. Queries for random zones make a nice starting point. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Root Server Operators (Re: What *are* they smoking?)
Yep, it went up around 6 pm ET on Tuesday. The list was a tremendous help, BTW. I don't think any folks who have followed these threads will find anything especially new in the article, but it may serve as a decent summary. ICANN's Mary Hewitt did tell me that they'd have a statement out in a few days. After a few hours of back and forth, Commerce decided to refer calls to ICANN and Verisign, though I've sent them a list of followup questions that, just maybe, they'll answer on Wednesday. Best, Declan On Wed, Sep 17, 2003 at 08:23:40AM +0200, Hank Nussbacher wrote: At 05:26 PM 16-09-03 -0400, Damian Gerow wrote: Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large. http://news.com.com/2100-1032_3-5077530.html -Hank
Re: Root Server Operators (Re: What *are* they smoking?)
On Wed, 17 Sep 2003, Paul Vixie wrote: 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. Verisign is on public record as saying many things over the years. 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? Or interesting sites that Verisign has a relationship with? What would it do to website's Keynote performance to eliminate another name lookup by having their www.something.com records served directly from Verisign's gtld-servers? Of course, ISC's non-standard BIND change will break Verisign's attempt to improve the Internet's performance by including A records in the .COM/.NET zones. Verisign's lobbyists are 3,000 miles closer to Washington DC than ISC's lobbyists. And history has demonstrated what Verisign lacks in Internet clue, they make up for in Washington clue. I wouldn't be surprised if tomorrow, Verisign is the playing the victim and calling ISC the out-of-control hooligans.
What *are* they smoking?
A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. -- Niels.
Re: What *are* they smoking?
On Tue, 16 Sep 2003, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. Tim Wilde -- Tim Wilde [EMAIL PROTECTED] Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: What *are* they smoking?
A wildcard A record in the net TLD. It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. This is sufficiently technically and business slimy that I would null-route that IP, personally. -george william herbert [EMAIL PROTECTED]
Re: What *are* they smoking?
Once upon a time, Niels Bakker [EMAIL PROTECTED] said: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. Yep, and it'll be coming soon to .com. All your typo domain are belong to Verisign. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: What *are* they smoking?
On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. I would say time to null route this horribly inappropriate scam, but it looks like a few cable modem providers have already done so, and I am no longer seeing it in the .com zone (but I still see it under .net). -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: What *are* they smoking?
On 9/15/03 3:56 PM, Niels Bakker [EMAIL PROTECTED] wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. -- Niels. http://www.cbronline.com/latestnews/d04afc52ae9da2ee80256d9c0018be8b Mike -- Michael K. Smith NoaNet 206.219.7116 (work) 206.579.8360 (cell) [EMAIL PROTECTED]http://www.noanet.net
Re: What *are* they smoking?
On Monday, September 15, 2003, at 07:11 PM, George William Herbert wrote: A wildcard A record in the net TLD. It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. This is sufficiently technically and business slimy that I would null-route that IP, personally. Nah, just route it to a Linux box with transparent proxy and show your own 'Websites-R-Us' page to your customers.
RE: What *are* they smoking?
-BEGIN PGP SIGNED MESSAGE- Tim Wilde wrote: On Tue, 16 Sep 2003, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. Even worse of this is that you can't verify domain names under .net any more for 'existence' as every .net domain suddenly has a A record and then can be used for spamming... From: Spammer [EMAIL PROTECTED] To: You [EMAIL PROTECTED] Thank you Verisign! Now we need to check for existence of an MX and then just break a couple of RFC's in the process :( It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. Who said the internet wasn't commercial again ? Thank you goverment of the United States of America for allowing such money hungry organisations to abuse one of the original tld's. Wasn't .net meant for *networks* ? aka ISP backbone infrastructure and not for commercials? (And I thought that domain reselling was a yucky business) Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP2ZIvCmqKFIzPnwjEQLQkgCgtFDU1TKOrt/tz0I+GGm+Vu/P+xUAoI+s 6Czvls9qXOslOkOnJXLhU8ZC =sC7+ -END PGP SIGNATURE-
Re: What *are* they smoking?
Once upon a time, Richard A Steenbergen [EMAIL PROTECTED] said: On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote: $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 I would say time to null route this horribly inappropriate scam, but it looks like a few cable modem providers have already done so, and I am no longer seeing it in the .com zone (but I still see it under .net). Someone has already brought up the idea on the BIND list of modifying BIND to recognize this response and converting it back to NXDOMAIN. Blackholing the IP means that your customers will get an error that the site is unreachable, not that it does not exist. BTW: I got a content filter message bounce in response to my other post on this topic - anyone else get that? I didn't see anything in my message that looked filter-worthy to me. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: What *are* they smoking?
It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. I am guessing that given the relatively light penalty Register.com got for its Coming Soon web pages, Verisign was encouraged to try the same thing and will probably be glad to take the same penalty. Deepak Jain AiNET
Re: What *are* they smoking?
A wildcard A record in the net TLD. It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. This is sufficiently technically and business slimy that I would null-route that IP, personally. The bigger issue is DNS troubleshooting.what a nightmare when a query of the *.gtld-servers.net servers does not return an error. What happens when they change the IP because of null-route'ing of the current IP to a completely different /8 subnet. Who engineered this! Or better yet, who allowed this blatant commercial use of the TLD servers. /disgusted Mark Vallar
Re: What *are* they smoking?
-- On Tuesday, September 16, 2003 00:56 +0200 -- Niels Bakker [EMAIL PROTECTED] supposedly wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. No, it accepts if the from domain exists - but only if it *REALLY* exists. [...] rcpt to: [EMAIL PROTECTED] 250 OK mail from: [EMAIL PROTECTED] 550 User domain does not exist. mail from: [EMAIL PROTECTED] 250 OK Nice that their spam filters still work. :( And I love the 221 close message: data 221 snubby1-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host. -- TTFN, patrick
RE: What *are* they smoking?
On Tue, 16 Sep 2003, Jeroen Massar wrote: -BEGIN PGP SIGNED MESSAGE- Tim Wilde wrote: On Tue, 16 Sep 2003, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. Even worse of this is that you can't verify domain names under .net any more for 'existence' as every .net domain suddenly has a A record and then can be used for spamming... From: Spammer [EMAIL PROTECTED] To: You [EMAIL PROTECTED] Thank you Verisign! Now we need to check for existence of an MX and then just break a couple of RFC's in the process :( What about if the IP address returned by the DNS query is the same one as does.really-not-exist.net then the spam is returned to the owner of the IP address? In this case Versign. I think this is already done by some automated spam reporting tools. If AOL does it Verisign will probably get crushed by the load (if one is having a spam war with AOL's mail servers AOL will always win). It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. Who said the internet wasn't commercial again ? Thank you goverment of the United States of America for allowing such money hungry organisations to abuse one of the original tld's. Wasn't .net meant for *networks* ? aka ISP backbone infrastructure and not for commercials? That has been going on for several years now (unfortunately). (And I thought that domain reselling was a yucky business) Yep, but it can be profitable. I'm just waiting for someone to put out a typo in a large press release and then sue Verisign for stealing all the traffic. According to the article in the link posted from cbronline.com this has been done by NeuStar who runs the .biz and .us domain registries. The company which runs this service for NeuStar claims to be able to differentiate between http and other requests. I'm still waiting to see how they do this as you can't tell from a DNS request alone. bye, ken emery
Re: What *are* they smoking?
On Mon, 15 Sep 2003, Chris Adams wrote: Someone has already brought up the idea on the BIND list of modifying BIND to recognize this response and converting it back to NXDOMAIN. That would be me -- I posted to comp.protocols.dns.bind, not realizeing it was a mailing list gateway. 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 ! At the least we need a way for MTA's to reject mail from domains that resolve to this nonsense. Having bind put NXDOMAIN back would be a plus. -Chris == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: What *are* they smoking?
-- On Monday, September 15, 2003 19:30 -0400 -- Mark Vallar [EMAIL PROTECTED] supposedly wrote: The bigger issue is DNS troubleshooting.what a nightmare when a query of the *.gtld-servers.net servers does not return an error. What happens when they change the IP because of null-route'ing of the current IP to a completely different /8 subnet. Anyone wanna patch BIND such that replies of that IP addy are replaced with NXDOMAIN? That solves the web site and the spam problem, and all others, all at once. -- TTFN, patrick
Re: What *are* they smoking?
On Tue, Sep 16, 2003 at 01:18:26AM +0200, Jeroen Massar wrote: Even worse of this is that you can't verify domain names under .net any more for 'existence' as every .net domain suddenly has a A record and then can be used for spamming... From: Spammer [EMAIL PROTECTED] To: You [EMAIL PROTECTED] Thank you Verisign! Now we need to check for existence of an MX and then just break a couple of RFC's in the process :( Checking for NS or SOA record(s) is sufficient, neither are being returned, only A records. Of course, you could just block anything that resolves to netsol. -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203 pgp0.pgp Description: PGP signature
