On Nov 21, 2006, at 1:59 AM, Michael.Dillon@xxxxxxxxxxxxx wrote:
If someone wants to add a new RR type to their DNS server, and
their server cannot handle it, then they can simply replace/
upgrade their server.
And if someone wants to leverage the DNS protocol and DNS server
software in order to operate a global distributed database, then
there are no barriers to doing this on ports other than port 53.
The IETF barely needs to be involved at all other than defining the
new RR.
Any opinions on port 3450? A DNSified name space of a peer to peer
matrix offering data structures to navigate NATs. Is this a perfect
bot-net tool? DNS on different ports might still involve the IETF,
while offering little information for assessing risks.
But when someone suggests that port 53 servers should all support
some new RR or anything else that is new, now we are talking about
a major upgrade to the Internet's mission critical infrastructure
impacting millions of people worldwide. Here the IETF has a major
role to play and the IETF should tread very carefully.
Design compromises for DKIM's TXT RR increases DNS cache allocations
by 34%. A label prefix for key rotation permits any number of keys
per domain, even one per customer. Per customer deployment of keys
may have a dramatic impact upon DNS resources, where the scale of
such deployment would exacerbate the TXT RR choice. Signature roles
are not identified and there are no limits on the number of
signatures per message either. The follow-on effort for DKIM expects
matching From/signing-domains and DNS authorization records that are
hunted when not found.
Being careful should mean making the most of a single signature/key
without added searches. An association scheme with a signing domain
eliminates a need for a key per customer (or different originating
domains), while also providing customers greater freedom of choice.
Associations also ensure abuse-reporting goes to the transmitting
entity. An association/annotation scheme provides greater protection
against phishing (even look-alikes), while also eliminating a need
for DNS authorization scans.
Making poor follow-on choices are not really a fault of the DKIM
concept. However, caution is is often a distant concern in (futile)
efforts to close a door that must remain open by design. Even when
DKIM signing is limited to the transmitting domains, verification of
a signature should occur only when an associated and desirable domain
affects message annotation or DSNs. Unfortunately, building DKIM
related obstacles for email might place DNS at risk. This does not
need to be the fate for DNS and DKIM, but it might be.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf