In message <[email protected]>, Joe Abley writes:
>
> On 2012-11-22, at 18:10, Mark Andrews <[email protected]> wrote:
>
> > Individual hosts should be doing dynamic DNS. Where that update
> > is sent to may change but all machines should be doing it and should
> > support TSIG as a minimum.
>
> The missing pieces here include:
>
> - what sane ISP/campus/home network/hotspot operator gives credentials =
> to customers or even random users to complete dynamic updates to one of =
> their master servers?
ISP's have a contractual relationship often with shared secrets
(username / password) for updating all sorts of information via a
web interface. TSIG is just a username / password pair operated
over DNS instead of HTTP / HTTPS. You can still do all the sanity
checking you want on the names if you want. Named has the hooks
to do this today. What it doesn't have yet is a external TSIG
database but that is realitively easy to add.
> - how can a TSIG key be shared between a network operator and a client =
> that potentially don't know each other?
Use a DH TKEY exchange with packets sourced from the address you want to
be updated. You then have a TSIG that is bound to a address. You only
allow that TSIG to update the associated reverse name.
> - what name should a user be allowed to specify in their PTR RDATA?
Any legal multi label hostname. You can do checks on the name for
obsenties if you want.
> - what stops user A from sending authentically TSIG-signed UPDATEs to a =
> nameserver and changing (or removing) user B's PTR?
See above.
> - what consumer systems do this by default? (I think it's none, but I =
> thought I'd ask)
We are designing for the FUTURE. The consumer systems WILL do this
if the operators add support. This is all existing protocols being
bolted together.
> > Individual hosts should be able to work out where to send the updates
> > by querying the DNS to find the nameservers of the containing zone
> > after processing and DNAME/CNAME mappings.
>
> I think you skipped a step -- you need to find the zone cut before you =
> can find the nameservers responsible for the zone. I guess I do that by =
> asking for blah.ip6.arpa/IN/SOA and checking the authority section, but =
> what if the authority section is empty because of software choices in =
> some nameserver? I guess then I need to
We shipped code to do this back before the turn of the millenium
with BIND 8 as it was needed for nsupdate.
> [krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80::
> inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 =
> autoconf=20
> [krill:~]%=20
> [krill:~]% dig =
> 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short
> [krill:~]% dig =
> 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short=20
> [krill:~]% dig =
> 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig =
> 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig =
> 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short =20
> [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short =20
> [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short =20
> [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short =20
> [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20=
>
> [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20=
>
> [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400
> [krill:~]%=20
% nsupdate -dd
> update add e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 in ptr
> dummy.example.net.
> send
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5017
;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA
;; AUTHORITY SECTION:
2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 IN SOA . jabley.hopcount.ca.
2011032174 10800 3600 604800 86400
Found zone name: 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa
The master is: .
couldn't get address for '.': not found
%
> Ah, there it is. There's no MNAME specified (I rudely called it ".") but =
> let's pretend I didn't do that.
>
> Now I need to know:
>
> what is my name?
Names don't depend apon where you are in the network. You give a
machine a name when you configure it for the first time.
> how do I know the name is unique within this network?
The name is fully qualified. There is no "unique within this network" to
worry about. It's globally unique.
> what TSIG key should I use?
The one you negotiate with the nameserver.
> Let's suspend disbelief and suppose that I am capable of knowing a =
> reasonable name that represents a reasonable, valid FQDN, that I know =
> it's unique, and that I have somehow discovered a TSIG secret for the =
> local network that is still a secret, and isn't shared knowledge amongst =
> 300,000 other customers.
>
> Once I've answered those questions, I send a TSIG-signed UPDATE to the =
> MNAME-specified server and update:
>
> =
> 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN PTR krill.hopcount.ca.
>
> Presumably we're encouraging PTR records to make sense, in which case I =
> also want to update:
>
> krill.hopcount.ca. AAAA 2001:4900:1042:100:584e:a27e:8df4:6277
>
> Since hopcount.ca is my own domain, and I run the server referenced in =
> the MNAME (assuming again I change it from "." to something sensible), =
> there is some chance I could make this work. What if the domain is =
> hosted elsewhere? What if it's the ISP's domain I've decided to use? =
> What if I have no reasonable parent domain configured, and the local =
> hostname is "Joe's Computer"?
Well you host your zone on a server that does dynamic updates.
> I need to repeat this for every v6 address I have (I have five right =
> now, apparently, not counting the link-local) and also handle deletion =
> of AAAAs and PTRs that might already be there, accommodating the full =
> range of abrupt disconnects that phones and networks enjoy six hundred =
> times per day.
Well you would send one update for the forward with all your addresses.
> Even without harping on about the many unanswerable questions in the =
> travelogue above, this whole procedure seems filled with fail.
>
> > Darwin and Windows already support sending dynamic updates though
> > I don't believe they handle the presence of DNAME or CNAME.
>
> I believe these days none of (Windows, Mac OS X, iOS, Android) do this =
> by default. Windows and Mac OS X can be made to do this kind of thing =
> with specific configuration ("wide-area bonjour", "Active Directory"), =
> which is usually only ever done in an enterprise context.
>
> I think current tools for this suck, and current protocols are going to =
> need extensions to be defined before the situation gets any better. =
> Happy to be proven wrong, though.
Tools become better as every starts to support it.
> If there's a good way to do this (enforce a naming scheme that =
> guarantees uniqueness, use SIG(0), whatever) then I think this draft =
> needs to spell it out in a way that people can actually implement, both =
> as vendors of consumer operating systems and as v6-capable ISPs. Simply =
> saying "this has been easy for a decade" doesn't really get us anywhere.=20=
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
