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.
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.
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
