On 13/11/13 22:21, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-11-13 at 16:49 -0500, Barry Margolin wrote:
It means that users will have to wait for an arbitrary
number of timeouts before the browser can give them an error message.
Well, the browser *could*
Found the problem.
According to the strace log, named was sending logging to syslog. This
couldn't be delivered somehow (have not investigated why). When I changed
the default logging channel to a local file, named started working properly
again. Diff:
Hi Everyone,
I recently had a recursive server running BIND 9.9.4 on FreeBSD 9.2 appear to
wedge and stop responding to clients. I had a flurry of these errors on the
console:
sonewconn: pcb 0xfe007211d930: Listen queue overflow: 16 already in queue
awaiting acceptance
I couldn't trace th
A user here was confused by the fact that
dig -t DS cam.ac.uk @authdns0.csx.cam.ac.uk
gives an (authoritative!) "nodata" response. (Well actually he was using
"host" rather than "dig", but the principle is the same.)
The server is authoritative-only and gives REFUSED when queried about
other z
Hi!
Are there size limits for zones of IPv6 reverse DNS ?
For example, is this a valid zone?
5.a.8.3.4.f.3.0.c.a.d.f.ip6.arpa
Thank you in advance!
--
Thiago Henrique
www.adminlinux.com.br
___
Please visit https://lists.isc.org/mailman/listinfo/bi
Hi,
Does anyone have any DNSSEC problem with uscg.mil.
On our DNS servers, we have seen broken trust chain error and the validation
failed.
14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) resolving
'uscg.mil/A/IN': 199.211.218.6#53
14-Nov-2013 12:57:37.573 lame-servers: error
-Original Message-
From: Listas
Date: Thursday, November 14, 2013 12:57 PM
To: "bind-users@lists.isc.org"
Subject: Size boundaries for zones of IPv6 rDNS
>Hi!
>
>Are there size limits for zones of IPv6 reverse DNS ?
>
>For example, is this a valid zone?
>
>5.a.8.3.4.f.3.0.c.a.d.f.ip6.arp
Not at this moment :
$ dig @8.8.8.8 mx uscg.mil. +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 mx uscg.mil. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42506
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0
And the name server 199.211.218.6 does not seem lame either :
$ dig @199.211.218.6 mx uscg.mil. +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @199.211.218.6 mx uscg.mil. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61958
;;
Hi Marc,
Yes, on my DNS server, if I do a dig @8.8.8.8, I got answer (with AD bit set).
I also do a dig @pac1.nipr.mil, I got answer (with AA bit set).
However, when I do dig @localhost, that is where I don't get any result at all.
All the DNSSEC tools out there, like dnsviz.net, dnsstuff.com,
Hello,
dnsstuff.com gives me all green for DNSSEC of uscg.mil.
dnsviz.net gives warnings (not : errors) on all RRSIG's - something with
TTL values.
What is odd - but should not be fatal - is that uscg.mil authoritative name
servers send replies with "strange" TTL values.
1) uscg.mil.
On Thu, Nov 14, 2013 at 11:19 AM, Marc Lampo wrote:
> Hello,
>
> dnsstuff.com gives me all green for DNSSEC of uscg.mil.
> dnsviz.net gives warnings (not : errors) on all RRSIG's - something with
> TTL values.
>
> What is odd - but should not be fatal - is that uscg.mil authoritative
> name server
In message , vinny_abe...@dell.com writes:
> Hi Everyone,
>
> I recently had a recursive server running BIND 9.9.4 on FreeBSD 9.2
> appear to wedge and stop responding to clients. I had a flurry of these
> errors on the console:
>
> sonewconn: pcb 0xfe007211d930: Listen queue overflow: 16 alre
On 11/14/13 1:29 PM, Kevin Oberman wrote:
> Don't forget that Google will white-list domains with known (by them)
> broken DNSSEC and reply even though validation is broken, so using
> 8.8.8.8 for checking on whether validation is broken is not the best idea.
Really? Google sets the ad flag for k
In message , Chris Tho
mpson writes:
> A user here was confused by the fact that
>
> dig -t DS cam.ac.uk @authdns0.csx.cam.ac.uk
>
> gives an (authoritative!) "nodata" response. (Well actually he was using
> "host" rather than "dig", but the principle is the same.)
>
> The server is authorita
Interesting - like other respondent already observed : with or without AD
flag set ?
Anyhow, I redid the query with a validating Bind 9.8 in the office :
$ dig @127.0.0.1 mx uscg.mil. +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @127.0.0.1 mx uscg.mil. +dnssec
; (1 server found)
;; global optio
16 matches
Mail list logo