This message is sent in my role as chair with consent of my co-chair
but without
his editing help, thus any mistakes in this message are mine and only mine.

The large volume of message over the last 2 weeks related to how to make DNS
safer made me think about "what are all the different possible approaches?"
Below is a list of ideas I have heard mentioned or thought off.

The list is supposed to be as complete as possible, if there is anything
missing feel free to bring it up.
Some of the ideas are stupid or do not make sense but are documented here
for sake of completeness.
Deployment of some of these ideas can be done real soon, others require
extensive software upgrades. The final solution selection may include more than
one ideas below as there is frequently not just one solution.

The goal of this email is that the WG is in a position to know that it is
selecting from a "complete set" of solutions When/IF the WG (or DNSOP WG)
decides that it should attempt to document/recommend more approaches than
what was covered in the FR-draft.

Covered in FR draft:
Query ID
Source Port
Source Address

Randomness possibilities that originators have:
Destination Address [1]
Case games (like x20)
Multiple identical questions [5]
Repeat question [6]
Spread question to number of nameservers. [7]
Delay question [8]
Time spaced repeated questions [9]
"random" TCP query [11]


What Destinations can do to increase protection:
More addresses: [10]
DNSSEC

Protections that require both parties collaboration:
TSIG
DNS cookies
TKEY + TSIG/SIG(0)
SIG(0) Destination Protocol/port [2]
Query name hacks (pre and post fixes) [3]
EDNS ECHO [4]
QCount > 1 [14]
QClass top bit 8 redefinition [13]
IPsec tunnels [12]
IPv6 preference [15]

Steps that resolvers can take to protect them self:
Forgery Detection
and react to forgery attempts.

Steps that Operators of Authorative servers/zone owners can take:
Deploy only current software
Deploy DNSSEC
Update ACL rules to reflect current recommended DNS port usage.

Comments:
[1] Destination Address: Many implementations go to first name server in an
NS set all the time, some go to the one they know is closest or go
to the one that they know has answered a query in the past, one they
have an A record for, etc.
From security point of view always selecting a random server is the
best one. From an operating point of view this may/will cause more
delays/errors. For high availability zones with short names having
large NS sets is an possible source of randomness for example "." has
13 A address this adds 3.5 bits of randomness for resolvers that use
random selection. By expanding this to randomly select IPv4 and IPv6
as transport for query another bit can be added.

[2] Destination Port: Another potential source for randomness is to reserve
4 - 16 ports that DNS servers MUST listen on. 16 ports add 4 bits of
randomness.

[3] This relates to adding .QNAME in query section or
QNAME. or even if QNAME is a.b.c to do
a..b.c or a.b..c
is in this case has a known prefix in the first label
that is registered with IANA so people can avoid it,
if is multiple labels the first label should encode
how many bytes or labels to strip.

[4] EDNS Echo: A simple option to EDNS that instructs a server to copy back
this option in the answer or the answer is not to be trusted.
The contents of the option is random data unique to the query.

[5] In this case a resolver fires a number of identical questions off and
expects to get the same number of identical answers.

[6] In this case the resolver repeats the question after getting an answer,
it expects an identical answer.

[7] Spread question to a number of nameservers/recursive resolvers,
expects to get back identical answers from all.

[8] Here the resolver waits for a short random time before sending the
question but it is listening for answers from the time it forms
the question.
This is to detect forgery attack before sending the question.

[9] In this case the resolver sends queries that are spaced in time
and it expects the answers to come back in the same order as sent the
time between second and subsequent answers should approximate
the transmission time.

[10] More designation addresses, larger NS sets potentially offer more
protection as the client has more addresses to choose from.

[11] TCP queries are controversial as they require more state and overhead.
Over the last few years we have seen TCP stacks optimized for handling
large number of TCP connections thus the assumptions for not using TCP
for DNS should be reexamined and requiring TCP port to be available on
authorative servers will allow clients to fall back on TCP in
specified situations.

[12] IPSEC: this is an option when there is strong relationship between two
DNS entities, it is not clear how applicable this it is in the random
resolver talking to random server.

[13] Right now about 4 classes are defined in the IANA registry. Use
and deployment
of new classes is difficult to say the least. For this reason it is tempting
to steal some of these unusable bits into help protect the protocol.
The proposal is to redefine the top 8 bits into a QID and servers would
ignore these bits when checking class answer but echo them back in the
answer's QCLASS.

[14] QCOUNT > 1 is currently not allowed but could be used to add
randomness to
the query if the second query is ignored in the answer processing
but is copied into the answer. There are number of different possibilities
in how the randomness is expressed in the: label, QCLASS, QTYPE or all.

[15] IPv6 preference for queries, A resolver can cycle through many
privacy address to increase source address randomization.


Sorry for the lack of attributions in this posting, if/when this becomes an
an ID that will be fixed.

Olafur


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: