TTL and min. TTL set to 0
baranyaib90 opened this issue · 6 comments
The "ttl" and "min_ttl" can not set to 0 because of omitempty option!
Please allow 0 as TTL value, because of https://www.ietf.org/rfc/rfc1035.txt:
TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.
Use case:
Bind9 (with caching) before SkyDNS, BUT we do not want to cache Service Discovery (SkyDNS) requests even for 1 second!
Reference:
https://github.com/tmaczukin/docker-bind9/tree/master/assets/bind-configuration
And adding cache into the bind options.
Thank you!
[ Quoting notifications@github.com in "[skynetservices/skydns] TTL and min..." ]
The "ttl" and "min_ttl" can not set to 0 because of omitempty option!
Please allow 0 as TTL value, because of https://www.ietf.org/rfc/rfc1035.txt:TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.Use case:
Bind9 (with caching) before SkyDNS, BUT we do not want to cache Service Discovery (SkyDNS) requests even for 1 second!Reference:
https://github.com/tmaczukin/docker-bind9/tree/master/assets/bind-configuration
And adding cache into the bind options.Thank you!
http://www.zytrax.com/books/dns/ch7/hkpng.html#max-cache-ttl
Hi miekg,
I know about this option.
But: "This statement may be used in view or a global options clause."
This work-around is not acceptable in my case, because I want 2 zones:
options {
max-ncache-ttl 5;
max-cache-ttl 15;
max-cache-size 10M;
minimal-responses yes;
recursion yes;
...
};
zone "." in{
type forward;
forward only;
forwarders {
8.8.8.8;
8.8.4.4;
};
};
zone "local." in{
type forward;
forward only;
forwarders {
skydns_ip_here;
};
};
One zone for any internet domain and one for Service Discovery (SkyDNS).
Inside zone, you cant change cache.
View is also not an option, because view is based on client IP, not on FQDN. :(
[ Quoting notifications@github.com in "Re: [skynetservices/skydns] TTL and..." ]
Hi miekg,
I know about this option.
But: "This statement may be used in view or a global options clause."
This work-around is not acceptable in my case, because I want 2 zones:
Damn bind... :(
Wonder if there are side effects in removing the omit-empty for this value.
Also: why are you bothered with the 1 sec TTL? Can't think if any operatial
reasons...? Also in a traffic burst it might well protect etcd.
/Miek
Miek Gieben
Actually yes, I also believed in bind :D
There might be side effects :S
I am also aware of it, but I will try.
Also: why are you bothered with the 1 sec TTL?
Well yes, great question. I want real-time service discovery.
Because fail can happen any time: sigsegv, nullptr. exception, connection lost :(
[ Quoting notifications@github.com in "Re: [skynetservices/skydns] TTL and..." ]
Actually yes, I also believed in bind :D
There might be side effects :S
I am also aware of it, but I will try.Also: why are you bothered with the 1 sec TTL?
Well yes, great question. I want real-time service discovery.
real-time and DNS don't really go well together.
Because fail can happen any time: sigsegv, nullptr. exception, connection lost :(
Which does not prevent from any client holding on to this IP.
I consider this a micro optimization that is probably not worth the trouble.
/Miek
Miek Gieben
I got your point :(
Before bind, my applications did not used DNS cache.
getpeername() always did the resolving, regardless of TTL value (default 3600 :).
Anyway, SkyDNS should obey RFC :)
Feel free to discard my issue.
I will find the way to make it work...
Thanks!