[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnssec@cafax.se
From: Miek Gieben <miekg@atoom.net>
Date: Mon, 10 May 2004 21:11:39 +0200
Content-Disposition: inline
In-Reply-To: <200405101858.i4AIw6b03693@boreas.isi.edu>
Mail-Followup-To: dnssec@cafax.se
Sender: owner-dnssec@cafax.se
User-Agent: Vim/Mutt/Linux
Subject: Re: dnssec: resolver - application communication

[On 10 May, @20:58, Bill wrote in "Re: dnssec: resolver - applica ..."]
> % [I'm using this list to start the discussion about it, rathen than
> % starting a new list (i'm on too many ML already :) )]
> 
> 	retro-fitting an old list to discuss the things the list was
> 	created for... how very odd :)

:-) don't blame me, I wasn't even around when this list was created... :)

> % pounding on the authoritative servers on the Internet. Most notably the secure
> % entry points, which will be root in some future. In short: this will most
> % probably break the DNS.
> 
> 	Not at all.  you only need to "get more" if the validation
> 	fails.  This was hammered home to me @ the SLC IETF.  If

how do you know validation fails if you only have SERVFAIL. If you
want to get more, you will always have get more on SERVFAIL.

> % SERVFAIL we indicate an attack - I don't care what kind of attack. I only need
> % to know there is one going on right now. Then I can fire up my dig++ and look
> % what is really happening. 
> 
> 	dig++ needs access to more data than you wish to mask w/
> 	SERVFAIL, no?   

I see your point, but what I meant with that is that you can go and
look for yourself on the Net. Like going out and asking the
authoritative servers for more information, instead of your local
cache.

grtz,
--Miek

--
today's fortune:
  Referring to a book: I read part of it all the way through.
  -Samuel Goldwyn

Home | Date list | Subject list