On 5/10/16 9:49 PM, "DNSOP on behalf of Mark Andrews" <dnsop-boun...@ietf.org on behalf of ma...@isc.org> wrote:
> >In message <20160510160757.13221.qm...@ary.lan>, "John Levine" writes: >> > Administrators should consider whether the lack of user-specified >> > hostnames is a drawback. >> > >> >This is not true - it would be trivial to allow the enduser to specify >>a >> >few specific hostnames and deterministically auto generate the rest. >> >> Putting names into the zone is the easy part. Deciding who's allowed to >> add names and what names they're allowed to add is not. > >For reverse zones, UPDATE over TCP from the matching IP works and >there are nameservers that support this and can be configured to >only accept PTR records as well. I've never figured out how a printer knows what server will accept UPDATEs from it. So, you wouldn't allow another host (say, a PC or a gateway) to populate? You get no hostname if you don't speak TCP UPDATE. I can live with that, just asking. > >It wouldn't be hard to add a EDNS option that says "remove if not >refreshed after XXXX seconds" to the update request and the master >server could maintain a time based list to clean up. I look forward to your draft. > >One can do UPDATE over TCP self for PTR + KEY (or just KEY) and >self using SIG(0) of PTR + KEY once the KEY is installed. This >allows the client to clean up after itself independent of the address >the UPDATE request comes from. Server implementations already >support this. Client implementations? > >One can do update TCP self /48 (already implemented in some servers) >(or any other configured prefix length) to install NS records or >DNAME records to do "delegations" of either style. Allow KEY to >allow client cleanups. The DHCP server can remove the delegation >when the PD expires so you have cleanup. The update self size needs >to be tuned to the PD size. If you want to add more moving parts >the DHCP server can add the KEY which is supplied w/ the DHCP PD >request. Oh, you're assuming the delegation is to something in the home, then? I still think that's a bad idea, because it's a DDoS vector. And removing delegation doesn't work if the ISP is delegating to itself. You could delete the zone and re-create it, but it'll still point (probably) to the same server. > >This is not hard to do. We just need to pick what is reasonable >to do and recommend it. The customer side will appear once we >recommend a approach. > >Border routers do the delgation while individual nodes to the self >updates. I've been taking the approach all along of "What is currently possible." If you think this is a problem space that needs to be solved, I look forward to your draft proposing this solution. Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
