After my last email which most probably did not find very usefull
(in that it did not state any specifics as might be required at
this stage of this group) you're probably wondering if I have
something of value to offer? Well I do in fact have concreate
proposal for 2nd part of what I think is the proper work for this WG
(i.e. technical specification of dns record). I was hoping to use
today to create anyting more then my own draft notes, but I did not
get a chance, so please don't kill me that I'm sending it so late
or that it does not come in the Internet-Draft format or anything
close to it - I really had no time for it considering how much I had
to do in the last few days so that I could clear next two days
primarily for MARID WG meeting.
---------------------------------------------------------------------
What is proposed is that new DNS record be created (which we'll
call MARID for now) that can be entered with wildcards. This record
should be as follows given in BIND example:
*.domain.com. IN MARID Identity-Type Prior-G Prior-N Trust-L Ref-Val MARID-Data
OR if more specifics are desired for username(_at_)host(_dot_)domain(_dot_)com,
then the
record should be like this
username.host.domain.com. IN MARID ...
The actual proposed MARID record is composed of the following parts:
Identity-Type:
A text field specifying type of email identity being specified by this
record. The list of valid "Identity-Types" is expected to be maintained
by IANA. Additional special "NONE" is available which can be used with
referrals
Prior-G: Number that specifies which group of policies does this belong to
(i.e. lime number 2 in "access-list 2 ..." if you're cisco fan)
Lower group numbers are processed first. Referrals are processed
separately from each of main group of records
Prior-N: Specifies priority of this policy record inside its group
Trust-L: One-character (or possibly a number) that specifies trust-level
of this policy and how it is to be applied. The proposed valid
symbols are:
I: This policy record is not valid and should be ignored
T: Testing mode, this policy is in testing and polncy decisions
should not be made based on it, but possible the decisions
maybe logged if desired to help in testing
L: Low level trust (for future)
S: Standard "mid-level" trust - apply this policy in conjunction
with other policies but don't make decisions based only on it
H: "High-level" trust - anything that does not comply with this
policy should be viewed as highly suspicious and possibly
connection should be terminated immediatly
N: If value if query matches the record specifies here, it should
specifically NOT be trusted
MARID-Data: This is a text field that usually contains FQDN (fully qualified
domain name) and very often this would be ip address. The
convention used for specifying ip address is that of
IN-ADDR.ARPA, i.e. 10.20.30.40 is specified as
"40.30.20.10.IN-ADDR.ARPA". The range of ip addresses is
specified with "*" such as "*.30.20.10.IN-ADDR.ARPA" means
10.20.30.0/24. So example of full record is
*.MYDOMAIN.COM. IN MARID [Identity-Type] 1 1 T - *.30.20.10.IN-ADDR.ARPA
Ref-Val: This is a field that specifies if record should be viewed as
direct specification of the policy or referral to different
record. There are possible values:
-: No referral (default. process record as direct specification
of policy)
MA: Marid standard referral. This means that another MARID record
contains policies that should be checked and added to
policies available from this lookup.
Note1: if Identity-Type is specified it is remembered as
"default" idenity type and if the MARID record
that is being referred here contains "NONE"
for identity type, then it is used with those
records in place of "NONE".
This trick is used if you want several identity
types to list same data (same ips) and you don't
want to relist them each separately
Note2: Referrals do not inherit priorities, i.e. those who
are applying the policy should not try to get all
records first and sort them all out by priority
and priority groups. Instead each lookup is sorted on
its own and referrals are subqueried in the same order
as they are entered considering the priority & priority
groups specified for the actual MA record
All the following referrals can be done in interpreted in several
ways (see more about it below)
A: The data field contains name of the host (FQDN). Take it as is
P: The data field contains name of the host which should be
queried for type "PTR" and that used as vlue for this policy
M: The data field contains name of the host which should be
queried for type "MX". The list of "MX" records becomes
values for this policy and they are sorted by MX priorities
These referrals can be futher interpreted in these ways
(the -X is added to actual value above to create full name of
this type of referral):
-D: Direct, the name used that was obtained from A, P or M
is directly used as value for this policy
-4: The FQDN name is queried for dns record type "A" and the
resulting ip is then used as value of this policy
-6: The FQDN name is queried for dns record type "AAAA" (or
A6 if dns groups still wants to use it as main future
IPv6 record) and its value is used for this policy)
-A: Interpreted by client to be either -4 or -6 depending if
original query was due to ipv4 address or IPv6 address
-Q: The incredible Q (as from Startrek :) MARID referral
subtype. In this case, the name from A, P or M is used
in conjunction with the actual value that client maybe
trying to authenticate. This value is added before the
FQDN obtained from A, P or M to create new FQDN and then
value is used in the normal MARID referral way
(see above info on MA).
Note: To understand power of the -Q referral type, I'll give
an example. Lets say we have a site that lists many ip
addresses and entering each one of them individually as
MARID records (or even doing it with multiple referrals)
would make for large number of queries from client system.
To make it easier they could entere record like this:
*.MYDOMAIN.COM. IN MARID [Identity-Type] 1 1 T A-Q _MARID
40.30.20.10.IN-ADDR.ARPA._MARID.MYDOMAIN.COM. IN MARID [Identity-Type] 1 1 T - *
As you can see from above the Q record reorgonized a query
so that new one was specifially for this ip address. It
can be noted that last record could have been:
*.20.10.IN-ADDR.ARPA._MARID.MYDOMAIN.COM. IN MARID [Identity-Type] 1 1 T - *
Which would provide same result for any ip address in
10.20.0.0/16 range
The refedrals with options given above provide for quite wide range of how
these records can be implemented (more example to come later) and allow
for very usefull tricks (one already shown above). Some of the referrals
are little like SPF so I'll refer you to read spf specs and examples on
what can be done and only list which corresponds to what:
SPF Modifier: Ref-Val for this proposed MARID record:
a A-A
mx M-A
ptr P-A
ip4 - (the ip address is entered directly)
ip6 - (same as above)
include MA
All right I'm now ready to go to sleep so whoever will be there tomorrow,
I'll see you and you can then ask questions about what I meant in this
proposal. And again please don't kill me for such a late submission.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net