On Mon, Aug 15, 2016 at 11:23 PM, blrmaani wrote:
> From tcpdump, it appears that customers are receiving delayed response and
> are too sensitive for timeouts.
>
> The queries they are sending are authoritative i.e the zone is on our
> nameserver.
>
> How do I trouble-shoot this issue? This is
Blr,
We do run RRL on some of our servers, example option clause below that
activates the feature. Two suggestions:
1. You mention you 'inherited' the server and looked at /etc/named.conf --
verify that it is not running chroot to another directory and using another
config file (I kn
The nameservers are broken. They send back rcode 17 (which is yet
to be assigned) when they see a query with a EDNS option present
rather than ignore the option as required by RFC 6891. They also
send back RCODE 17 rather than BADVERS (16) when send a EDNS(1)
query. The servers also don't answ
On Tue, Aug 16, 2016 at 11:04:14AM +0200, Eivind Olsen wrote:
> Hello.
>
> I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
> getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
> RHEL/CentOS/Fedora.
>
> I can do manual lookups of the domain with "dig"
Hello.
I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
RHEL/CentOS/Fedora.
I can do manual lookups of the domain with "dig" and point it to their
servers (dns0.getsurfed.com, dns1.getsurfed.com)
Thanks for a workaround. But in this case - after "dnssec-settime -L ttl" I
need unsign/sign zone (p.1 of steps above) in order to new TTL value
appeared in DNSKEY RRset ("service bind9 reload" or "rndc loadkeys" has no
effect). But I would like to find a solution without the need of
unsigning/sign
6 matches
Mail list logo