Posts Tagged ‘htacess’

wildcard

Monday, June 30th, 2008

i get invloved of making sub domain redirection ,

so i googled it and found that’s need wildcard to activited , what wildcard :S

so i found that :

The DNS “wildcard” mechanism has been part of the DNS protocol since the original specifications were written twenty years ago, but the capabilities and limitations of wildcards are sufficiently tricky that discussions of both the protocol details of precisely how wildcards should be implemented and the operational details of how wildcards should or should not be used continue to the present day. This section attempts to explain the essential details of how wildcards work, but readers should refer to the DNS specifications ([RFC 1034] et sequentia) for the full details.

In essence, DNS wildcards are rules which enable an authoritative name server to synthesize DNS resource records on the fly. The basic mechanism is quite simple, the complexity is in the details and implications.

The most basic and by far the most common operation in the DNS protocols is a simple query for all resource records matching a given query name, query class, and query type. Assuming (for simplicity) that all the software and networks involved are working correctly, such a query will produce one of three possible results:

success
If the system finds a match for all three parameters, it returns the matching set of resource records;

no data
If the system finds a match for the query name and query class but not for the query type, it returns an indication that the name exists but no data matching the given query type is present.

no such name
If the system fails to find a match for the given query name and query class, it returns an indication that the name does not exist.

Ordinarily, matches for all three parameters must be exact. This is where wildcards come into the picture.

A wildcard record is an otherwise ordinary DNS resource record whose leftmost (least significant) label consists of a single asterisk (”*”) character, such as “*.bar.example”. Conceptually, the asterisk matches one or more labels at the left (least significant) end of the DNS name.

When wildcard records are present, the rules become more complicated. Specifically, if the query class matches, there is no exact match for the query name, and the closest match for the query name is a wildcard, the system in effect synthesizes a set of resource records matching the query name on the fly by treating the resource records present at the wildcard name as if they had been present at the query name. Thus, if the wildcard name has records matching the desired query type, the system will return those records, precisely as in the “success” case above; otherwise, the system will return an indication that the name exists but no data matching the given query type is present, precisely as in the “no data” case above. The response is identical to that of a normal “success” response for the query name, so the resolver which issued the query can not tell that the results it got back were the result of wildcard expansion.

Note that, in the case of a wildcard match, the “no such name” case cannot occur; the wildcard match eliminates this possibility. Note also that only the query name and query class matter for purposes of determining whether a wildcard matches: any record type can produce a wildcard match, regardless of whether or not the record type happens to match the query type.

so in brief it enable redirect sub domain which not realy created to  ceratian page using htaccess .

i contacted my hosting and waiting thier answer

Share/Save