Subject: secure-ddns-howto.html

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Feb 2002 22:32:37 +0100

I'm sorry for not having setup a dynamic reverse zone so I don't know
how it will work, but one thing the document above doesn't explain (or
perhaps I am reading it poorly) is if the reverse zone does any
checking on the name provided by the client via DHCP.

What I mean is, if I say `send fqdn.fqdn "www.ietf.org.";' in
dhclient.conf, will the DHCP/DNS server put a PTR for the IP I receive
that says www.ietf.org.?

This solution to this is pretty obvious though, so perhaps it is
implemented.

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Feb 2002 14:14:36 -0800

> dhclient.conf, will the DHCP/DNS server put a PTR for the IP I receive

yes

> This solution to this is pretty obvious though

do tell

and it's not the forward lookup, as you do not know that the laptop
has a sufficient or reliable trust association with the forward dns,
or if the forward updata has already succeeded.

randy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Mar 2002 00:25:36 +0100

>> dhclient.conf, will the DHCP/DNS server put a PTR for the IP I receive

Is that good?

> or if the forward updata has already succeeded.

If the laptop does not have a sufficient or reliable trust association
with the forward DNS, I don't see why I should let it pollute my
reverse zone with a DNS name that points to that forward zone.

And yes, I was thinking about forward lookup, possible after some
delay to let the forward server update itself.  More elaborate
approaches could be possible as well (server looks up KEY(fqdn.fqdn)
and only adds the name if the client provides a blob signed with the
private key corresponding to KEY(fqdn.fqdn) in the DHCP request).

Of course, this whole issue falls back to what PTR is used for.  I
can't come up with even one application that internally use PTR for
anything good.  Not without DNSSEC at least, but there is no DNSSEC.

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Feb 2002 15:37:19 -0800

> reverse zone with a DNS name that points to that forward zone.

but the dhcp server has no way of knowing if the laptop has a trust
relationship with the forward server.  so you can't test that.  when
the trust relationships ain't there, they just ain't there.

and you have no way of knowing if an attempt to update the forward
failed, failed temporarily, succeeded, ...  it's not that someone is
refusing to tell you.  no one can.

i agree that it would be nice if the above was untrue.  but, until it
is, if it does not make you comfortable, then don't run this stuff
to update your reverse dns.

as you note, the threats which might use this weakness are not earth-
shattering.

randy