> 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
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 recursiv
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, I'
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 providers
> 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 i
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 abusi
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 bind-u
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
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: Destina
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 (most
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 y
Hi,
We are encountering a problem that SOA records had data residue when
deleting a new-created zone with BIND 9. The operation procedures are as
below:
1. Firstly, a zone named test18.cn was added with BIND 9. The command "dig
-t SOA test18.cn" shows the corresponding SOA record was created
succ
12 matches
Mail list logo
