In message <d35a0121.640eb%lee.how...@twcable.com>, "Howard, Lee" writes: > > > 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.
You can find the containing zone easily enough. Code to do that was added to libresolv back in the 1990's. You send the update to the nameservers for the zone starting with the NS that matches the SOA MNAME. For tcp-self you don't want to forward (return NOTIMP) or examine the UPDATE request as see if it passes the tcp-self test before fowarding and all the master to accept updated from the other nameservers based on tcp address but for SIG(0) you can forward updates. Apple also got _dns-update._udp registered so you can use SRV to override the SOA MNAME (they failed to document it as required which is why people missed it). http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=53&page=4 > 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? dnssec-keygen + nsupdate with the correct set of options. nsupdate will find the correct server to send the update to (support for SRV is on the to do list). % dnssec-keygen -T KEY -a RSASHA256 -b 2048 -n HOST 4.3.2.1.in-addr.arpa Generating key pair......................................+++ .............................................+++ K4.3.2.1.in-addr.arpa.+008+13510 % cat K4.3.2.1.in-addr.arpa.+008+13510.key 4.3.2.1.in-addr.arpa. IN KEY 512 3 8 AwEAAdqtaoLxk98xaWwNfyNkb9z/hL4TzKKqE36Gwl1flzrPUf1PNMgI +hfBdTbxQgfWeUMzerMyrGHc+/rdWbIw70I3hnXI+yOrOcay1sNscQLe fNpWBFyEhGlChY/4bu7siRxlfhff1uf2jg9/eOzYjLxCVcBJRwLJvHOa htV8aT6GkOe6LfUvJmFyWm9MN+dwrqMyaWEX7fxdaS8MwVhNh9q56ir+ 2Sdl2nuD1fAPTUVab1TKjJ/dyy5GPLBcL5ObWyBl19BF3d2KjpMkXA5E Ph7dNBvk7ZKZ6XU0JOn0iY0W2+0VTsN8N2B/2SpDR2kNkqSv387dbw3i oAgviyXGJz0= % # # Add the key using TCP from the designated address. # ( echo local 1.2.3.4 echo update delete 4.3.2.1.in-addr.arpa IN KEY cat K4.3.2.1.in-addr.arpa.+008+13510.key | sed -e 's/^/update add /' -e 's/IN/3600 IN/' echo send ) | nsupdate -v # # Add the PTR record after removing any existing PTR records # using SIG(0) to authenticate. # nsupdate -k K4.3.2.1.in-addr.arpa.+008+13510 << EOF update delete 4.3.2.1.in-addr.arpa 3600 IN PTR update add 4.3.2.1.in-addr.arpa 3600 IN PTR host.example.net. send EOF > >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. Absolutely total FUD. UPDATE is no worse than QUERY. > 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. You only need to delegate if you are synthesising PTR records. > >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. I'm talking about what is currently possible using existing tools. People just refuse to accept that it is. Named already has the code for self-48 (called 6to4-self) doing the other prefixes lengths would be a hour or so work. tcp-self already exists for host KEY / PTR records. self / selfsub already exists for SIG(0). See update-policy. Mark > Lee > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable propri= > etary information, which is privileged, confidential, or subject to copyrig= > ht belonging to Time Warner Cable. This E-mail is intended solely for the u= > se 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 dissem= > ination, distribution, copying, or action taken in relation to the contents= > of and attachments to this E-mail is strictly prohibited and may be unlawf= > ul. If you have received this E-mail in error, please notify the sender imm= > ediately and permanently delete the original and any copy of this E-mail an= > d any printout. -- 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
