In message <[email protected]>, Wouter Cloetens writes:
> On 21/08/12 16:03, Curtis Villamizar wrote:
> >
> > In message<[email protected]>
> > Wouter Cloetens writes:
> >
> >> DOn 18/08/12 05:05, Curtis Villamizar wrote:
> >>>>> When a domain registrar is needed is only when the homenet needs or
> >>>>> wants (maybe for ego reasons) a domain residing in a TLD (such as .com
> >>>>> or .org) and would not accept a subdomain from the provider. For
> >>>>> example the homenet user wants foo.com and would not accept something
> >>>>> of the form foo.site.provider.com, which would be less permanet (the
> >>>>> delegation is lost if switching providers).
> >>>>
> >>>> For security reasons documented in one of the drafts above, it should be
> >>>> disabled by default. A user-defined configuration could open the DNS
> >>>> port to the world, and allow additional domains.
> >>>
> >>> I think you missed the point. This is not a security issue.
> >>
> >> Yes, I got your point, but I'm adding an implication.
> >> The draft explains that this requires opening up the gateway's DNS port
> >> to the world, rather than only to the trusted DNS infrastructure of the
> >> provider. That has some security issues.
> >
> > There is the option for split horzon, but I don't think it should be
> > the default. Having a GUA and not having a DNS name is not a
> > *security* feature. More like paranoia IMHO. Security by obscurity
> > has never worked.
>
> Well, there is the issue of discoverability of the addresses in the
> home. A /64 for your home network is prohibitively expensive to scan by
> enumerating IP addresses. Scanning a list of hostnames based on a
> dictionary reduces the space considerably. Personally, I agree that not
> having a DNS name is indeed security by obscurity. Your IP address can
> be seen by any server with which you communicate already, so I think the
> whole discoverability security element will just shift attackers' focus
> to XSS attacks on web pages. I also think that the advantages of the DNS
> name outweigh the (IMHO small) security risks.
It is trivial to scan a /48 if ip6.arpa is populated for it. There
is too much structure in ip6.arpa to prevent the scan succeeding.
This is independent of whether the zones are signed or not or
whether NSEC or NSEC3 is used when signing the zone.
You query for [0-9a-z].</48-reverse>. For each of these that return
NOERROR you scan for [0-9a-z].</52-reverse>. Repeat until you have
the entire 128 bits for all registered nodes in the /48.
> >> Also, only the provider can give you reverse DNS.
> >
> > The provider can delegate reverse DNS. That is a problem with
> > uncooperative providers.
>
> True, and well, that's a matter of making a business case. If the
> customer is willing to pay for it, or if it creates a competitive
> advantage, then yes. I suspect that there is just not enough money in it
> to make it worth their effort.
There are existing DNS servers that make automatic delegation trivial
to support.
There is deployed code that allows clients to update the delegation
of a /48 that was designed to allow 6to4 reverses to be delegated
in band using TCP as the authenticator. If the update request comes
from the /48 over TCP it is accepted otherwise it is rejected. This
code supports any /48. It is trivial to make it support /52, /56,
/60 and /64 (20 minutes work).
zone "8.B.D.0.1.0.0.2.ip6.arpa" {
type master;
file "8.B.D.0.1.0.0.2.ip6.arpa";
update-policy {
grant dhcpserver subdomain 8.B.D.0.1.0.0.2.ip6.arpa ANY; //
cleanup when lease expires
grant * 6to4-self . NS DNAME DS; //
CPE added these using a TCP
};
};
It was designed to be used like this where updates could be done
over both IPv4 (constructs the matching 2.0.0.2.IP6.ARPA /48 reverse)
and IPv6. Geoff/APNIC went with a HTTP interface rather than a DNS
interface.
zone "2.0.0.2.IP6.ARPA" {
type master;
file "2.0.0.2.ip6.arpa";
update-policy {
grant * 6to4-self . NS DNAME DS;
};
};
Finer grained control is available so you can allow this for subsets
of the reverse space.
zone "8.B.D.0.1.0.0.2.ip6.arpa" {
type master;
file "8.B.D.0.1.0.0.2.ip6.arpa";
update-policy {
grant local:path external . NS DNAME DS;
};
};
> > Otherwise accurate rDNS is site local only, but at least it is
> > accurate at the site.
>
> >> Whereas the provider-delegated domain can be a fully automatic feature,
> >> setting up a personal domain requires the user to do some work.
> >> Registering a domain (could be made simple, from a gateway's web UI),
> >> pointing a nameserver at his gateway (could be automated, DynDNS-style).
> >> It is only logical that a user should also have to disable the secure
> >> default source address restriction of DNS requests.
> >
> > If the user wants no work, the provider delegated subdomain can be
> > reduced to zero work on the part of the customer, and a one time
> > mechanical configuration on the part of the provider at the time that
> > service is initiated (when new customer buys service for first time).
> >
> > Working with a registrar could be made simpler by the registrar, but
> > most homes will never need a *vanity* domain in a TLD.
>
> Exactly.
> It isn't necessarily a registrar that needs to offer the option though.
> A DynDNS provider could offer a vanity non-TLD domain, and delegate
> queries to the gateway. It's even perfect to combine the existing IPv4
> service (e.g. foo.homeunix.net from dyn.com) with the new IPv6
> delegation (router.foo.homeunix.net, printer.foo.homeunix.net,
> mylaptop.foo.homeunix.net, ...)
>
> >> Nonetheless, it is a perfectly valid use case; the IPv6 functional
> >> equivalent of widely used DynDNS in the IPv4 world today. And, of
> >> course, not every operator may implement the automated domain delegation.
> >
> > It seems that today, getting operators to do anything is difficult.
> > Too bad we have so little competition in Internet service. :-(
>
> Note the list of authors on the drafts. ;-) I realised that without
> operator cooperation, nothing is likely to happen, so I was delighted
> when an operator contacted me, and even more delighted when they showed
> a working proof of concept implementation, and were willing to co-author
> the draft.
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
