--"william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:
What was discussed at the meeting is approach to this where if direct
lookup for _marid.user.host.domain.com fails, then as part of the failure
code dns server provides AUTHORITY section which contains information
about actual domain zone (i.e. most likely domain.com) and then lookup
can be done to _marid.domain.com for the default record.
Right, the assumption here is that the "closest SOA" would be a logical
place to stick a "catchall" record, if you want one record to cover all
hosts in your domain or subdomain.
Rather you can take it as a logical place to put "catchall" records that
applies to any other record otherwise entered in that zone. Obviously
domain may have subzones (redeligation) and for those zones additional
default records would have to be configured.
There is also another possibility for the future that extra lookup would
not be required if dns server authors modify their software to know about
such lets call it default record in the zone file (which they all read
and cache in memory or on disk or database anyway) and automaticly supply
it (most likely in "ADDITIONAL" section) for any other record that exists
but does not have such specific type record specified in that zone. Obviously
when dns server does not provide such synthized record functionality based
on default entry it'd be up to the client to specifially look for it.
Now I'm sure by now you all think, you've read about this somewhere before -
and you're right, this is almost like "*" as how it is implemented by
BIND, the difference is that with normal "*" these records apply only to
somehost.domain.com if there is no specific host DNS record for that zone
(of any type) where as here it would apply to this record if there is no
specific record of this TYPE even if there is some kind of other type
record there. Plus it would mean allowing for "hosts" under the sinthized
default/wildcard record.
To give practical example of how this all can work, lets say that
administrators are to be allowed to enter the following in their dns zone:
_marid.* TXT "..."
(unlike normal "*" in this convention its not allowed to have anything
after the "*", i.e. it must be the one for the actual zone in SOA).
Now when somebody asked for something like "_marid.host.subdomain"
within appropriate domain zone this wildcard would be expanded from the
side other then normal wildcard and used to supply _marid record back
in the additional section (meaning its not necessarily what you wanted but
you might be interested that it exists if your application is interested).
And for servers that did not support it, the client would just look for
_marid.*.domain.com based on the AUTHORITY entered in domain.com
I think we may need to get in contact with IETF DNS folks and see what they
think about creating either additional "*" record for the future or extending
functionality of normal "*". I do suspect there would be lots of objections
because many people enter multiple domains into same zone record (i.e.
host.domain.com. IN A ...
host.domain2.com. IN A ...
On the other hand, I'm not totally certain that implementing it actually
requires any kind of change to DNS protocol, rather this can be BCP for
server implementors or something like this.
It's not a bad idea, because it keeps people from having to create TXT
records to match all the MX and A records that already exist, but in cases
where they already have a wildcard for A or MX, they may still want a
wildcard TXT (since it may be different from the base MX)
That is where MARID records come in...
I note however that above approach will mean that during initial
deployment there would often be necessary for clients to send 3
consequative dns queries and that is often just to find out that there is
not MARID record for domain:
Quite a bit of bandwidth waste, don't you think?
Add to that Query 3 can not be done unless Query 2 answer is received
(as data from AUTHORITY section from Query 2 is used for Query 3).
I don't think bandwidth is going to be as big an issue as the sequential
nature of it.
True, what I meant is that we endup doing too many extra lookups where as
normally we only have to do one lookup to get not-found answer (which is
actually quite common), we must try to cut down on that.
A "does not exist" answer with authority included should be
between 100 and 150 bytes. But, the sequential requirement may be a hit to
performance. (Still cheaper than filtering though :)
Its cheaper then filtering when you get an answer. I see it as a bigger
problem exactly because you're not getting an answer and have to do most
number of lookups. I
--Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
It should be pointed out, according to my tests, if you have a wildcard
TXT, that would cover any made-up name that doesn't have any other records,
but if you have names with A or MX but no TXT, the wildcard TXT doesn't
apply to those.
*.bigisp.com. IN TXT "v=marid record goes here"
www.bigisp.com. IN A 10.2.3.4
In this case a query for "www.bigisp.com TXT" would give no answer (NOERROR
result, meaning the empty set is the correct answer)
Someone should probably check my results.
Checked. You're absolutly right, existance of any other TYPE of record
for the host would nullify any * record that may exist for different TYPE.
P.S. For chairs - its clear by now that we're getting quite a bit into dns
issues and that we must have several edns experts with us on the list,
perhaps you can contact appropriate IETF WG or AD and invite some people
to participate. Another alternative if dns people are not interested in
reading too many messaging dealing with decisions on what mail header is
to be authenticated and how is to possible create different MARID mail
which would focus on DNS syntax and implementation for MARID (and as such
of interest to dns people) where as mail list may continue to work on
syntax of actual MARID record and how it is to be used by mail servers.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net