On 4.11.2015 22:53, Tony Finch wrote:
> Tim Wicinski <tjw.i...@gmail.com> wrote:
>>
>> draft-spacek-dnsop-update-clarif, Spacek
Grrr, dnsop session ended right on time and Paul Wouters did not get necessary
30 seconds to present this draft to the WG.
Anyway:
> Note that my 2317bis draft has a slightly different take on UPDATE vs
> classless reverse DNS. The UPDATE section of my draft is entirely due to
> Petr's draft, so I'm very grateful to him for pointing out the problem.
> I'm interested in opinions about
>
> - should this be a separate draft or is it sensible to put it in rfc2317bis?
It could be combined with rfc2317bis because there is very tight relation
between these two. However spacek-update-clarif is more generic and IMHO we
should extend rfc2317bis to incorporate the generic-ness before dropping
spacek-update-clarif.
> - is the indirection problem specific to classless reverse DNS (which is
> the approach I took) or does it apply everywhere (which is what
> Petr Spacek's draft says)?
Personally I do not see why it should be specific to ARPA sub-tree ...
Conceptually it is the question if client wants to update RR at the terminal
node or on the node client can name beforehand ("reverse DNS query name" is
one example of a name known beforehand).
Thinking about it a bit more ... I can see that RFC2317bis should make
canonicalization mandatory for reverse sub-trees and all other cases should be
left to the implementation to decide. Let's see if we can do it in one document.
> - is my detailed suggested UPDATE behaviour sensible?
> https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9
Most importantly, I believe that limiting the new behavior ("canonicalize
first") to PTR RR type is a bad idea. We have DHCID, EUI48, EUI64 and people
are certainly using other RR types in the reverse sub-trees too (TXT comes to
mind...).
Even if we decide in the end to mandate the new behavior to ARPA sub-tree we
surely should not limit ourselves to PTR.
I would remove limitation to PTR and add a paragraph about sub-trees other
than IN-ADDR.ARPA and IP6.ARPA. For a while I was considering adding a
limitation to "*not* CNAME/DNAME", but IMHO your sentence "these requirements
do not apply if you are using DNS UPDATE to deploy classless IN-ADDR.ARPA or
IP6.ARPA delegations" is better.
I'm proposing to use following text (few nitpicks included):
"""
9. Dynamic DNS UPDATE for reverse DNS sub-tree
This section updates the DNS UPDATE specification [RFC2136]. It
specifies additional requirements for DNS UPDATE clients, so they can
dynamically change DNS records in reverse sub-tree in a way that is
compatible with the techniques described in the previous sections.
It applies both to the IPv4 reverse DNS under IN-ADDR.ARPA and
the IPv6 reverse DNS under IP6.ARPA.
These additional requirements only apply to DNS UPDATE clients that
wish to add, remove, or change records in the reverse DNS sub-tree.
Exception is that these requirements do not apply if you are using DNS
UPDATE to deploy classless IN-ADDR.ARPA or IP6.ARPA delegations.
No new requirements affect other uses of DNS UPDATE, i.e. uses outside
of IN-ADDR.ARPA or IP6.ARPA sub-trees.
In this section, we use the term "reverse DNS query name" to mean a
name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making
a reverse DNS query. The resolver expects this name to resolve to a
PTR or related RRsets, but (as described in previous sections)
it does not have to be the direct owner of the RRsets but can instead
be an alias.
The problem addressed by this section is that DNS UPDATE clients
sometimes use a reverse DNS query name in an UPDATE message without
checking for CNAME or DNAME redirections. If the usual reverse DNS
query name is an alias, then this behavior results in an attempt to
add or delete a record to or from a node that already contains
the CNAME record, and the update fails.
Aside: Presumably the UPDATE will also fail if the node is occluded
below a DNAME record, but neither [RFC2136] nor [RFC6672]
specifies how a server out to react to attempts to UPDATE an
occluded domain name.
Please note that this problem is generic. For names outside of
IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation
to decide if it is necessary to update aliases itself or if it is
necessary to update RRsets at terminal node of alias chain and thus
method described in the section 9.2 needs to be applied.
9.1. Requirements for updating records in the reverse DNS
When updating a record in the reverse DNS sub-tree, an UPDATE client
SHOULD NOT simply convert the IP address to a reverse DNS query name
and send an UPDATE request for RRsets at that name. It MUST
NOT assume the zone cut falls on a particular boundary such as /24
for IPv4 or /64 for IPv6.
"""
Additionally, Security Considerations section does not mention risks mentioned
in
https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01#section-6
It would be nice to copy&paste/incorporate the text from there. These risks
should be explicitly mentioned.
Now it is ~ 4 AM here so I wish the text above makes sense :-) I will read the
procedure in section 9.2 carefully again this week, but it seems okay at a
first glance. (For generalization proposed above we would have to drop "PTR"
from the very last bullet in 9.2. Suggested behaviour but that is it.)
I believe that we can drop draft-spacek-dnsop-update-clarif in favor of
rfc2317bis if concerns above can be resolved.
Have a nice day!
--
Petr Spacek
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
