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 delegation at the
parent zone
.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 resolver having default config (or with any ot
e 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 delegation at the parent zone to point directly to
orary 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 delegation at the parent zone to point direct
-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 resolver
having default config (or with any other
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
> 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 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 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
> 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
>
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
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
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
s 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" message. I totally get how that brief phrase makes sense
> for a sideways referral, but I'm not seeing how that statem
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" message.
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
> 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
>
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
network outages, so not be dependant on the accessibility of root
nameservers. It seems later subdomains were added for blocklists.
I have removed this zone from this caching-only server, fixing the non-
improving referral issue.
Questions remains however: considering we want a strict separation
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 to work
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
our caching resolvers with bind-9.7.2-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
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-9.7.2-P2
25 matches
Mail list logo
