] // getsrvbyname.c -- A trivial implementation of a DNS
] // SRV [RFC2782] resolver.

Here's Bucy's code. Probably buggy. BSD license.

getsrvbyname()

Bucy suggests using SVR tags to implement the passing of clues, for lookup services like SiteFinder.

] Unfortunately, noone uses them. I claim that the main reason
] for this is the lack of support in (free (not GPL)) resolver
] libraries. I have a minimally working implementation that I
] will probably release under a BSDish license in the next few
] days.
]
] SRV records might, for example, make sitefinder much less bad;
] if the wildcard were
]
] *.com IN SRV host=sitefinder.verisign.com port=80 priority=1
] weight=1
]
] rather than
]
] *.com IN A ...
]
] I expect that the effects would be much less disruptive, i.e.
] browsers would be redirected but everything else would not.
]
] So first, we have to get resolvers out there and then we need
] to get software fixed. Who's with me?

This sounds like a good idea Bucy. (Although I would still argue that lookup services like this should be in the browser, and not a function of the DNS system.) This is a reasonable middle ground, and most importantly its an acceptable solution that it may be possible to force VeriSign into. I'm sure SiteFinder, as a product, will wind up thrust in front of many eyeballs before we see the end of it. That's also not the problem. The problem is the current implementation breaks Internet standards.

The DNS give authoritative answers to questions. Nothing about this wildcard is authoritative. Your solution is. Its telling me what the resource is in a context where I know what it is. At the protocol level, I know I'm not getting exactly what I asked for, but I can get something that will help me. And that is what SiteFinder is. Under your scheme, its no longer theft and false representation. Here, I can choose to use the service offered me. Not forced. And that _is_ the way business should work after all.

VeriSign does have a quasi-valid point in that innovation in this space does not happen by itself. It would have been impossible to make what you suggest happen without the current pressure created by VeriSign. However, If MS and Apple can be made to go along with this, in terms of support in their resolver libraries that gets pushed out in a planed update, its won. And I can see that being possible.

If the Internet community can present a better option, that still allows VeriSign to deploy their SiteFinder product, only in a way acceptable to us, we win. I really hate that right now I have to opt-out at the level of by local recursive DNS server. It should be able to happen at the client.

Here, there exists the ability for the user to opt-opt and the various browser to extend the feature set, override it. Its also easy to extend it to service different services.

And the key thing, its not breaking the authoritative nature of DNS system. I like.

] *.com IN SRV host=sitefinder.verisign.com port=80 priority=1
] weight=1

However, you would need a protocol="tcp" flag along with your port="80" in your example. :) There are some details that need to be hashed out, but I like the general idea.

RE: A DNS RR for specifying the location of services (DNS SRV) (RFC2782)

] This document contains a number of observations on
] the implications of the use of wildcards in DNS zones,
] and makes some recommendations concerning their use.

] The Robustness principle tells us that in some (not all) of
] the problems detailed above, both parties could be
] construed as being at fault. In some cases this is hardly
] surprising: spam filtering in particular, by its nature,
] tends to be extremely ad hoc and somewhat fragile.
] No doubt there are lessons here for all parties involved.

] The Principle of Least Astonishment suggests that the
] deployment of wildcards was disastrous for the users.
] It had widesweeping effects on other users of the
] Internet far beyond those enumerated by the zone
] operator, created several brand new problems, and
] caused other internet entities to make hasty, possibly
] mutually incompatible and possibly deleterious (to
] the internet as a whole) changes to their own
] operations in an attempt to react to the change.

] Proposed guideline: If you want to use wildcards in your
] zone and understand the risks, go ahead, but only do so
] with the informed consent of the entities that are delegated within your zone.

Internet Architecture Board - Architectural Concerns on the use of DNS Wildcards

] When asked why VeriSign did not inform the Internet's
] technical organizations of the change in advance,
] O'Shaughnessy replied: "There's not much I can add
] except to say that our testing and the resources
] we've applied toward this have been in accordance
] with prevailing industry standards for new products
] and services."

"Because they would have said no."

Ok, the ISC has patched BIND.. The AIB is against this, and has said they are now writing guidelines for running the NIC. No major anyone or anything has stood up and said this is "good". Well, aside from end-users who don't really understand that their browser should be doing what they see, not the damn heart of the DNS system. But VeriSign is going to stick to their guns though.. So this is going to be a very messy fight.

I think in the end, this is really just going to be a big loss for VeriSign. All the browsers and the ISPs are going to take this out of their hands, very fast. They will be forced into making the NIC behave again.

They must behave or be replaced. Personally, I don't think they should be running .com/.net, A, RS, anything. They cannot be trusted.

VeriSign sticks with redirect service | CNET News.com

] Documents, tools, and links of interest to technical folks.

] BGP Statistics
] DNS Statistics
] Network Response
] Time Statistics
] Blocked Packet Statistics

This site has some tools that may be interest to other people like myself, who are waiting for some random AS# in NYC to reappear on the Internet.

Welcome to Cymru.COM!

Need web-based access to WHOIS, reverse lookup, ping, tracert, spam database lookup, IP routiong info and more? Check this site out for several useful networking tools.

Making note of this for the ISP cached DNS lookup.. I've often wished I had something to point people at when explaining why their DNS settings are going to take awhile to fully take effect.

DNS Stuff: DNS tools, WHOIS, tracert, ping, and other network tools.