First thing. Ensure that the nameservers are properly ntp synced.
This should get rid of mosr timing issues.
Secondly, for the failing zone run tcpdump on both ends and compare
the TCP payload of the packets. They should be byte for byte
identical. If they differ then the NAT box is fiddling w
On 08/18/2010 02:42 PM, Ulrich David wrote:
> Hi,
>
> I'm using Bind as a cache (absolutely not authoritative) DNS for a public
> network. I have put a firewall in order to refuse incoming packets from
> people not on my network.
>
> Today, inspecting logs, I see this :
>
> Aug 18 17:31:44 cn
On Wednesday 18 August 2010 17:42, Ulrich David wrote:
> Hi,
>
> I'm using Bind as a cache (absolutely not authoritative) DNS for a public
> network. I have put a firewall in order to refuse incoming packets from
> people not on my network.
>
> This traffic came from other DNS server in the world.
On 08/18/2010 06:55 PM, Dave Sparro wrote:
On 8/18/2010 1:12 PM, Casey Deccio wrote:
On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote:
On 8/18/2010 8:30 AM, Phil Mayers wrote:
...since the "ncbi" zone is an unsigned child zone, there needs to be an
NSEC/NSEC3 record to prove the absence o
Hi Jason and Robert,
Sorry for my lack of details.
My firewall has stateful inspection enabled for all port :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
I permit all outgoing packet. The opened incoming ports are 22 tcp (for all
IP), 53 tcp and udp (filtered for my clients
Hi,
I have some more information. I do a tcpdump of incoming packets of the sources
of request on udp 53 from external IPs :
08:29:32.482475 IP 195.176.219.26.62511 > MY.CACHE.DNS.domain: 12614+ PTR?
167.72.97.76.IN-ADDR.ARPA. (43)
08:29:34.333751 IP 195.176.219.26.25840 > MY.CACHE.DNS.domain:
On Aug 16, 2010, at 11:55 , Yohann Lepage wrote:
> 2010/8/16 Shiva Raman
>> Which is the best method to measure dns latency ? Is there any scripts /
>> programs
>> available to measure the dns latency directly?
I would like to remind people of the most obvious one: dig
sh-4.1$ dig localhost
All,
It seems this zone is broken as of a couple of days ago. Is anyone else
seeing it? Is there an appropriate bind workaround?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
It comes right up in Firefox but prompts for a username and password.
Dig shows:
dig www.ncbi.nlm.nih.gov
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> www.ncbi.nlm.nih.gov
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22983
;; flags: qr rd r
On 18/08/10 13:30, Phil Mayers wrote:
On 18/08/10 13:15, Lightner, Jeff wrote:
It comes right up in Firefox but prompts for a username and password.
Do you have DNSSEC validation enabled? Because as per my email, it's a
DNSSEC problem.
Damn - in fact sorry, scratch that. I realise my origina
On 18/08/10 13:15, Lightner, Jeff wrote:
It comes right up in Firefox but prompts for a username and password.
Do you have DNSSEC validation enabled? Because as per my email, it's a
DNSSEC problem.
After a bit of investigation, it seems that the problem is a missing
NSEC/NSEC3 record in the
On 18.08.2010 14:31, Phil Mayers wrote:
> After a bit of investigation, it seems that the problem is a missing
> NSEC/NSEC3 record in the empty reply for:
>
> $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds
>
> ...since the "ncbi" zone is an unsigned child zone, there needs to be an
> NSEC/NSEC3
No problem. We haven't enabled DNSSEC here yet. Man for dig says:
"+[no]cdflag
Set [do not set] the CD (checking disabled) bit in the query.
This requests the server to not perform DNSSEC validation of responses."
Below are the digs with the +cdflag and +nocdflag:
dig +cdflag www
On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers wrote:
>
> After a bit of investigation, it seems that the problem is a missing
> NSEC/NSEC3 record in the empty reply for:
>
> $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds
>
> ...since the "ncbi" zone is an unsigned child zone, there needs to be an
On Wed, Aug 18, 2010, at 00:42:40AM GMT+02:00, Hauke Lampe wrote:
What TSIG algorithms do you use and how long are the keys?
HMAC-MD5, 128 bit. The keys are 24 chars long. I'll try to test with
another algorithm, however I find it quite strange; if it works for
some zones, why doesn't it wo
deny-answer-addresses { %source%; };
deny-answer-aliases { %source%; };
Maybe?
- Kevin
On 8/17/2010 12:22 AM, Bradley Falzon wrote:
bind-users,
In light of Craig Heffner's rece
On 8/18/2010 8:30 AM, Phil Mayers wrote:
On 18/08/10 13:15, Lightner, Jeff wrote:
It comes right up in Firefox but prompts for a username and password.
Do you have DNSSEC validation enabled? Because as per my email, it's a
DNSSEC problem.
After a bit of investigation, it seems that the proble
On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote:
> On 8/18/2010 8:30 AM, Phil Mayers wrote:
>>
>> ...since the "ncbi" zone is an unsigned child zone, there needs to be an
>> NSEC/NSEC3 record to prove the absence of the DS record, and have a
>> secure delegation to an unsigned child zone.
>
>
>
On 8/18/2010 1:12 PM, Casey Deccio wrote:
On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote:
On 8/18/2010 8:30 AM, Phil Mayers wrote:
...since the "ncbi" zone is an unsigned child zone, there needs to be an
NSEC/NSEC3 record to prove the absence of the DS record, and have a
secure delegation
On Wed, Aug 18, 2010 at 10:55 AM, Dave Sparro wrote:
> It seems to me that the OP wanted a work-around to the fact that his end
> users couldn't use the website due to a validation failure.
> It still seems to me that working around that situation misses the point of
> using DNSSEC.
>
I read your
Hi,
I'm using Bind as a cache (absolutely not authoritative) DNS for a public
network. I have put a firewall in order to refuse incoming packets from people
not on my network.
Today, inspecting logs, I see this :
Aug 18 17:31:44 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
DST=M
Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV I
experience the following issue. When I attempt to resolve
www.jobcorps.govI get a SERVFAIL message. The authoritative servers
return an RRSIG
covering the A RR, but the resolver is unable to validate it because it
cannot
On Wed, 18 Aug 2010, Casey Deccio wrote:
Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV I
experience the following issue. When I
attempt to resolve www.jobcorps.gov I get a SERVFAIL message. The
authoritative servers return an RRSIG covering the
A RR, but the reso
On Wed, Aug 18, 2010 at 4:33 PM, Paul Wouters wrote:
> On Wed, 18 Aug 2010, Casey Deccio wrote:
>
> Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV
>> I experience the following issue. When I
>> attempt to resolve www.jobcorps.gov I get a SERVFAIL message. The
>> aut
I am looking at the deny-answer-* section for this, but we just need
to ensure we minimally affect legitimate applications. This is why I
was proposing we only action when the source is apart of the answer AS
WELL as another answer. Blocking based on just the source would affect
dyn-dns type applic
25 matches
Mail list logo
