At 16:33 13/01/2010, Edward Lewis wrote:
At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote:
The benefit is that a single query can retrieve the signed root NS set
and all the signed glue records.
I am not certain that the cost of doing TCP for this is worth the
benefit of getting a signed priming response. I agree with section
2.4 - no DO bit.
What does a DNSSEC-protected priming query gain you?
Accepting any old priming query and having a root SEP configured, if
the query is right all things work. If the query is wrong/forged
you won't get anywhere any how. (Without going into the weeds here
- what if one IP address were forged, what if it were 6, 16, or all of them?)
(13 name servers => 13 A records + 7 AAAA records last check)
Besides the warm and fuzzy feeling, what do you gain? (Keep in mind
all of the TCP traffic it would take to get warm and fuzzy.)
Well having TCP used for all priming queries would make me feel better
as TCP traffic is harder to forge.
But seriously DNSSEC signed and validated data should protect the
the resolver from going to the forged addresses.
Yes someone can forge the answer and DoS the resolver into believing that
nothing works.
The situation is "." and root-servers.net. zones are hosted on the
root servers, thus the same servers will get all follow-up questions
about signed address sets as the priming query.
Resolvers like to ask the "close" servers for information thus it
is almost certain that over time the resolver will send a question
to all root servers.
Based on this I think one TCP connection is better than 14-27
UDP ones. (Resolver that only supports one transport should never
ask for the address records it will not use).
We can even take this one step further and ask both priming questions
over the same TCP connection that is NS and DNSKEY.
Ed in my mind this is straight forward engineering question,
which approach is better as in cheaper/faster/safer.
At 16:05 -0500 1/13/10, Olafur Gudmundsson wrote:
Why not ask for signatures ?
Same reason it is no longer fashionable to include keys in signed
responses - signatures are a big load. Yes, you'll know sooner if a
server's IP address is a problem, but you'd figure it out before it
mattered anyway (if you ever use that server).
--
This is totally different.
Adding DNSKEY to "random" answers was an "optimization" in trading
off answer size vs delay in first verification for a zone.
The choice made by early RFC's and implementations was the wrong
one for the Internet we have today, where UDP fragments have high
chance of not getting through.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
