On 5/6/2022 12:45 AM, Reindl Harald wrote:
in the past our CISCO ISP router with "DNS ALG" even rewrote zone
transfers and invented a zero TTL for each and every CNAME it saw
Probably doing that to retaliate for dynamic DNS providers abusing DNS
and people abusing dynamic DNS
> On 6. 5. 2022, at 12:24, Ted Mittelstaedt wrote:
>
> You got caught in the crossfire of that particular war.
Nah, it was just crappy implementation and somebody at Cisco not understanding
the RFC. I remember that - at my previous job we had a ticket opened with them
about this particular
> On 6. 5. 2022, at 8:19, Bjørn Mork wrote:
>
> How about configuring forwarder(s) if you have to operate a resolver in
> such an environment? Hoping that the answer from the intercepting
> server isn't too different from what you'd expect from a forwarder.
I would personally go with VPN as a
Mark Andrews writes:
> It’s a long known issue with so called “Transparent” DNS
> proxies/accelerators/firewalls. Iterative resolvers expect to talk to
> authoritative servers. They ask questions differently to the way they
> do when they talk to a recursive server. Answers from different
>
On 5/5/2022 11:19 PM, Bjørn Mork wrote:
Mark Andrews writes:
How about configuring forwarder(s) if you have to operate a resolver in
such an environment? Hoping that the answer from the intercepting
server isn't too different from what you'd expect from a forwarder.
In my environment,
Am 06.05.22 um 08:19 schrieb Bjørn Mork:
Mark Andrews writes:
It’s a long known issue with so called “Transparent” DNS
proxies/accelerators/firewalls. Iterative resolvers expect to talk to
authoritative servers. They ask questions differently to the way they
do when they talk to a
Am 06.05.22 um 12:24 schrieb Ted Mittelstaedt:
On 5/6/2022 12:45 AM, Reindl Harald wrote:
in the past our CISCO ISP router with "DNS ALG" even rewrote zone
transfers and invented a zero TTL for each and every CNAME it saw
Probably doing that to retaliate for dynamic DNS providers
Hi all,
I have the following problem: I run a caching dns server using bind9
v9.10.3 in a gateway device which it serves several internal LAN IP
addresses (clients). I am doing some traffic accounting in the gateway
device using Linux conntrack so as to calculate the generated client
traffic
Hi Nick,
Thanks for bringing this to our attention. Yes, this is a copy paste
error. I think it can be removed, although we could change it because
you should make sure the address matches with what the parental agent
expects.
Best regards,
Matthijs
On 01-05-2022 07:18, Nick Tait via
Hi folks,
Thank you for the reply.
I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as suggested and
it seems that the order fixed the issue.Now my Bind9 clients are getting ip
192.168.0.10 favorably.
Anyway, I'd like to eliminate ip 172.17.0.1 from name resolutions.I never added
On 7/05/2022 1:38 am, Maurà cio Penteado via bind-users wrote:
I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as
suggested and it seems that the order fixed the issue.
Now my Bind9 clients are getting ip 192.168.0.10 favorably.
Hi Mauricio.
I don't think anyone suggested that
I just message you and the problem happened again ...
C:\Users\Mauricioλ ping ns1.example.lan
Pinging ns1.example.lan [172.17.0.1] with 32 bytes of data:Reply from
84.116.236.63: Destination net unreachable.Reply from 84.116.236.63:
Destination net unreachable.Reply from 84.116.236.63:
12 matches
Mail list logo
