On 2004-03-11, at 23.39, Markus Stumpf wrote:
On Thu, Mar 11, 2004 at 11:05:21AM +0800, Patrik Fältström wrote:
[3] Add a prefix to the owner (i.e. _foo.example.com.)
Problematic for two reasons:
If we have
example.com. IN MX 10 mail.example.com.
it is for me much better to have the same owner for the "RMX" resource
record as the MX because then we know for sure both MX and the "RMX"
is
in the same zone, and have to be signed by the same owner/mechanism.
I don't see a problem with having both
example.com. IN MX 10 mail.example.com.
_srv.example.com. IN NRR ...
in the same zone.
I don't even see a problem with having
ns4.dns.space.net in the space.net
zone. The only ones up to now that seem to have a problem is the
italian NIC that insisted that dns.space.net MUST have a delegation.
Problem is that they might be in different zones.
example.com. IN MX 10 mail.example.com.
_srv.example.com. IN NS ...
Is this something which have impact on the "trust" on the data?
Is this a weakness which can be used as an attack vector when attacking
the system? Especially when using DNSSEC?
Second problem has to do with wildcards.
If one have
*.example.com. IN MX 10 mail.example.com.
then one can have still
*.example.com. IN RMX ...
But, if one use _foo.example.com for the mechanism, we can not have:
_foo.*.example.com.
This problem only becomes evident if there is a need for wildcard
records. It may even be a design goal to make wildcard records
impossible
to make it harder for manually managed zones to set the NRR for the
whole zone. As for automated (database backed) administration it
doesn't make a big difference as they would probably assign the records
to every LHS explicitely.
When DNSSEC was designed, and when the wildcard Verisign was playing
around with was discussed there was a discussion whether the wildcard
"was obsolete" and the outcome was that "it is needed in enterprise
environments for email".
But, of course we should ask again.
paf