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.

Rattle wrote:

] ] *.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.

Oops ... it would look more like this:

_http._tcp.*.com IN SRV ...

in other words, for every domain q.com, synthesize a record _http._tcp.q.com

A client asking for the HTTP SRV record for a non-existant domain would get sitefinder; a client asking for the A would get NXDOMAIN.

bucy wrote:
] ] The SRV RR allows administrators to use several servers
] ] for a single domain, to move services from host to host
] ] with little fuss, and to designate some hosts as primary
] ] servers for a service and others as backups.
]
] 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.

This is a very interesting approach to the sitefinder problem. John, if you make it to Phreaknic I'm willing to give you some of my speaking time to talk about this.

U: I guess one concern is this still creates problems for HTTP based XMLRPC services, which will get a "no XML service on this webserver" error instead of a "host not found" error. (Of course, one could ask that xmlrpc lookup _xmlrpc._tcp.*...