Create an Account
username: password:
  MemeStreams Logo

Spontaneous Sociability and The Enthymeme


Picture of Rattle
Rattle's Pics
My Blog
My Profile
My Audience
My Sources
Send Me a Message

sponsored links

Rattle's topics
   Sci-Fi/Fantasy Literature
  Tech Industry
  Telecom Industry
Health and Wellness
   Using MemeStreams
Current Events
  War on Terrorism
Local Information
  SF Bay Area
   SF Bay Area News
  Nano Tech
  International Relations
  Politics and Law
   Civil Liberties
    Internet Civil Liberties
   Intellectual Property
   Computer Security
   PC Hardware
   (Computer Networking)
   Software Development
    Open Source Development
    Perl Programming
    PHP Programming
   Web Design
  Military Technology
  High Tech Developments

support us

Get MemeStreams Stuff!

Current Topic: Computer Networking

Topic: Computer Networking 12:06 pm EDT, Oct 20, 2003

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

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


RE: A DNS RR for specifying the location of services (DNS SRV) (RFC2782)
Topic: Computer Networking 2:28 am EDT, Oct 20, 2003

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 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 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)

Internet Architecture Board - Architectural Concerns on the use of DNS Wildcards
Topic: Computer Networking 9:07 pm EDT, Sep 20, 2003

] 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

VeriSign sticks with redirect service | CNET
Topic: Computer Networking 6:59 pm EDT, Sep 18, 2003

] 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

Welcome to Cymru.COM!
Topic: Computer Networking 12:06 am EDT, Aug 15, 2003

] 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!

DNS Stuff: DNS tools, WHOIS, tracert, ping, and other network tools.
Topic: Computer Networking 10:19 pm EDT, May 27, 2003

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.

(Last) Newer << 1 - 2 - 3 >>
Powered By Industrial Memetics