Re: some comments on draft-ietf-dnsext-forgery-resilience-01.txt

[bert hubert <[e-mail]>]

On Tue, Aug 14, 2007 at 12:09:24PM -0400, Edward Lewis wrote:

> #   5.  It is the first answer to match the previous four conditions.
> #
> #   Note that the fifth condition can strictly speaking be derived from
> #   the first.  It is included for clarity reasons only.
> 
> In the reading it seems that the text is from RFC 1034/5.3.3 (which 
> refers only to earlier lines apparently).  I went back and forth 
> trying to find the source of this until I realized it is probably an 
> interpretation and not the source.

We do quote a bit from section 5.3.3 of RFC 1035, and this bit is indented.
The other lines, 1. through 5., are our own invention.

I've updated the xml a bit to clarify where the quote from RFC 1035 ends:

-           Section 5.3.3 of <xref target="RFC1034"/> presaged the present problem:
+           The following sentence in section 5.3.3 of <xref
target="RFC1034"/> presaged the present problem:

> Given that most sniffer based attacks are based on being closer to 
> the querier than the proper responder, I would look for the last 
> answer to match.  Of course, that is only theoretically possible as 
> you will never know if any event is the last time it happens.  Like 
> Elvis sightings.

That would be a good suggestion except in real life :-)

> The Note also is confusing. I don't see how you derive #5 from #1.

Indeed. It originally stated you could derive the fifth condition from the
first, where first was intended to be plural, and denote 1-4. But even that
is not true. Removed the note.

> #4.5.  Have the answer arrive before the authentic answer
> #
> #   Once any packet has matched the previous four conditions, no further
> #   answers should be accepted.
> 
> This is a strategy I disagree with, kinda.  If TSIG or DNSSEC is 
> used, responses matching the first four conditions ought to be queued 
> up until the answer has passed TSIG or DNSSEC checking.  This allows 
> these techniques to not just detect errors but detect and deflect 
> until the right answer comes (within the timeout).

Well, I'd hate to sprinkle TSIG and DNSSEC exceptions all over the document.
I'd rather have that this document updates RFC 1035, and tries not to
engtangle itself with other developments.

> #before applying DNS credibility rules.
> 
> RFC 2181 has trustworthiness rules, the are TSIG and DNSSEC rules.  I 
> don't know of other "DNS credibility rule" sets.  You probably at 
> least need a reference there.

Well spotted - I copy pasted this section from elsewhere, and didn't fully
verify it.

> #   The document can not require the use of either multiple ports or
> #   addresses as that is an operational issue and should be addressed in
> #   a separate document in DNSOP.
> 
> Don't let IETF document bureaucracy get in the way of a good story!

Thanks - I agree fully. Unsure what to do about it though..

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>