caching only + wildcard

[Kevin Darcy]

NXDOMAIN isn't user-friendly. But then it's not meant to be. It exists 
at the infrastructure level. It's up to the browser or other client 
software to present that NXDOMAIN as something that the user can 
understand and deal with. If an ISP wants to distribute a browser plugin 
"NXDOMAIN helper", complete with dancing .gifs, flash animation, or 
whatever, I'd have no problem with that.

But, IMO, giving false answers to DNS queries, as a default, is the 
*wrong* way to go, whether it's a TLD server doing it, or the resolvers 
provided on a "consumer" connection. And the argument of "well they can 
use somebody else's nameservers" is not only often problematic from a 
security/trust perspective (how do they know you're not some malicious 
DoS'er?), and thus *blocked* on a lot of "consumer" connections, but 
it's also several steps along the path towards "well they can use a 
different ISP entirely". Does it make business sense, to drive your most 
sophisticated customers, into the arms of your competitors? What does 
that do to your word-of-mouth referrals?

Moreover, doing this by default essentially imposes an "opt-out" rather 
than an"opt-in" model for this "fake but helpful" resolution. We 
generally don't accept the "opt-out" model for SPAM, why would we accept 
it for the (dis)integrity of our ISP's name-resolution service?

"Please check this box if you want your ISP's nameservers to tell the 
truth".

- Kevin

Chris Buxton wrote:
> As we discussed just about 6 weeks ago on this very list... OpenDNS  
> does this. I forget what product they're using to do it, but it's  
> available. Your competitors are already using it, as you noted.
>
> NXDOMAIN (and NXRRSET) responses are not user-friendly. Using a custom  
> name server, combined with a web server setup, that does what you're  
> looking for seems like reasonably good business sense to me. Microsoft  
> started working this angle with IE years and years ago, at the client  
> level, notwithstanding that it annoys the heck out of us  
> professionals. It gives end-users a better idea of what happened than  
> simply returning, "That domain does not exist." You wouldn't be  
> forcing your users to use your resolvers - anyone with the knowledge  
> and experience to understand what you would be doing has the ability  
> to change their TCP/IP settings to use other DNS servers.
>
> Furthermore, anyone running a service should not be using name servers  
> like these for service-related lookups (reverse lookups, MX record  
> lookups, etc.). But those customers should probably not be using a  
> consumer-grade net connection, either.
>
> Normally I would agree with the "don't mess with DNS" argument. But  
> normally on this list, we're talking about authoritative name service.  
> This thread relates to resolution for customers of a consumer-grade  
> network connection. It's a totally different equation, and is  
> completely different from Site Finder.
>
> The strongest language I would agree with in this discussion is,  
> document the behavior for your customers, and give your customers a  
> way to opt out.
>
> Chris Buxton
> Professional Services
> Men & Mice
>
> On Jun 26, 2008, at 2:42 PM, idanj wrote:
>
>   
>> Hi Josh,
>>
>> Since most of the large ISPs (RR, earthlink) already do it, I don't
>> think a small ISP like us would make any difference.
>>
>> Due to increasing we must find new ways of making money.
>>
>> And actually our solution will HELP our users because we plan to give
>> them a link to the original website that we think they were looking
>> for.
>>
>> Thanks
>> Idan
>>
>> On Jun 26, 9:05 pm, "Josh Smith" <juice... at gmail.com> wrote:
>>     
>>> This is typically a bad idea - dns is used for more than just  
>>> browsing the web.
>>>
>>> See the site finder fiascohttp://en.wikipedia.org/wiki/Site_Finder
>>>
>>> Please do not break the DNS in this manner for your users.
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>>
>>> On Thu, Jun 26, 2008 at 9:34 AM, idanj <idan.... at gmail.com> wrote:
>>>       
>>>> Thank you for your reply, and sorry for not being clear. I'll try to
>>>> explain again.
>>>>         
>>>> We are a small ISP.
>>>>         
>>>> We want to display a friendly message to our users whenever they are
>>>> trying to access a non existent domain.
>>>>         
>>>> So the flow we were thinking about is:
>>>> 1. User queries our (caching-only) NS
>>>> 2. Our NS checks the root servers and get a "NXDOMAIN" reply.
>>>> 3. We return to the user an A RECORD with the IP address of our  
>>>> server
>>>> 4. The user goes to that IP address and gets our error message.
>>>>         
>>>> So we basically want the ability to add a wildcard record to our NS,
>>>> but have that wildcard catch ONLY when our NS gets an NXDOMAIN reply
>>>> from the root server.
>>>>         
>>>> I hoped I explained myself OK this time.
>>>>         
>>>> Thanks again
>>>> Idan
>>>>         
>>>> On Jun 26, 2:29 am, Kevin Darcy <k... at chrysler.com> wrote:
>>>>         
>>>>> idanj wrote:
>>>>>           
>>>>>> Hello all,
>>>>>>             
>>>>>> We have 2BINDname servers configured as "caching-only".
>>>>>>             
>>>>>> Is it possible to set a wildcard A record ("catch all") on a these
>>>>>> name server?
>>>>>>             
>>>>>> The problem is that when the server gets a query for a domain that
>>>>>> doesn't exist in its cache, the server will return the wildcard  
>>>>>> reply
>>>>>> instead of checking the root servers first.
>>>>>>             
>>>>> I'm confused about what you're trying to accomplish here. Are you  
>>>>> saying
>>>>> "return a wildcard record any time the answer is not in cache"?  
>>>>> Even if
>>>>> that were possible, how would you expect to *ever* get anything  
>>>>> into
>>>>> your cache in that case? Bear in mind that a caching-only  
>>>>> nameserver
>>>>> typically starts up with *nothing* in its cache, just some "hints"
>>>>> information about where to find root nameservers. If you give  
>>>>> back a
>>>>> wildcard record for everything not in cache, then there's no  
>>>>> reason to
>>>>> *ever* go out and resolve *anything* or cache *anything*. You  
>>>>> just give
>>>>> the wildcard record for every query. You might as well be not even
>>>>> connected to the Internet.
>>>>>           
>>>>> I must be missing something here. Could you please clarify?
>>>>>           
>>>>> Are you perhaps using the term "cache" to also cover
>>>>> *authoritative*data*, i.e. where your (so-called) "caching-only"
>>>>> nameserver is also master or slave for certain select zones, and  
>>>>> you
>>>>> want everything *else*, not in those zones, to get a wildcard  
>>>>> response?
>>>>> In that case, maybe your requirement might make sense...
>>>>>           
>>>>> Or, could it be that you're trying to set up a DNS infrastructure  
>>>>> on an
>>>>> internal network, that has no connectivity to the Internet? If  
>>>>> so, then
>>>>> you're approaching it the wrong way. You don't want "wildcards" to
>>>>> prevent your nameservers from going out and trying to talk to the
>>>>> Internet root nameservers; what you want is to set up your *own*  
>>>>> private
>>>>> root zone, and point all of your nameservers at that root zone  
>>>>> instead
>>>>> of the Internet version.
>>>>>           
>>>>>                           - Kevin
>>>>>           
>>> --
>>> Josh Smith
>>> email/jabber: juice... at gmail.com
>>> phone: 304.237.9369(c)
>>>
>>> () ascii ribbon campaign - against html e-mail
>>> /\www.asciiribbon.org- against proprietary attachments
>>>       
>>     
>
>
>
>
>