> > = James > = Ted In message <47b88b0c-ea3e-4222-85a1-95c9d1e67...@fugue.com> Ted Lemon writes: > On Jul 30, 2012, at 11:52 AM, james woodyatt wrote: > > I realize that solving this problem with a standard would involve > > more working groups than HOMENET, but clearly the effort needs to > > start here. Once we have a good idea how to solve this problem, then > > I think it will be easier to talk about forward DNS coherently. > > The work's already started in the dhc working group: > > http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt > > I'd be curious to hear your feedback on this draft.
In most cases where a site has delegation of DNS or rDNS. it is not negociated using DHCP. This draft appears to allow that extension. That is good (IMHO). I think it would be wonderful if providers offered delegation of rDNS and making it trivial for them might not hurt. [Aside: my ISP will not do delegation of rDNS. You have to put in a support call (not web page, not email, a phone call) for any change and that is hugely time consuming for me, and very time consuming and therefore expensive for them. My ISP is stupid in some ways. My IPv6 tunnel provider OTOH has an option on their web page to specify where the rDNS name servers reside and it all works very nicely. Native IPv6 would be better but only if my ISP had a clue about rDNS.] Back to the original email. > > The steps I had to go through to be sure that such queries were > > answerable were not the steps I would want to defend in a feature > > usability review. James gave an example and I don't know what his gripe was, other than getting rDNS to work was not something the home user could tolerate. I agree with that usability point. Looking at the practical side, right now there is a good tie in between ISC dhcpd (DHCP server) and ISC bind (DNS server) for forward DNS. I don't think that rDNS is handled by ISC but I could be wrong. Even so, there is nothing preventing rDNS from being handled. The issue is then that rDNS (like DNS itself) is hard to configure with some of today's tools. ISC tools (for example) are powerful but hard to configure. Some low end routers exist that are much easier to configure, but they lack capabilities. Some of the prior discussions centered around using a default zone of local, such that if a host claimed to be host name "foo" and another claimed to be "bar" then the fqdn would be "foo.local" and "bar.local". It would then be a small matter of configuration to change "local" to "example.com" and have the fqdn reported by rDNS be "foo.example.com" and "bar.example.com". For any of this to make sense some configuration is needed. Someone has to configure "foo" as the host name on one host, and "bar" as the host name on the other, and maybe if they have just one router, they could give it a name too. This would be simple enough to configure. No protocol extension is neede to accomplish this. This is something that could be mentioned in a homenet arch document if we decide that the default local domain is a good idea (and get the appropriate blessings on this use of that TLD) and that dynamic DNS and dynamic rDNS should be available and enabled by default. There are two decisions to be made 1) dynamic DNS and rDNS should be available, 2) they should be enabled by default with "local" domain, easily configured to another name. btw - Even without delegation, accurate rDNS can be provided *locally* which for some users (like those using the default "local" domain) would be sufficient. Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
