Re: [DNSOP] FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys

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

Re: [DNSOP] DNSSEC as a Best Current Practice

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

Re: [DNSOP] DNSSEC as a Best Current Practice

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",

Re: [DNSOP] DNSSEC as a Best Current Practice

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

Re: [DNSOP] extension of DoH to authoritative servers

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

Re: [DNSOP] request for adoption

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

Section 4.3 claims RFC7671 reserves "_dane": " ++--++ | RR Type| _NODE NAME | REFERENCE | ++--++ .. | TLSA | _dane| [RFC7671] | " I

Re: [DNSOP] ANAME TTL vs GCD

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,

Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

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

Re: [DNSOP] SIG(0) useful (and used?)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

"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

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

bert hubert <bert.hub...@powerdns.com> 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

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

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

[DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

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