The Register says:
Verisign have added a wildcard entry to the .com / .net TLD DNS.
[ol][li] There is no longer any such thing as a non-resolving .com / .net domain.[/li]
[li] This compromises a fundamental method of anti-spam checking.[/li]
[li] This increases the complexity and required bandwidth for a robot crawler to identify non-operational links.[/li]
[li] The majority of internet users (May 2003: 93% -
use Microsoft's IE5 browser or above, which already incorporates a search feature similar to Verisign's implementation.[/li]
[li] Patches have already been developed for various BIND implementations which deliberately ignore the wildcard response, and so introduce a level of inconsistency into the DNS system.[/li]
[li] Most importantly, this implementation contravenes the defined DNS standard: RFC1034:[/li][/ol]
// quote ( available from: ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt ) //
If recursive service is requested and available, the recursive response to a query will be one of the following:
- The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.
- A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist.
- A temporary error indication.
If recursive service is not requested or is not available, the non-recursive response will be one of the following:
- An authoritative name error indicating that the name does not exist.
- A temporary error indication.
- Some combination of:
RRs that answer the question, together with an indication whether the data comes from a zone or is cached.
A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply.
- RRs that the name server thinks will prove useful to the requester.
// end quote //
Basically, when a client requests DNS resolution from a DNS server, the server uses either a recursive or non-recursive method of resolution. In either case, where the domain name does not exist, the expected response is 'an authoritative name error indicating that the name does not exist'. This is not the case with the current wildcard implementation.
Is verisign abusing it's trusted position for profit?
I see this as a fundamentally wrong move - any other thoughts?
<marc> i wonder what will happen if i press this...[ul][li]please give feedback on what works / what doesn't[/li][li]need some help? how to get a better answer: faq581-3339[/li][/ul]
Verisign have added a wildcard entry to the .com / .net TLD DNS.
[ol][li] There is no longer any such thing as a non-resolving .com / .net domain.[/li]
[li] This compromises a fundamental method of anti-spam checking.[/li]
[li] This increases the complexity and required bandwidth for a robot crawler to identify non-operational links.[/li]
[li] The majority of internet users (May 2003: 93% -
use Microsoft's IE5 browser or above, which already incorporates a search feature similar to Verisign's implementation.[/li]
[li] Patches have already been developed for various BIND implementations which deliberately ignore the wildcard response, and so introduce a level of inconsistency into the DNS system.[/li]
[li] Most importantly, this implementation contravenes the defined DNS standard: RFC1034:[/li][/ol]
// quote ( available from: ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt ) //
If recursive service is requested and available, the recursive response to a query will be one of the following:
- The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.
- A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist.
- A temporary error indication.
If recursive service is not requested or is not available, the non-recursive response will be one of the following:
- An authoritative name error indicating that the name does not exist.
- A temporary error indication.
- Some combination of:
RRs that answer the question, together with an indication whether the data comes from a zone or is cached.
A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply.
- RRs that the name server thinks will prove useful to the requester.
// end quote //
Basically, when a client requests DNS resolution from a DNS server, the server uses either a recursive or non-recursive method of resolution. In either case, where the domain name does not exist, the expected response is 'an authoritative name error indicating that the name does not exist'. This is not the case with the current wildcard implementation.
Is verisign abusing it's trusted position for profit?
I see this as a fundamentally wrong move - any other thoughts?
<marc> i wonder what will happen if i press this...[ul][li]please give feedback on what works / what doesn't[/li][li]need some help? how to get a better answer: faq581-3339[/li][/ul]