W dniu 02.11.2015 o 00:40, 神明達哉 pisze:
> I have one quick comment/question on draft-krecicki-dprive-dnsenc-01.
>
> In Section 3.1 it states:
>
> APPLICABLE NS NAME a <domain-name> of NSes that use this
> key. This allows for different NSes for
> a zone to use different keysets (eg. when
> the secondary is operated by different
> entity than primary). This field might
> contain wildcard symbol '*' at any place
> (including as a part of a single label -
> eg. 'ns*.foo*bar.example.com'), which
> matches zero or more characters and can
> cross label boundaries ('ns*.example.com'
> matches 'ns.example.com',
> 'ns1.example.com' and
> 'ns1.foobar.example.com'), single '*'
> means any.
>
> So the semantics of '*' is different from that of RFC1035/4592. Is
> this deviation really necessary? It's not immediately clear to me
> from the draft about the definite need for it, and I suspect this can
> be easily a nightmare for implementers. Also, calling this a
> <domain-name> might also not be very appropriate as it handles '*' in
> a different way.
The goals to achieve are:
1. have the ability to specify different keys for different nameservers
for one domain (as one might be provided by domain owner, other by SNS,
and both can use different keys)
2. having 1. in mind, limit the amount of NSK records needed for domain
to absolute minimum.
For example:
example.com IN NS ns1.example.com
example.com IN NS ns2.example.com
example.com IN NS alt-ns1.example.com
example.com IN NS ns1.snsprovider.com
example.com IN NS ns2.snsprovider.com
example.com IN NSK ns*.example com ...
example.com IN NSK ns*.snsprovider.com ...
Two different keys for two providers, and no key for alt-ns1.example.com
(because it does not provide DNSENC).
It is a topic for discussion (you're not the first one to mention it),
and I'm open to other solutions - I just want to make sure that the
chosen solution achieves the goals I've mentioned before.
Witold Krecicki
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
