resolver, when the resolver got the
delegation to the temporary name server it failed with
'non-improving referral'.
How can I resolve this so the delegation will work for a BIND
resolver having default config (or with any other resolver for
that matter)? I know that I can simp
emporary name server ('ns-temp.example.com'). However, when I tried to test this set-up with a BIND resolver, when the resolver got the delegation to the temporary name server it failed with 'non-improving referral'. How can I resolve this so the delegation will work for a BIND resol
en the resolver got the delegation to the temporary name
> server it failed with 'non-improving referral'.
> How can I resolve this so the delegation will work for a BIND resolver
> having default config (or with any other resolver for that matter)? I know
> that I can simply update
lver got the delegation to the temporary name
> server it failed with 'non-improving referral'.
> How can I resolve this so the delegation will work for a BIND resolver having
> default config (or with any other resolver for that matter)? I know that I
> can simply update de
ew temporary name server ('
ns-temp.example.com'). However, when I tried to test this set-up with a
BIND resolver, when the resolver got the delegation to the temporary name
server it failed with 'non-improving referral'.
How can I resolve this so the delegation will work for a BIND
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
> 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
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 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'
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 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
> le
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 levels of the DNS
hierarchy for
Thought I would document this in case anyone else gets bit by it
I have several nameservers and other servers on a Comcast copper
connection (cable internet) in the office using a Technicolor Business
Router CGA4131COM modem. This is Comcast's de-facto standard modem as
of 2022 for business
On Thu, Jul 8, 2021 at 1:38 AM Mark Andrews wrote:
> AA is NOT set so it is not a valid answer to the question.
Ahh that was the part that I overlooked.
--
tale
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
fro
e
>> delegation point do
>> not match those at the zone apex.
>
> I'm curious if this is a re-purposing of the existing "non-improving
> referral" message. I totally get how that brief phrase makes sense
> for a sideways referral, but I'm not seeing how t
On Mon, Jul 5, 2021 at 8:20 PM Mark Andrews wrote:
> This is an error with the delegation of ok.contact. The NS records at the
> delegation point do
> not match those at the zone apex.
I'm curious if this is a re-purposing of the existing "non-improving
referral" mes
On 2021 Jul 05, at 18:20, Mark Andrews wrote:
> On 6 Jul 2021, at 06:40, @lbutlr wrote:
>> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for
>> 127.0.0.1#16749: non-improving referra
>
> This is an error with the delegation of ok.contact. The NS records at the
> delegation poin
> On 6 Jul 2021, at 06:40, @lbutlr wrote:
>
> I've been getting a few errors along these lines (bind 9.16.18), the IPs
> changes, but I don't know what "non0improving referral" means or if I should
> be concerned.
>
> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for
> 127.
I've been getting a few errors along these lines (bind 9.16.18), the IPs
changes, but I don't know what "non0improving referral" means or if I should be
concerned.
DNS format error from 64.70.78.82#53 resolving ok.contact/NS for
127.0.0.1#16749: non-improving referra
This IP is owned bv Cent
only thing that doesn't match is the TTL, 7200 on the delegation,
> 300 on the authoritative side.
>
The problem was a forward zone in our caching-only-set-up:
zone "example.com" {
type forward;
forwarders { 1.5.3.4; 1.5.2.2; };
};
The idea was to always
Hi Mark,
Op 28/10/2010 om 13:38:13 +1100, schreef Mark Andrews:
> In message <20101026161348.gj2...@omroep.nl>, Leo Baltus writes:
> > We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2.
> >
> > We have our authoritative servers migrated to bind-9.7.2-P2 and it all
> > seems
In message <20101026161348.gj2...@omroep.nl>, Leo Baltus writes:
> Hi,
>
> We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2.
>
> We have our authoritative servers migrated to bind-9.7.2-P2 and it all
> seems to work fine.
>
> While testing our caching resolvers with bind
P2 however, we
> noticed some errors in our logfiles we have never seen before.
>
> Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53
> resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637:
> non-improving referral
> Oct 26 09:52:03 myhost name
before.
Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 resolving
1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving referral
Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolving
1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203
25 matches
Mail list logo
