Petr Menšík writes:
> Our crypto team is
> responsible for preparing RHEL 9 for FIPS 140-3 certification. They said
> there is legal obligation to stop using all RSA signatures with keys
> shorter than 2048 bits.
Either they're wrong or you're misquoting them by merging "signing" and
"verifying"
Masataka Ohta writes:
> Are there anyone who still think, with reasons, DNSSEC were
> cryptographically secure or had protected TLDs more securely
> than diginotar?
Does DNSSEC make the TLD operators less trustworthy in your eyes?
Bjørn
___
DNSOP ma
Masataka Ohta writes:
> Bjorn Mork wrote:
>
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which
>> describes
>> this "secure enough" alternative to DNSSEC?
>
> As I wrote "rely on DNS cookie or something like that",
Masataka Ohta writes:
> Plain DNS with long enough message ID is secure enough.
Hello!
Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?
I must admit I'm a bit lost wrt precisely what that alternative is since
you haven't given a
Vladimír Čunát writes:
> You can still multiplex based on SNI sent by the client. HTTPS clients
> surely send it commonly. DoT clients perhaps not so often, but that's
> just an implementation detail (which I was fixing in the past few weeks
> in knot-resolver, incidentally).
My understanding
Ladislav Lhotka writes:
> Paul Wouters writes:
>
>> I am also confused by the difference between deprecated and
>> obsoleted. I guess the yang model interprets the IANA regitry, but the
>> registry has no official column designation for this. I wonder if it
>> should be given one. I also then sug
Section 4.3 claims RFC7671 reserves "_dane":
" ++--++
| RR Type| _NODE NAME | REFERENCE |
++--++
..
| TLSA | _dane| [RFC7671] |
"
I
Tony Finch writes:
> In the first round, the ANAME processor will choose a 30s TTL.
>
> In the second round, 30s later, it will get the target address records
> from the cache with a 15s TTL, so it'll choose a 15s TTL.
>
> The in the third round it'll be back to 30s.
>
> The TTL will flip-flop, a
Tony Finch writes:
> Ray Bellis wrote:
>>
>> I'd like to see examples of configurations where the local root copy
>> *isn't* on the same host.
>
> It's basically the same as the examples in RFC 7706, but you use the other
> host's address instead of 127.12.12.12. RFC 7706 even says,
>
>The ex
Well Mark did propose this many years ago:
https://mailman.nanog.org/pipermail/nanog/2013-October/061619.html
And based on that, I created a half-assed implementation using Net::DNS.
Of course I never got around to polishing it up enough to actually put
it into production. And definitely not
Is there a need to explictly modify MX and NS records, allowing them to
point to an ANAME? Or is this already covered by the mandatory A or
records for the ANAME ?
I believe this needs to be discussed in the light of the RFC2181
wording:
| The domain name used as the value of a NS resour
"John Levine" writes:
> What would be the operational advantage of accepting mail from IPv6 hosts
> too lame to set up rDNS?
The answer is pretty much the same as the answer to the question:
"What would be the operational advantage of accepting mail?"
Bjørn
__
bert hubert writes:
> On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote:
>> Just to avoid any confusion: Although I demonstrated the issue by
>> running BIND on my laptop only, the real usage scenario is resolver
>> service for a few million distinct admini
Just to avoid any confusion: Although I demonstrated the issue by
running BIND on my laptop only, the real usage scenario is resolver
service for a few million distinct administrative domains (aka
"customers"). Changing the trust anchor is not an option.
Bjørn
_
Tony Finch writes:
> Bjørn Mork wrote:
>>
>> Recently I noticed a side effect of this configuration which I consider
>> unwanted and unexpected: It changes how BIND replies to requests without
>> the RD bit set. BIND will normally answer such requests with a "best
Hello,
We are currently trying out the configuration recommended by RFC7706,
serving a copy of the root zone on a loopback. We are using BIND 9.10
and our configuration is directly copied from the example in appendix
B.1. Even down to the actual loopback address used, as we needed a
dedicated on
16 matches
Mail list logo
