In message <[email protected]> Michael Richardson writes: > > >>>>> "Ted" =3D=3D Ted Lemon <[email protected]> writes: > Ted> You secondary a zone so that the contents of the zone will be > Ted> there when a query happens, but why would a query happen if the > Ted> CPE device isn't reachable? What would trigger that query? > Ted> So I think you can get away with _not_ secondarying the zone. > Ted> But if you do want to secondary it, why would the ISP be > Ted> responsible for that? Presumably the customer is pretty > Ted> savvy; a secondary for their reverse tree would just be another > Ted> service they'd want to buy or set up, and the ISP could wash > Ted> their hands of it or sell it, whichever they chose.=20 > > My suggestion is that the ISP secondary the zone from the CPE, but > actually advertise only their server in the NS delegation. (The CPE > remains a stealth primary) > > The CPE will have multiple addresses, usually at least two, as it has at > least two interfaces. The CPE address which the ISP most knows about > and is most easily reachable is the outside address (the ISP facing > one). That address, if auto-configured, could trivially change if > the CPE is replaced (or replugged into a different port), or if the CPE > used privacy extensions. So we'll need a low TTL on that NS/AAAA > record. > > If we use the internal address from the CPE, which is likely in the > prefix that was delegated, and therefore very unlikely to change (and I > think some people have even proposed to make the host part well-known!), > it is possibly more stable, but it instantly introduces an exception to > the CPE firewall rules. > > Out of these two choices, neither is particularly bad, but as you > indicated, when the customer is down, the data is inaccessible. > > If the ISP has a copy (and might keep some history of it), then the ISP > is in a position to indicate to the customer what host is what. > Consider an ISP that has detected a home system infected with some > malware. Said ISP has either quaranteed or has disconnected that > customer. Customer will not understand > "host 2001:DB8:0001:1234:0234:45fe:ff01:4567 is infected" > > but, might understand: > "host suzie-derkins is infected" > > this could also be done if the ISP actually recorded the mapping from > ..:4567->susie-derkins at the time the event occured, and maybe that's > really the answer here.
The ISP is not doing dyndns, the CPE router is doing that and the provider is secondary to that zone. The zone should have a short TTL (less than lease duration) and a long expire time to make it likely that the secondary is giving accurate answers and keeps giving answers for a while after the primary has gone away. > I'm thinking that ISPs might want to have more control over what's in > the reverse. (I don't really like that myself, but...) But not the forward? If the forward is <host>.<site-email>.site.<provider-fqdn> -> <addr> and the reverse is <inaddr>.arpa -> <host>.<site-email>.site.<provider-fqdn>, why is one OK and the other not OK. > Perhaps there are privacy concerns if the ISP has this mapping recorded, > and it would be better if the CPE was the only place with the info. If its published in global DNS, recording it should not be a privacy concern. > Michael Richardson <[email protected]>, Sandelman Software Works=20 > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
