Am 21.04.20 um 21:30 schrieb Ondřej Surý:
> There was a setting in Cisco which would handle the host behind
> the NAT differently when the DNS traffic passed the matching NAT.
>
> I found a bug in the Cisco devices more than 10+ years ago when
> it would mangle the TTL to `0`. I don’t really re
The ultimate fix for this is to move to IPv6 so every device is universally
addressable. NAT is a stop gap measure that is well past its use by date.
> On 22 Apr 2020, at 09:03, Mark Andrews wrote:
>
> https://www.networkstraining.com/dns-doctoring-cisco-asa/
>
>> On 18 Apr 2020, at 06:26, Jo
https://www.networkstraining.com/dns-doctoring-cisco-asa/
> On 18 Apr 2020, at 06:26, John Wiles wrote:
>
> Hello all,
>
> I am running into a problem that I think is caused by either a
> misconfiguration in Bind9, our Cisco NAT, or perhaps both.
>
> The scenario:
>
> We host our own site
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-04-21 at 14:08 -0400, John Wiles wrote:
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
tcpdump is your friend.
Dump the outgoing packets from your home connection to see exactly what
you are sending for:
dig 3.32.1
There was a setting in Cisco which would handle the host behind
the NAT differently when the DNS traffic passed the matching NAT.
I found a bug in the Cisco devices more than 10+ years ago when
it would mangle the TTL to `0`. I don’t really remember the details
though, but it’s not only the `ip i
The only ip inspect lines that I could find in the current config are:
ip inspect dns-timeout 7200
ip inspect name CCP_HIGH dns
John
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Matthew Richardson
> Sent: Tuesday, April 21, 2020 2:55 PM
Out of interest, what "ip inspect" settings exist in the Cisco 2911 config?
Do any of these reference "dns"? If so, this may be your problem...
Best wishes,
Matthew
--
>From: John Wiles
>To: Tony Finch
>Cc: "bind-users@lists.isc.org"
>Date: Tue, 21 Apr 2020 14:08:24 -0400
>Subject: RE:
> -Original Message-
> From: John Wiles
> Sent: Sunday, April 19, 2020 11:18 PM
> To: 'Tony Finch'
> Cc: bind-users@lists.isc.org
> Subject: RE: NAT and Question Section Mismatch
>
> > >
> > > I am running into a problem that I think is caused by either a
> > > misconfiguration in Bind9,
Ondej,
Built on FreeBSD 12.1-STABLE, so far so good :
[xavier@numenor bind9]$ ./configure --prefix
/home/xavier/Development/bind9/build/
===
Configuration summary:
-
Petr Bena wrote:
>
> So when someone changes zone on A via nsupdate, NOTIFY and subsequent IXFR
> goes like this: A -> B -> C instead of:
>
> A -> B
> -> C
Chaining NOTIFY like A -> B -> C is very common - I would guess most TLDs
do it. In many cases, A is a secure hidden primary, B are zone tr
On 21/04/2020 17:05, Petr Bena wrote:
Hi Petr,
> So when someone changes zone on A via nsupdate, NOTIFY and subsequent
> IXFR goes like this: A -> B -> C instead of:
This is just fine. There are many DNs setups organised like this. Your
configuration isn't unique or strange.
> What confuses me
Hello,
In our massive corporate setup with hundreds BIND servers all around
planet, we have some "funny" configurations (please don't ask why :)),
that seem to be actually working just fine, but I would like to
understand if this is actually supported setup, or they just work by
accident or d
Hey all,
the work to upgrade BIND 9 to use automake and more declarative syntax has been
completed to a state where the majority of the work was merged to the
development
branch and it will be included in the next major release (e.g. BIND 9.18).
However
because this is a big change, I would like
13 matches
Mail list logo
