In message <20141105215548.27d51a91...@fafnir.remote.dragon.net>, Paul Ebersman
writes:
>
> marka> Or we could stop debating whether we should maintain it and
> marka> assume that if we give people tools that will allow it to be
> marka> automatically maintained they will eventually deploy them.
>
> For providers with millions or tens of millions of end customers, any
> system that just lets any customer scribble in DNS is unlikely to be
> employed for security or stability reasons.
For in-addr.arpa you already have a PTR records. Allowing the end
user to set its content does not increase the amount of data you
are serving. It does increase the amount of churn in the zone. A
matching TCP source address is a good enough authenticator to permit
the update. If you want to force a single PTR record that is
implementable policy.
1.2.3.4 can only set the PTR record at 4.3.2.1.in-addr.arpa.
update-policy {
permit * tcp-self * PTR;
};
to do singletons something like would work
update-policy {
permit * tcp-self-singleton * PTR;
};
I don't see a real security issue here.
The occasional customer will add a offensive PTR record which won't
be seen by 99.99999% of the world. It will occasionally be included
in logs. The contents can already be checked to ensure that it is
a legal hostname (LDH) that is being added. We see this sort of
thing in whois but it doesn't stop the host names being registered
there and there is no real reason to stop them here.
If we recommend that this is only done when a forward record is
also successfully added UPDATE + TSIG (yes, this does scale for
this use) you get rid of the PTR/A mis-match issues.
For ip6.arpa you delegate to the customer along with the prefix
delegation. The customer has to deal with the space issues but
uses the same mechanisms to add the PTR records and cleanup.
> marka> Document what a node should do to register itself in the reverse
> marka> tree and to cleanup when its address changes. Write some code to
> marka> do it.
>
> And of course all CPE vendors put out quality products with these
> advances in code and never put out cheap crap. And consumers always
> upgrade their CPEs based on this improved code immmediately.
So you implement the rest of the proposal to self clean and restore
defaults. Delayed additions are no harder than delayed removals. Yes
there are 3 records instead of one but no human needs to any
maintainence of the zone content.
REMOVE PTR <time>
ADD PTR <time> <default value>
You get the equivalent of $GENERATE with customer settable overrides
using UPDATE over TCP.
This is incrementally deployable.
add-remove delay PTR;
add-remove delay KEY;
add-add delay PTR "dynamic-%1.%2.%3.%4.example.net";
update-policy {
permit * tcp-self-singleton * PTR KEY;
};
Or if you don't like the ADD record.
add-remove delay PTR;
add-remove delay KEY;
ptr-default "dynamic-%1.%2.%3.%4.example.net";
update-policy {
permit * tcp-self-singleton * PTR KEY;
};
Technically this is 100% achievable. It adds a couple of new record
types. It requires nameservers to do the processing specified in
the new records as it falls due.
If you don't have PTR records by default you don't restore them on
deletion.
It can work with zones that synthesize missing PTR records on demand.
If there is no PTR record in the zone, create one.
> Heh.
>
> The reality is that this will take decades and in the meantime,
> consumers will have problems doing what they want and they will complain
> to their service provider, who won't have a good solution.
The reality is that this will give what is needed and is incrementally
deployable. The only question is do you synthesize missing PTR
records and matching AAAA records or not for IPv6.
Mark
> This document tries to lay out the challenges and tradeoffs of not
> having PTRs or not having "clean" PTRs. We should be sure it makes those
> tradeoffs clear, along with the problems service providers will see if
> they do or don't pick one of the solution sets. If there are issues or
> tradeoffs not in the document, suggest a text change.
>
> The "just do it right and folks will roll it out" argument doesn't solve
> the problem in any useful timeframe and doesn't let folks who do have to
> support millions of customers make informed operational decisions.
>
> And automating at the scale we'll see with real IPv6 deployment is going
> to be very hard. Add in that embedded devices are some of the least
> likely to be current, clean or remotely upgradeable as we learn of
> mistakes and you'll wind up with more boxes doing it wrong than right.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
