Minimum TTL?

[LuKreme]

Is it possible to tell bind to ignore very short TTLs and enforce a...say... 5 second minimum TTL?

--
This is my signature. There are many like it, but this one is mine.

[Reindl Harald]

Am 08.02.2018 um 09:52 schrieb LuKreme:
> Is it possible to tell bind to ignore very short TTLs and enforce a...say... 5 second minimum TTL?

no, such a feature was refused because it violates RFC's (questionable
justification for a local decision not enbaled by default) and hence on
a inbound mailserver use unbound which has it

cache-min-ttl: 90
cache-max-negative-ttl: 90

[Michelle Konzack]

Hi,

Am 2018-02-08 hackte LuKreme in die Tasten:

> Is it possible to tell bind to ignore very short TTLs and enforce
> a...say... 5 second minimum TTL?

VERY SHORT TTL?

5 sec minimum?

What Du you mean with ignoring?
It is you YOU have to configure Bind9 correctly to longer TTLs.

If the NS Entry is not a Dyn-DNS entry,
it should have anyway at least 3600 seconds.

[Karol Augustin]

This situation is relevant if bind is acting as recursive DNS server and
upstream record has very short TTL. In that case the record is not kept
cached for longer than 5 seconds and it might be not optimal if this
record is looked up frequently. Some recursive servers have an option to
set minimum TTL and thus overwrite upstream TTL for such records with
some minimal value (like 90s for example).

It has nothing to do with the authoritative mode when yo set up TTL for
zones locally hosted.


k.


--
Karol Augustin
ka...@augustin.pl
http://karolaugustin.pl/
+353 85 775 5312

[Michelle Konzack]

Thankyou for clarification...

Am DATE hackte AUTHOR in die Tasten: Karol Augustin

Michelle Konzack Miila ITSystems @ TDnet
GNU/Linux Developer 00372-54541400

[Reindl Harald]

Am 08.02.2018 um 11:10 schrieb Michelle Konzack:
> Am 2018-02-08 hackte LuKreme in die Tasten:
>> Is it possible to tell bind to ignore very short TTLs and enforce
>> a...say... 5 second minimum TTL?
>
> VERY SHORT TTL?
>
> 5 sec minimum?
>
> What Du you mean with ignoring?
> It is you YOU have to configure Bind9 correctly to longer TTLs.
>
> If the NS Entry is not a Dyn-DNS entry,
> it should have anyway at least 3600 seconds

you miss the topic

many DNSBL's have a very short TTL and at the same time a limit of
queries froma single IP until you need to pay for the service

so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
is trying to deliver spam to you override the 2 scodn TTL with 90
seconds or whatever makes sense reduces the total amount of DNS requests
dramatically

[Michelle Konzack]

Hello Harald,
Am 2018-02-08 hackte Reindl Harald in die Tasten:

> you miss the topic
>
> many DNSBL's have a very short TTL and at the same time a limit of
> queries froma single IP until you need to pay for the service
>
> so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> is trying to deliver spam to you override the 2 scodn TTL with 90
> seconds or whatever makes sense reduces the total amount of DNS requests
> dramatically

Sounds logic.

And this feature was rejected by the Bind Developers?

[Reindl Harald]

Am 08.02.2018 um 12:30 schrieb Michelle Konzack:
> Hello Harald,
> Am 2018-02-08 hackte Reindl Harald in die Tasten:
>> you miss the topic
>>
>> many DNSBL's have a very short TTL and at the same time a limit of
>> queries froma single IP until you need to pay for the service
>>
>> so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
>> is trying to deliver spam to you override the 2 scodn TTL with 90
>> seconds or whatever makes sense reduces the total amount of DNS requests
>> dramatically
>
> Sounds logic.
>
> And this feature was rejected by the Bind Developers?

i remember a response pointing out it would violate RFC's

[John Levine]

In article <mailman.422.151808...@lists.isc.org> you write:
>you miss the topic
>
>many DNSBL's have a very short TTL and at the same time a limit of
>queries froma single IP until you need to pay for the service

This doesn't sound like a technical problem.

Is there some reason you shouldn't pay for the service you're using?

[Reindl Harald]

Am 08.02.2018 um 16:16 schrieb John Levine:
> In article <mailman.422.151808...@lists.isc.org> you write:
>> you miss the topic
>>
>> many DNSBL's have a very short TTL and at the same time a limit of

>> queries from a single IP until you need to pay for the service

>
> This doesn't sound like a technical problem.
> Is there some reason you shouldn't pay for the service you're using?

braindead argumentation because it was a technical problem until you
stepped in

when i try to reduce the amount of dns-queries to the service to reduce
their load because i decide for me that instead 5 seconds 30 or 90
second are "realtime" the R in RBL enough

frankly, even *if* i pay for the service i would call it a good citizen
to produce less load and the "minimum-ttl" also reduces load from other
RBL's without any restriction

additionally you can *not* control your inbound mailflow - so when the
same IP is hammering on your server and you produce 20 times mor DNS
requests than the rest of the year what options do you have - you did
nothing wrong and exceeded limits

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 01:30:04PM +0200, Michelle Konzack wrote:
> Hello Harald,
> Am 2018-02-08 hackte Reindl Harald in die Tasten:

> > you miss the topic
> >
> > many DNSBL's have a very short TTL and at the same time a limit of

> > queries froma single IP until you need to pay for the service
> >
> > so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> > is trying to deliver spam to you override the 2 scodn TTL with 90
> > seconds or whatever makes sense reduces the total amount of DNS requests
> > dramatically
>
> Sounds logic.
>
> And this feature was rejected by the Bind Developers?

If the RRset wants a TTL of N seconds, then that is the authoritative
instruction from the owner of the zone about how the data should be
used. We have to follow that. The RFCs so far do not allow increasing
TTL, though they allow decreasing it.

If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
about why it is so. There ought to be a reason from their perspective
why it is set to 2s.

Mukund

[Reindl Harald]

so what - nobody can force me to ask him the same question every 2
seconds and as long it's a local resolver for my own services the one i
have to ask about any why in doubt is the person i face in the mirror
every morning

yes, you are free to decide that named don't need to support the users
wish of such a feature. but the result is that the user stops to use
named at all on a inbound-mailserver and is done

[Reindl Harald]

and BTW - i don't need to ask the zone owner because common sense has
the answer already: to have answers as real-time as possible nad let as
less as possible new listings slip through

it's still my decision as mailadmin if i need that accuracy

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 04:39:36PM +0100, Reindl Harald wrote:
>
>
> Am 08.02.2018 um 16:34 schrieb Mukund Sivaraman:
> > On Thu, Feb 08, 2018 at 01:30:04PM +0200, Michelle Konzack wrote:
> > > Hello Harald,
> > > Am 2018-02-08 hackte Reindl Harald in die Tasten:
> > > > you miss the topic
> > > >
> > > > many DNSBL's have a very short TTL and at the same time a limit of
> > > > queries froma single IP until you need to pay for the service
> > > >
> > > > so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> > > > is trying to deliver spam to you override the 2 scodn TTL with 90
> > > > seconds or whatever makes sense reduces the total amount of DNS requests
> > > > dramatically
> > >
> > > Sounds logic.
> > >
> > > And this feature was rejected by the Bind Developers?
> >
> > If the RRset wants a TTL of N seconds, then that is the authoritative
> > instruction from the owner of the zone about how the data should be
> > used. We have to follow that. The RFCs so far do not allow increasing
> > TTL, though they allow decreasing it.
> >
> > If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
> > about why it is so. There ought to be a reason from their perspective
> > why it is set to 2s
>
> so what - nobody can force me to ask him the same question every 2 seconds
> and as long it's a local resolver for my own services the one i have to ask
> about any why in doubt is the person i face in the mirror every morning

I doubt the zone owner is forcing you to use their zone. You can nix
fetches to it. If you want the zone data, then follow what the zone
owner requires.

> yes, you are free to decide that named don't need to support the users
> wish of such a feature. but the result is that the user stops to use
> named at all on a inbound-mailserver and is done

Also, just for argument's sake, one user wants to extend TTLs to
5s. Another wants 60s TTLs. What is OK and what is going too far?

It really is something for the zone owner to consider.

Mukund

[Barry Margolin]

In article <mailman.427.151810...@lists.isc.org>,

Reindl Harald <h.re...@thelounge.net> wrote:

> frankly, even *if* i pay for the service i would call it a good citizen
> to produce less load and the "minimum-ttl" also reduces load from other
> RBL's without any restriction

If the service provider is worried about load, they should increase
their TTL to reduce the frequency of queries. It's not your job to
second-guess them.

There are some servers that will avoid expiring records if the auth
servers stop responding, as a fail-safe mechanism. I think Google Public
DNS does this. So they obey TTL when deciding when to try to refresh the
cache, but will continue returning whatever they've cached if necessary.

--
Barry Margolin
Arlington, MA

[Reindl Harald]

Am 08.02.2018 um 16:51 schrieb Mukund Sivaraman:
> On Thu, Feb 08, 2018 at 04:39:36PM +0100, Reindl Harald wrote:
>> Am 08.02.2018 um 16:34 schrieb Mukund Sivaraman:
>>> If the RRset wants a TTL of N seconds, then that is the authoritative
>>> instruction from the owner of the zone about how the data should be
>>> used. We have to follow that. The RFCs so far do not allow increasing
>>> TTL, though they allow decreasing it.
>>>
>>> If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
>>> about why it is so. There ought to be a reason from their perspective
>>> why it is set to 2s
>>
>> so what - nobody can force me to ask him the same question every 2 seconds
>> and as long it's a local resolver for my own services the one i have to ask
>> about any why in doubt is the person i face in the mirror every morning
>
> I doubt the zone owner is forcing you to use their zone. You can nix
> fetches to it. If you want the zone data, then follow what the zone
> owner requires.

does not matter

>> yes, you are free to decide that named don't need to support the users
>> wish of such a feature. but the result is that the user stops to use
>> named at all on a inbound-mailserver and is done
>
> Also, just for argument's sake, one user wants to extend TTLs to
> 5s. Another wants 60s TTLs. What is OK and what is going too far?

that's simply the users decision - problem solved

> It really is something for the zone owner to consider

for sure not

[Tony Finch]

Reindl Harald <h.re...@thelounge.net> wrote:
>
> yes, you are free to decide that named don't need to support the users wish of
> such a feature. but the result is that the user stops to use named at all on a
> inbound-mailserver and is done

Or you could use patched versions from FreeBSD or Debian ...

https://svnweb.freebsd.org/ports/head/dns/bind912/files/extrapatch-bind-min-override-ttl?view=markup
https://sources.debian.org/src/bind9/1:9.11.2.P1-1/debian/patches/10_min-cache-ttl.diff/

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Lundy, Fastnet: Southwest 5 to 7 veering northwest 6 to gale 8. Rough or very
rough. Rain then showers. Good, occasionally poor at first.

[Reindl Harald]

Am 08.02.2018 um 17:03 schrieb Barry Margolin:
> In article <mailman.427.151810...@lists.isc.org>,
> Reindl Harald <h.re...@thelounge.net> wrote:
>

>> frankly, even *if* i pay for the service i would call it a good citizen
>> to produce less load and the "minimum-ttl" also reduces load from other
>> RBL's without any restriction
>

> If the service provider is worried about load, they should increase
> their TTL to reduce the frequency of queries. It's not your job to
> second-guess them.

let my job me my own problem - seriously - my server - my rules - period

if named can't serve my needs than "dnf remove bind; dnf install
unbound" is the solution and was it on mailservers

named is great as authoritative server but not for RBL's which also can
be used on webserver (web-application firewall where you try to reduce
latency as much as you can)

[Tony Finch]

Barry Margolin <bar...@alum.mit.edu> wrote:

> There are some servers that will avoid expiring records if the auth
> servers stop responding, as a fail-safe mechanism.

For instance, BIND 9.12 - https://www.isc.org/blogs/bind-9-12-almost-ready/

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode

Irish Sea: Southwest 5 to 7 veering northwest 6 to gale 8, perhaps severe gale
9 later. Slight or moderate, becoming moderate or rough. Rain then wintry
showers. Good, occasionally poor.

[Matus UHLAR - fantomas]

>Reindl Harald <h.re...@thelounge.net> wrote:
>>
>> yes, you are free to decide that named don't need to support the users wish of
>> such a feature. but the result is that the user stops to use named at all on a
>> inbound-mailserver and is done

On 08.02.18 16:07, Tony Finch wrote:
>Or you could use patched versions from FreeBSD or Debian ...
>
>https://svnweb.freebsd.org/ports/head/dns/bind912/files/extrapatch-bind-min-override-ttl?view=markup
>https://sources.debian.org/src/bind9/1:9.11.2.P1-1/debian/patches/10_min-cache-ttl.diff/

FYI, it's there for years.

bind9 (1:9.6.0.dfsg.P1-1) experimental; urgency=low

[Michael Milligan]

* Add min-cache-ttl and min-ncache-ttl keywords

[LaMont Jones]

* Fix merge errors from 9.6.0.dfsg.P1-0

-- LaMont Jones <lam...@debian.org> Fri, 20 Mar 2009 15:50:50 -0600


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 05:05:51PM +0100, Reindl Harald wrote:
> > I doubt the zone owner is forcing you to use their zone. You can nix
> > fetches to it. If you want the zone data, then follow what the zone
> > owner requires.
>
> does not matter

It matters to us.

Mukund

[Reindl Harald]

it's not your business to make local decisions, your business are sane
defaults and warning from such override options to use them outside
specific workloads but that's it

do what you want - i do too and throw out software which don't give me
options i want to have that way when competitors provide them because i
have no time for political stuff when i need to configure a server which
is in my responsibility

[Reindl Harald]

Am 08.02.2018 um 17:07 schrieb Tony Finch:
> Reindl Harald <h.re...@thelounge.net> wrote:
>>
>> yes, you are free to decide that named don't need to support the users wish of
>> such a feature. but the result is that the user stops to use named at all on a
>> inbound-mailserver and is done
>

> Or you could use patched versions from FreeBSD or Debian ...
>
> https://svnweb.freebsd.org/ports/head/dns/bind912/files/extrapatch-bind-min-override-ttl?view=markup
> https://sources.debian.org/src/bind9/1:9.11.2.P1-1/debian/patches/10_min-cache-ttl.diff/

yeah, i will switch from Fedora to Debian or start to maintain named
including patches on my own instead just use a different package out of
the distribution repos which can do the same and let me control *my*
server as i want out-of-the-box

won't happen :-)

[Grant Taylor]

On 02/08/2018 08:51 AM, Mukund Sivaraman wrote:
> Also, just for argument's sake, one user wants to extend TTLs to
> 5s. Another wants 60s TTLs. What is OK and what is going too far?

I think what is "OK" is up to each administrator.

Obviously the zone administrators have decided that they want people to
use the 2s TTL.

That being said, it is up to each individual recursive server operator
if they want to honor what the zone administrators have published, or if
the recursive administrators want to override published desires.

> It really is something for the zone owner to consider.

Yes and no. Yes it's up to the zone owner to consider what intentions
that they want to publish. No, the zone owner has no influence on how I
operate my servers. I choose how I operate my servers.

If I choose to operate my servers in a manner that ignores the zone
owner's published desires, that's on me.

I feel like this discussion is really two issues: 1) Does the
capability to override published values and 2) should I use said
capability. They really are two different questions. I personally
would like to see BIND have the option to do #1, even if I never use it.



--
Grant. . . .
unix || die

[Bob Harold]

+1 

 

--
Grant. . . .
unix || die

-- 

Bob Harold

 

[sth...@nethelp.no]

> I think what is "OK" is up to each administrator.
>
> Obviously the zone administrators have decided that they want people to
> use the 2s TTL.
>
> That being said, it is up to each individual recursive server operator
> if they want to honor what the zone administrators have published, or if
> the recursive administrators want to override published desires.
>
> > It really is something for the zone owner to consider.
>
> Yes and no. Yes it's up to the zone owner to consider what intentions
> that they want to publish. No, the zone owner has no influence on how I
> operate my servers. I choose how I operate my servers.

Yesterday I measured, on our busiest resolvers, the amount of replies
with TTL=0 the resolvers received (from the authoritative servers).
Turns out we receive around 2.3 percent replies with TTL=0. This is
a percentage I can live with, and I see no reason to artificially
inflate the TTL.

That being said - if the percentage had been significantly higher, I
would feel it was perfectly reasonable to set a minimum TTL of for
instance 10s. I agree that this is a decision for each operator.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

[Reindl Harald]

and i can tell you from where they are coming:

CISCO router with "DNS-ALG" between primary and slave writing in front
of every CNAME explicit a TTL 0 statement - was there and it takes a
long time until you realize that your slave repsonds with differnt data
as you configured

[Matus UHLAR - fantomas]

>Am 09.02.2018 um 07:02 schrieb sth...@nethelp.no:
>>Yesterday I measured, on our busiest resolvers, the amount of replies
>>with TTL=0 the resolvers received (from the authoritative servers).
>>Turns out we receive around 2.3 percent replies with TTL=0. This is
>>a percentage I can live with, and I see no reason to artificially
>>inflate the TTL.
>>
>>That being said - if the percentage had been significantly higher, I
>>would feel it was perfectly reasonable to set a minimum TTL of for
>>instance 10s. I agree that this is a decision for each operator.

On 09.02.18 08:21, Reindl Harald wrote:
>and i can tell you from where they are coming:
>
>CISCO router with "DNS-ALG" between primary and slave writing in
>front of every CNAME explicit a TTL 0 statement - was there and it
>takes a long time until you realize that your slave repsonds with
>differnt data as you configured

which, in advance, hugely increases the amount of DNS queries sent by
clients for hosts that are widely used. That can backfire and hugely
increase load (session count) on those cisco routers.

Using min-ttl would help much there. And it's the part that can be fixed on
side of BIND without waiting for network admins.

been there too...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

I don't have lysdexia. The Dog wouldn't allow that.

[Tony Finch]

Reindl Harald <h.re...@thelounge.net> wrote:
>
> CISCO router with "DNS-ALG"

Oh god, never turn on PIX/ASA protocol fuxup features.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode

Malin: West 5 or 6, backing south 7 to severe gale 9 for a time. Very rough or
high. Rain or wintry showers. Good, occasionally poor.

[Warren Kumari]

Leave off the "protocol fixup feature", its cleaner....

:-P

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf

[Reindl Harald]

Am 09.02.2018 um 13:15 schrieb Tony Finch:
> Reindl Harald <h.re...@thelounge.net> wrote:
>>
>> CISCO router with "DNS-ALG"
>
> Oh god, never turn on PIX/ASA protocol fuxup features

well, i did not know that the ISP ships that crap with the feature
enabled and even if i did not imagine that it takes a zone-transfer on
the wire and starts to playing games with the data....

[Barry Margolin]

In article <mailman.441.151812...@lists.isc.org>,

As long as you understand the implications of what you're doing?

The zone owner may be using short TTLs to implement load balancing
and/or quick failover. If you extend the TTLs, your users may experience
poor performance when they try to go to these sites using out-of-date
cache entries.

[Reindl Harald]

Am 09.02.2018 um 17:37 schrieb Barry Margolin:
> In article <mailman.441.151812...@lists.isc.org>,
> Grant Taylor <gta...@tnetconsulting.net> wrote:
>

> As long as you understand the implications of what you're doing?
>
> The zone owner may be using short TTLs to implement load balancing
> and/or quick failover. If you extend the TTLs, your users may experience
> poor performance when they try to go to these sites using out-of-date
> cache entries

but that's my problem then and not yours - it's that simple

[Barry Margolin]

In article <mailman.452.151819...@lists.isc.org>,

Reindl Harald <h.re...@thelounge.net> wrote:

> > As long as you understand the implications of what you're doing?
> >
> > The zone owner may be using short TTLs to implement load balancing
> > and/or quick failover. If you extend the TTLs, your users may experience
> > poor performance when they try to go to these sites using out-of-date
> > cache entries
>
> but that's my problem then and not yours - it's that simple

Sure, but the Internet was designed on a philosophy of cooperation. An
ISP could also drop every other packet, and say "that's my problem, not
yours", but we wouldn't consider that to be a reasonable way to run a
network.

IMHO you should at least be transparent about it, so your users know
what they're in for.

[Reindl Harald]

Am 09.02.2018 um 17:45 schrieb Barry Margolin:
> In article <mailman.452.151819...@lists.isc.org>,
> Reindl Harald <h.re...@thelounge.net> wrote:
>

>>> As long as you understand the implications of what you're doing?
>>>
>>> The zone owner may be using short TTLs to implement load balancing
>>> and/or quick failover. If you extend the TTLs, your users may experience
>>> poor performance when they try to go to these sites using out-of-date
>>> cache entries
>>
>> but that's my problem then and not yours - it's that simple
>

> Sure, but the Internet was designed on a philosophy of cooperation. An
> ISP could also drop every other packet, and say "that's my problem, not
> yours", but we wouldn't consider that to be a reasonable way to run a
> network.
>
> IMHO you should at least be transparent about it, so your users know
> what they're in for

where i would place that option "my users" are my servers (inbound MX,
RBL's hence unbound there, but you would know that if you would have
followed the thread)

another usecase are 5 seconds or so to mask problems of the zone-owner
where all his slaves are victims of Cisco hardware and mangle CNAMEs in
zone-transfers with a "$TLL 0" in front of them while the whole domain
was intened to have a global 86400 seconds TTL

one needs me to show a single example where human users would have a
non-theoretical differnece between 2 and 5 seconds..

but you would also know that if you have followed the thread

[Reindl Harald]

Am 09.02.2018 um 17:45 schrieb Barry Margolin:
> In article <mailman.452.151819...@lists.isc.org>,
> Reindl Harald <h.re...@thelounge.net> wrote:
>

>>> As long as you understand the implications of what you're doing?
>>>
>>> The zone owner may be using short TTLs to implement load balancing
>>> and/or quick failover. If you extend the TTLs, your users may experience
>>> poor performance when they try to go to these sites using out-of-date
>>> cache entries
>>
>> but that's my problem then and not yours - it's that simple
>

> Sure, but the Internet was designed on a philosophy of cooperation. An
> ISP could also drop every other packet, and say "that's my problem, not
> yours", but we wouldn't consider that to be a reasonable way to run a
> network

you mix things which must never be mixed - never

the ISP has no business to touch any package bewteen source and me
because he can't know the implications - he even must not know about
them because it#s not his business

the admin of the destination network is in a completly differnt position
and knos about the implications because it's his job

[John Levine]

In article <mailman.451.151819...@lists.isc.org> you write:
>As long as you understand the implications of what you're doing?
>
>The zone owner may be using short TTLs to implement load balancing
>and/or quick failover. If you extend the TTLs, your users may experience
>poor performance when they try to go to these sites using out-of-date
>cache entries.

The zone in question is a DNSBL. When an address is added to or
removed from a dynamically maintained BL, the short TTL means clients
pick it the change promptly. If you want your mail filtering to work
reliably, you pay attention to that. Some of Spamhaus' BLs have
minimum TTLs of 10 seconds, and they do update that fast (not using
BIND, of course.)

The person who asked the original question made it quite clear that
his goal is use a commercial DNSBL but avoid paying for it, so I don't
see any need to offer further help.

R's,
John

[Grant Taylor]

On 02/09/2018 09:37 AM, Barry Margolin wrote:
> As long as you understand the implications of what you're doing?

I don't think my level of understanding has any impact of my ability to
override what the zone publisher sets the desired TTL (or any value) to be.

I have the right to run my network the way that I want to, even in my
ignorance or while shooting myself in the foot.

> The zone owner may be using short TTLs to implement load balancing and/or
> quick failover. If you extend the TTLs, your users may experience poor
> performance when they try to go to these sites using out-of-date cache
> entries.

Again, by choosing to do something, as questionable as it may be, I am
also choosing the responsibility for the outcome, for better or for worse.

[@lbutlr]

On 2018-02-08 (03:10 MST), Michelle Konzack <linux4m...@tamay-dogan.net> wrote:
>
> Hi,
>
> Am 2018-02-08 hackte LuKreme in die Tasten:
>> Is it possible to tell bind to ignore very short TTLs and enforce
>> a...say... 5 second minimum TTL?
>
> VERY SHORT TTL?

YEs.

> 5 sec minimum?

Yes.

> What Du you mean with ignoring?

Ignoring responses with TTLs or <5 seconds and treating them as if the TTL was 5 seconds.

> It is you YOU have to configure Bind9 correctly to longer TTLs.

I cannot configure bind for other DNS servers.

> If the NS Entry is not a Dyn-DNS entry,
> it should have anyway at least 3600 seconds.

"Should" is a pointless word 99.999% of the time it is used.


--
i wasn't born a programmer. i became one because i was impatient. - Dave
Winer

[@lbutlr]

On 2018-02-08 (08:51 MST), Mukund Sivaraman <mu...@isc.org> wrote:
>
> Also, just for argument's sake, one user wants to extend TTLs to
> 5s. Another wants 60s TTLs. What is OK and what is going too far?

For the record, the issue is not RBLs or legitimate domains, it is spammer scum that set super-low DNS because they are shotgunning spam from a a vast botnet and they want to have maximal impact, so you get a different IP for every spam they send. It is a way of trying to overwhelm a machines tarpits, blacklists, sshguard protections, and others.

But to answer your question, off-hand, I'd say that any TTL under 60s is suspicious and any TTL under 10s is almost certainly intentionally abusive.

But that's just me, giving it maybe 20 seconds of thought.

--
So now you know the words to our song, pretty soon you'll all be singing
along, when you're sad, when you're lonely and it all turns out wrong...

[Grant Taylor]

On 02/09/2018 05:26 PM, @lbutlr wrote:
> But to answer your question, off-hand, I'd say that any TTL under 60s
> is suspicious and any TTL under 10s is almost certainly intentionally
> abusive.

I thought there was a lower recommended boundary, particularly to detect
and avoid things like fast flux.

I /thought/ it was somewhere between 1 and 5 minutes.

[John Levine]

In article <mailman.459.151822...@lists.isc.org> you write:
>For the record, the issue is not RBLs or legitimate domains, it is =
>spammer scum that set super-low DNS because they are shotgunning spam =
>from a a vast botnet and they want to have maximal impact, so you get a =
>different IP for every spam they send. It is a way of trying to =
>overwhelm a machines tarpits, blacklists, sshguard protections, and =
>others.

Um, you have it completely backward. Botnets are computers with IP
addresses. They don't need DNS pointing at them to send spam. DNSBLs
with low TTLs try and list them the moment the first spam hits the
spamtraps.

There is fast flux DNS for computers running landing pages, but they
tend to use a lot of A records at once and don't care about the TTL
since they're going for quantity, not quality.

>But to answer your question, off-hand, I'd say that any TTL under 60s is =
>suspicious and any TTL under 10s is almost certainly intentionally =
>abusive.

I hope you're not planning to do much spam filtering.

R's,
John

[Matus UHLAR - fantomas]

>>But to answer your question, off-hand, I'd say that any TTL under 60s is =
>>suspicious and any TTL under 10s is almost certainly intentionally =
>>abusive.

On 09.02.18 23:11, John Levine wrote:
>I hope you're not planning to do much spam filtering.

do you have any evidence where enforcing a 5s minumum leads to serious
problems?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them

[@lbutlr]

On 2018-02-09 (21:11 MST), John Levine <jo...@iecc.com> wrote:
>
> In article <mailman.459.151822...@lists.isc.org> you write:
>> For the record, the issue is not RBLs or legitimate domains, it is =
>> spammer scum that set super-low DNS because they are shotgunning spam =
>> from a a vast botnet and they want to have maximal impact, so you get a =
>> different IP for every spam they send. It is a way of trying to =
>> overwhelm a machines tarpits, blacklists, sshguard protections, and =
>> others.
>
> Um, you have it completely backward.

No, I don't.

AS I explained upthread, the mechanism works something like this.

buy garbage domain. Setup DNS with a TTL of 1S and have the IP change to random machines on your botnet.

Spew Spam at a single mail server.

The target, instead of very quickly rejecting the spam because of the lack of a domain or the lack of DNS, instead has to deal with thousands of different IPs.

Everyone of those is going to hit scammer scums DNS servers.

At some point those thousands (tens of thousands? hundreds of thousands?) requests are going to have a serious impact on your mail server. Meanwhile, you are giving spammer scum a lot of information about how much traffic your server can deal with since they can easily see when your responses start to slow down.

> Botnets are computers with IP addresses. They don't need DNS pointing at them to send spam.

They do to send spam to any mail admin with even half a brain who would not accept unauthenticated mail from an IP without an actual domain attached.

> I hope you're not planning to do much spam filtering.

a 5s TTL will not make an appreciable effect on RBLs

--
If you mixed vodka with orange juice and Milk Of Magnesia, would you get
a Philip's Screwdriver?

[Barry Margolin]

In article <mailman.457.151821...@lists.isc.org>,

Grant Taylor <gta...@tnetconsulting.net> wrote:

> On 02/09/2018 09:37 AM, Barry Margolin wrote:
> > As long as you understand the implications of what you're doing?
>
> I don't think my level of understanding has any impact of my ability to
> override what the zone publisher sets the desired TTL (or any value) to be.
>
> I have the right to run my network the way that I want to, even in my
> ignorance or while shooting myself in the foot.

Just because you have the right to do something doesn't mean it's a
reasonable thing to do.

And if you're offering a service, you have responsibilities to your
customers in addition to rights. They likely have expectations of the
quality of your service. Sure, you have the right to disappoint them,
but do you really want to do that intentionally if you have alternatives?

[John Levine]

In article <mailman.463.151828...@lists.isc.org> you write:
>The target, instead of very quickly rejecting the spam because of the =
>lack of a domain or the lack of DNS, instead has to deal with thousands =
>of different IPs.

That's not how spam filters work. They do filtering based on the IP
address sending the spam and maybe the rDNS. It makes no difference
whatsoever if there is some other random A record pointing at the
spamming host. You can't even tell.

>> Botnets are computers with IP addresses. They don't need DNS pointing =

>at them to send spam.
>

>They do to send spam to any mail admin with even half a brain who would =
>not accept unauthenticated mail from an IP without an actual domain =
>attached.

The half a brain generally requires forward and reverse DNS to match
before using them. If you know a way to do fast flux rDNS on botnets,
I know a lot of people who'd like to talk to you.

R's,
John

[Warren Kumari]

Ok, so I've never used forwarders (actually, that's not strictly true;
I've used them twice, but it was to work around weird issues, and I
felt dirty), but couldn't increasing the TTL cause stupid
configuration issues to become immortal RRs?

I've seen a number of instances where people who *do* forward manage
to make a loop - this works just fine under normal conditions (at
least with BIND's default of "forward first" - resolver A gets a
question for an answer not in it's cache, it asks B, B asks A, after a
few rounds this hits the forward timeout, and one of them recurses to
find the answer. Now the pair (or pathologically, group) has the
answer, and this will decay, just like any other TTL. Eventually it
expires, you get a brief spike as they both ask each other, and the
process repeats.

If TTLs were capped to a minimum, A would time it out, and ask B. B
will respond with e.g 4 seconds, and A will bump that back up to 5. 4
seconds later, B will time out, and will ask A. A still has 1 second
left, to it answers with 1. B helpfully bumps that back to 5, 1 second
later, A expires, and forwards to B, ...

Now, I'm guessing that I'm missing something obvious here (more than
"Well, don't forward and minimum cap TTLs!" and / or "Don't make loops
of forwarders, it's silly"), but I'm not sure what...

W

On Sat, Feb 10, 2018 at 2:42 PM, Matus UHLAR - fantomas
<uh...@fantomas.sk> wrote:
>>> But to answer your question, off-hand, I'd say that any TTL under 60s is

>>> =
>>> suspicious and any TTL under 10s is almost certainly intentionally =
>>> abusive.
>
>
> On 09.02.18 23:11, John Levine wrote:
>>

>> I hope you're not planning to do much spam filtering.
>
>

> do you have any evidence where enforcing a 5s minumum leads to serious
> problems?
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> One OS to rule them all, One OS to find them, One OS to bring them all

> and into darkness bind them _______________________________________________

[Matus UHLAR - fantomas]

>>>> But to answer your question, off-hand, I'd say that any TTL under 60s is

>>>> =
>>>> suspicious and any TTL under 10s is almost certainly intentionally =
>>>> abusive.

>> On 09.02.18 23:11, John Levine wrote:
>>> I hope you're not planning to do much spam filtering.

>On Sat, Feb 10, 2018 at 2:42 PM, Matus UHLAR - fantomas
><uh...@fantomas.sk> wrote:
>> do you have any evidence where enforcing a 5s minumum leads to serious
>> problems?

On 10.02.18 19:41, Warren Kumari wrote:
>Ok, so I've never used forwarders (actually, that's not strictly true;
>I've used them twice, but it was to work around weird issues, and I
>felt dirty), but couldn't increasing the TTL cause stupid
>configuration issues to become immortal RRs?

we are talking about min-ttl around 10 seconds.

>I've seen a number of instances where people who *do* forward manage
>to make a loop - this works just fine under normal conditions (at
>least with BIND's default of "forward first" - resolver A gets a
>question for an answer not in it's cache, it asks B, B asks A, after a
>few rounds this hits the forward timeout, and one of them recurses to
>find the answer. Now the pair (or pathologically, group) has the
>answer, and this will decay, just like any other TTL. Eventually it
>expires, you get a brief spike as they both ask each other, and the
>process repeats.
>
>If TTLs were capped to a minimum, A would time it out, and ask B. B
>will respond with e.g 4 seconds, and A will bump that back up to 5. 4
>seconds later, B will time out, and will ask A. A still has 1 second
>left, to it answers with 1. B helpfully bumps that back to 5, 1 second
>later, A expires, and forwards to B, ...
>
>Now, I'm guessing that I'm missing something obvious here (more than
>"Well, don't forward and minimum cap TTLs!" and / or "Don't make loops
>of forwarders, it's silly"), but I'm not sure what...

OTOH, I have encountered case where CISCO ALG changed A recods and set TTL
to 0, later admin was complaining about huge number of DNS queries causing
high load on the router...

there are many ways to fsck things up, and many ways wayt so avoid that.
forcing min-ttl is way to avoid one, although it can cause what you
describe. But I do not create loops and would like a possibility to avoid
the latter case.

Note that I am able to coifigure BIND to avoid loops, but I can't affect
CISCO ALG ...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

[Grant Taylor]

On 02/10/2018 12:15 PM, Barry Margolin wrote:
> Just because you have the right to do something doesn't mean it's a
> reasonable thing to do.

I never meant to imply that it was the reasonable thing to do.

I meant to imply that it is my choice how I run my servers.

> And if you're offering a service, you have responsibilities to your
> customers in addition to rights. They likely have expectations of the
> quality of your service. Sure, you have the right to disappoint them,
> but do you really want to do that intentionally if you have alternatives?

Part of what my customers paid me to do for 15 years was to run the
network the way that I thought was best. In other words, they were
paying me for my professional opinion.

Granted, it behooved me to make sure that my opinion took into account
their needs. That being said, I would tell at least one client a year,
"I'll do that if you tell me that's what you want. However my better
judgment says to do otherwise." That's when conversations would ensue
and usually one or the other of us would change our opinion. Usually it
was because one or both of us did not have all the information.
Sometimes it was me, sometimes it was them. But we did trust each other
and respect each others opinion, particularly when it diverged form the
beaten path.

[@lbutlr]

On 2018-02-10 (12:15 MST), Barry Margolin <bar...@alum.mit.edu> wrote:
>
> Just because you have the right to do something doesn't mean it's a reasonable thing to do.

No one has made an argument that would imply this is not reasonable.

> And if you're offering a service, you have responsibilities to your customers in addition to rights. They likely have expectations of the quality of your service. Sure, you have the right to disappoint them, but do you really want to do that intentionally if you have alternatives?

I don't think anyone is expecting that respecting a 1-4s TTL is part of a service arrangement.


--
Outside of a dog, a book is a man's best friend. Inside of a dog, it's
too dark to read.

[wbr...@e1b.org]

From: "Reindl Harald" <h.re...@thelounge.net>
> To: bind-...@lists.isc.org

> the ISP has no business to touch any package bewteen source and me
> because he can't know the implications - he even must not know about
> them because it#s not his business

And yet they do (Supercookies?), and sell that data to any and all buyers.



Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

[Reindl Harald]

Am 12.02.2018 um 20:36 schrieb wbr...@e1b.org:
> From: "Reindl Harald" <h.re...@thelounge.net>
>> To: bind-...@lists.isc.org
>
>> the ISP has no business to touch any package bewteen source and me
>> because he can't know the implications - he even must not know about
>> them because it#s not his business
>
> And yet they do (Supercookies?), and sell that data to any and all buyers

but *that* was not the point which you stripped (by intention?) from the
quote

[Reindl Harald]

Am 10.02.2018 um 05:11 schrieb John Levine:
>> But to answer your question, off-hand, I'd say that any TTL under 60s is =
>> suspicious and any TTL under 10s is almost certainly intentionally =
>> abusive.
>

> I hope you're not planning to do much spam filtering

i do for years with a min-ttl of 90 secods and you will have a hard-time
to beat our results - using a mix of many DNSBL/DNSWL on postsrceen as
well as SpamAssasin does the trick and not ordianry low TTL's