rocess and
that boundary is too low. But that's purely a guess. The number of DS
records in osd.mil for dmdc.osd.mil is probably the most I've personally
seen. Since I can't poke the Akamai recursive name service myself, I have
no way to dig any more.
HTH,
Scott
On Fri, Aug 9, 202
dmdc.osd.mil is ... a bit of a mess. However, sha-1 DS records remain
present and I doubt whatever Akamai's recursive service is doing is choking
on those.
I note (and confirmed with my own manual queries) that amid all the DS
records that don't point to anything, there are two SHA-256 DS records
On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote:
> We do runtime detection at startup because it's configurable, build time
> would not work properly.
>
Okay, that makes sense. However, if I understood the scenario correctly, it
seems like that configuration should then generate a runtime erro
On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček wrote:
> Hello.
>
> It smells like a packaging issue to me. Stock BIND (not an obsolete Red
> Hat-Frankenstein version) should detect this condition and threat
> domains as insecure.
>
And I think that answers the one question I had. I was curious what
The question I have is why you're posting the issue to this list and what
you expect the ISC to do? It could be submitted as a bug to the
distribution you're using. Or if you want to change the way algorithms are
treated, the dnsops list at the IETF would be an appropriate place to
start. (There ha
On Wed, Apr 29, 2020 at 5:23 AM Alessandro Vesely wrote:
> Hi all,
>
> the doc says each node has a set of resource information, which may be
> empty.
> But how do I create such a node? If I just write, say:
>
> an-emty-name.example.com.
>
I believe that's a reference to empty non-terminals
On Tue, Aug 20, 2019 at 5:46 AM Ignacio García wrote:
> El 20/08/2019 a las 9:28, Marco Davids via bind-users escribió:
> > A TXT _dmarc.domain.tld "v=DMARC1; p=reject" might also be useful.
> >
>
> Wouldn't that imply having DKIM set up for the domain?
>
>
>
Short answer is no since nothing in D
+1
On Mon, Sep 18, 2017 at 8:58 PM, Mark Andrews wrote:
> We really should make all the root and TLD servers return maximal
> EDNS answers (pad to the advertised EDNS UDP size). This would
> create a little short term pain by exposing all the broken firewalls
> which would then get fixed or the
On 2 Aug 2013 at 22:25, Mark Andrews wrote:
> In message <51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov>, "Scott Morizot"
> wri
> tes:
> > Hello all,
> >
> > I ran into an interesting situation resolving dfas.mil. It appears that
> > they have
Hello all,
I ran into an interesting situation resolving dfas.mil. It appears that
they have attempted to roll their ZSKs to algorithm 8 while leaving their
KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs
for multiple algorithms exist in the apex DNSKEY RRset, then an RRS
On 1 Nov 2011 at 20:02, Phil Mayers wrote:
> On 11/01/2011 06:34 PM, Scott Morizot wrote:
>
> > Alternatively, you can sign 'policydomain.internal' and configure its key
> > as one of the trust anchors on the validating name servers. The order of
> > validation
On 1 Nov 2011 at 18:12, vinny_abe...@dell.com wrote:
> Thanks, however I can't control the domain in question
> unfortunately. It is what it is. We have to work with it. I totally
> understand why this doesn't work and actually agree with the design,
> however I just don't have a workaround or way
On 28 Oct 2011 at 17:39, Laws, Peter C. wrote:
> OK, so simply putting the NS records in the parent zone is
> sufficient to make it a separate zone. No need to put stuff in
> named.conf unless I want to or until I actually delegate to a
> different set of nameservers.
If you put NS records deleg
13 matches
Mail list logo
