Andrew Sullivan wrote:
> On Thu, Mar 26, 2009 at 12:16:41AM -0700, Doug Barton wrote:
>  
>> Here is where the alarm bells go off in my head. From 4035, Section 3.1.6:
>>      A security-aware name server MUST NOT set the AD bit in a
>>      response unless the name server considers all RRsets in the
>>      Answer and Authority sections of the response to be authentic.
>>
>> (Also see 3.2.3, and the rules for validation in Section 5.)
> 
> Yes.  But 3.1.6 also says
> 
>    […] A security-aware
>    name server's local policy MAY consider data from an authoritative
>    zone to be authentic without further validation.  However, the name
>    server MUST NOT do so unless the name server obtained the
>    authoritative zone via secure means (such as a secure zone transfer
>    mechanism) and MUST NOT do so unless this behavior has been
>    configured explicitly.
> 
> So AD doesn't mean "I validated this", but rather "I know this is
> valid". 

That is a pretty large (and I believe unwarranted) leap in logic.
There is a world of difference between "I am authoritative for this
zone" and "I validated a response I got from an authoritative server
and then glued stuff onto it."

> The translating validator _can_ know it's valid: it validated
> the "base" A record, and then performed a translation using the data
> it also has by secure means (the sysadmin configured it that way, or
> it obtained the prefix via some secured connection, or something like
> that).  

Now you're back to the local policy argument. Wouter already mentioned
additional concerns about your statement "obtained the prefix via some
secured connection" that make me even more queasy.

>  > Furthermore, NAT64/DNS64 already provides a mechanism for the owner of
>> the v4-only host to set up the translation on _their_ end, which could
>> of course include proper DNSSEC signatures on the AAAA records for
>> their NAT64 box.
> 
> Remember that what we're trying to do is provide a (nasty) connection
> between two completely different networks: there's the v4 network, and
> there's the v6 network.  The claim is that we need to find a way to
> make people on the v6-only network reach hosts that are in a v4-only
> network.  If you disagree with the assumption, that's the one you need
> to attack.  (The response, I expect, will probably be something like,
> "Operators tell us they need this."  Also, the discussion certainly
> doesn't belong on dnsop -- this message itself is, I suspect, already
> past far enough.)  One basic assumption is that you can't force (or
> convince) the v4 end nodes to do anything. 

I "get" what your goal is. I also "get" the value in achieving that
goal for the common case. What you're trying to argue is that for this
particular edge case the benefit of achieving the goal outweighs
whatever cost may be associated with violating the protocol regarding
the AD bit. So far I remain unconvinced.

> Relying on people to do
> the right thing has gotten us where we are with v6, and I think what
> people are hoping for is some way to make it not the case that "just
> use v6 and no more v4" means "lose all the resources currently on the
> v4 network".

This area is where I believe our opinions diverge pretty widely, but I
agree with you that discussion of these problems is off topic for
dnsop. (That said, please keep in mind that I'm approaching this as a
strong advocate of v6 adoption.)

>> That's great if I'm in the 1% of Internet users that actually can
>> connect directly to anything. If I'm in the other 99% (yeah, I'm
>> exaggerating) then there is almost certainly some kind of middleware
>> box between me and the rest of the Internet controlled by (you guessed
>> it) _local policy_. Given that I already have to trust whoever is
>> running the network (or built the box) to deal honestly with my
>> packets as they go from my host, through locally controlled
>> middleware, out to the Internet, and back; what harm does a "local
>> policy" of setting the AD bit for synthesized DNS64 answers cause?
> 
> Well, sure, if someone can rewrite you're packets you're in big
> trouble.  On the other hand, there's only so much damage such a case
> can do without being detected.

Actually if I can rewrite your packets AND set the AD bit on your DNS
responses I basically 0wn you, even in a world where the OS,
application, and human layers all understand and care about DNSSEC
(modulo the CD bit of course, but that's off topic for this particular
discussion).

At this point I think I've said my piece, I'd like to encourage others
to jump in.


hope this helps,

Doug
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to