How do they handle that?

On Mon, Aug 27, 2018 at 8:02 PM Mark Andrews <ma...@isc.org> wrote:

> Active directory has each domain controller updating its own SRV record
> on the same <qname,qtype,qclass> tuple.  These updates happen at different
> times and need to expire if a domain controller becomes unreachable.
>
> A different case is when you have multiple prefixes from different
> providers with different lifetimes.  You then end up with multiple AAAA
> records that need to expire at different times.
>
> Mark
>
> > On 28 Aug 2018, at 8:34 am, Ted Lemon <mel...@fugue.com> wrote:
> >
> > Sorry, I realized that I accidentally hit "reply" instead of "reply all."
> >
> > The issue that I raised with Tom is that for the DNSSD SRP use case, the
> only names that receive updates from multiple services are service names
> (IOW, not service instance names).   In the case of SRP, PTR RRs in service
> names always point to service instance names, which are per-service, and
> hence can be counted on to expire on a single schedule.   So for the use
> case of SRP, the easiest way to handle deleting service name PTR RRs is to
> take advantage of the semantics of DNSSD: when a service instance SRV
> record expires, also delete the PTR RR on the service name that points to
> it.
> >
> > The reason I bring this up is that it's the most complicated use case I
> know of.   Is there some other use case where we expect more than one DNS
> Update client to be updating RRs of the same type on the same name?   How
> would this even work without SRP semantics?   If this is not expected, then
> any complexity in the timeout RR that's present only to support that use
> case is unnecessary.
> >
> > This is what has been motivating my questions about use cases.   I'm
> sorry I didn't make that clear earlier.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to