Requery on RR expiration automatically

Kevin Darcy kcd at daimlerchrysler.com
Fri Jun 14 22:56:39 UTC 2002


John Morrison wrote:

> > > > Maybe you can arrange to slave the zones in question, if they =
> aren't
> > > > too many? But that still doesn't solve the underlying issue.
> > >
> > > This would be up to a few hundred thousand.
> >=20
> > And you think it would be *better* to continually re-query at least =
> one
> > name in every one of those zones?!?!?
>
> Only upon the expiration. The record in question happens to be the MX =
> record which is usually set to expire quickly I know.
> However much less spam than IXFR don't you think?

If nothing in the zone changes, then all you have is a serial-number check
and that's all. And this would happen approximately every REFRESH seconds,
rather than every TTL seconds, which is usually somewhat smaller. Even in the
"worst case", where something in the zone changes, IXFR is quite efficient.

> > I sure hope you're talking about 100's of thousands of *internal* =
> zones,
> > otherwise surely you must realize how anti-social it would be to=20
> > spam 100's
> > of thousands of other people's nameservers with unnecessary queries, =
> just
> > to humor a vendor's broken implementation of a caching stub resolver.
> > There's no way I could condone anything like that.
>
> HMMM. I can understand if this was all done unnecessarily. However they =
> will be requerried the expiration day anyway.

> So its more like this hour =
> or the next for some, others may be a day off. If the MX ttl is an hour =
> there might be a little unnecessary spam. The upside to this is that =
> users will stop yelling for subscriptions being put on hold or not =
> receiving messages.
>
> I know i may be overcompensating for a vendor flaw. Just wanted to some =
> ideas. Looks like this is not a feasible one.

I'd have to agree.


- Kevin




More information about the bind-users mailing list