In message <[email protected]>, Ted Lemon writes:
> The problem of secondarying the reverse zone isn't really discussed in the dn
> s-pd draft, and there are a number of operational details I'd like to flesh o
> ut, but the specific question of secondarying the reverse zone isn't quite wh
> at it seems.
>
> You secondary a zone so that the contents of the zone will be there when a qu
> ery happens, but why would a query happen if the CPE device isn't reachable?
Log processing.
> What would trigger that query? So I think you can get away with _not_ seco
> ndarying the zone.
It's trivial to secondary a zone. It's even easier when you can have
the forward and reverse zones be the same.
<cust-prefix-rev>.ip6.arpa. DNAME <cust-forward>.
or
<cust-prefix-rev>.ip6.arpa. DNAME <cust-prefix-rev>.<cust-forward>.
No on the fly setup of zones when a new prefix is allocated. Just install
a DNAME record. The second form is for when machines don't have the same
suffix in all prefixes.
The CPE device can make the decision about which form to use.
> But if you do want to secondary it, why would the ISP be
> responsible for that?
So they don't get extra request due to the delegated servers being
unreachable. Giving good answers is cheaper than have to cope with
the effects of the customer's servers being unreachable.
> Presumably the customer is pretty savvy; a secondary
> for their reverse tree would just be another service they'd want to buy or s
> et up, and the ISP could wash their hands of it or sell it, whichever they ch
> ose.
--
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
