On Mon, 14 Sep 2020, Mark Andrews wrote:
[...] All
the queries to the recursive server with this configuration not answered by
the server will leak. The configuration needs “forward only;” to be added
to prevent the leak. We see this all the time.
zone “non-existant-tld” {
type
> On 13 Sep 2020, at 06:45, Fred Morris wrote:
>
> I'm a little confused by the "sky is falling" tone of all this. I'm
> pretty sure that the browser fetish for "search and URLs in the same
> box!" is pretty high up on the root server pain scale; on any given day
> .belkin/.cisco can be one of
I'm a little confused by the "sky is falling" tone of all this. I'm
pretty sure that the browser fetish for "search and URLs in the same
box!" is pretty high up on the root server pain scale; on any given day
.belkin/.cisco can be one of the top 10 NXDOMAIN TLDs (at least as of a
couple of years
> On 11 Sep 2020, at 22:22, Rob McEwen wrote:
>
> On 9/11/2020 2:46 AM, Mark Andrews wrote:
>> validate-except (I typo’d it the second time, unfortunately expect and
>> except are both valid words).
>
> I got so far down the rabbit trail with your other points, somehow I missed
> that.
On 9/11/2020 2:46 AM, Mark Andrews wrote:
validate-except (I typo’d it the second time, unfortunately expect and except
are both valid words).
I got so far down the rabbit trail with your other points, somehow I
missed that. Thanks. This should solve my problem!
If you actually used a
validate-except (I typo’d it the second time, unfortunately expect and except
are both valid words).
https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/Bv9ARM.pdf
validate-except
This specifies a list of domain names at and beneath which DNSSEC validation
should not be performed, regardless
Mark,
You gave me the "let them eat cake" answer I anticipated. Also, this
isn't fixing a problem that my services produce - it is preventing a
problem that a potential MISTAKE from a large customer would cause - the
type of mistake that is inevitable at some point, but likely
short-lived.
> On 11 Sep 2020, at 15:04, Rob McEwen wrote:
>
> Mark,
>
> The whole usage of DNS by the anti-spam industry in our DNSBLs - is somewhat
> a hack on the DNS system from the start - I guess if you think that is wrong,
> maybe you should take that up with Paul Vixie?
And Paul will tell you
Mark,
The whole usage of DNS by the anti-spam industry in our DNSBLs - is
somewhat a hack on the DNS system from the start - I guess if you think
that is wrong, maybe you should take that up with Paul Vixie?
And the whole purpose for MANY of us DNSBLs using ".local" in the first
place - was
> On 11 Sep 2020, at 11:13, Rob McEwen wrote:
>
> Mark,
>
> Most invaluement subscribers do direct queries - to hostnames that end with
> my own valid domain names that don't have this DNSSEC issue - those are the
> ONE ones that make use of public DNS and are broadcast across the internet.
Mark,
Most invaluement subscribers do direct queries - to hostnames that end
with my own valid domain names that don't have this DNSSEC issue - those
are the ONE ones that make use of public DNS and are broadcast across
the internet.
Our usage of ".local" zones for those who are RSYNC'ing
.local is for mDNS (RFC 6762). Do not use it for other purposes as you are
hijacking the namespace.
The best solution is to NOT change the name of the zones from those that you
use publicly. That way they have the correct DNSSEC chain of trust down from
the root. If you want to use
On Thu, 2020-09-10 at 13:50 -0400, Jim Popovitch via bind-users wrote:
> On Thu, 2020-09-10 at 11:56 -0400, Rob McEwen wrote:
> > I manage an anti-spam DNSBL and I've been running into an issue in recent
> > years - that I'm FINALLY getting around to asking about. I just joined this
> > list to
On Thu, 2020-09-10 at 11:56 -0400, Rob McEwen wrote:
> I manage an anti-spam DNSBL and I've been running into an issue in recent
> years - that I'm FINALLY getting around to asking about. I just joined this
> list to ask this question. Also, I checked the archives, but couldn't find an
> answer
14 matches
Mail list logo
