Re: [DNSOP] [dns-privacy] RFC9103 -- extended key usage

Am 03.12.22 um 01:22 schrieb Daniel Migault: adding dns-privacy to the thread. Yours, Daniel On Fri, Dec 2, 2022 at 4:35 PM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: https://www.ietf.org/rfc/rfc9103.html#name-mutual-tls

[DNSOP] Re: [DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis

Paul Hoffman: Tim jumped the gun by about an hour: we just submitted the -05. It incorporates the suggested text from below; you can see the diff at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 this changed text is much more clear to me. Andreas ___

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-7706bis

Am 31.10.19 um 16:48 schrieb Tim Wicinski: > This starts a Working Group Last Call for draft-ietf-dnsop-7706bis > If someone feels the document is *not* ready for publication, please speak > out with your reasons. Hello, editorial note: Appendix B2 and B4 are mostly the same. Andreas __

Re: [DNSOP] nsec3-parameters opinions gathered

Am 05.11.21 um 20:19 schrieb Olafur Gudmundsson: > The document should strongly discourage any use of NSEC3 Hello, sorry for maybe asking an already answered question, but why is NSEC3 considered to have no benefit at all? I'm still on "NSEC allow zone-walks while NSEC3 don't" At least not

Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

Am 15.06.22 um 18:28 schrieb Eugène Adell: https://datatracker.ietf.org/doc/draft-adell-client-roaming/ (to me) it looks you like a solution for a problem solved specifically for email. It's known as SPF / RFC 7208 there ... Andreas ___ DNSOP mai

Re: [DNSOP] fragile dnssec, was Fwd: New Version

Petr Špaček: http://iepg.org/2017-07-16-ietf99/Fully%20automatic%20DNSSEC%20-%20final.pdf Feel free to play with it, we very much welcome feedback! Please direct further questions to Jaromír Talíř . update: I followed the instructions. One day after publishing a CDNSKEY I received one ema

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

tjw ietf: The draft is available here: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ the draft uses Vnew Vold Vleg and nonV without description. that makes it hard for me as I still do not fully understand the idea ... Andreas

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Paul Vixie: no resolver should be sending single-label names in DNS requests, period. ... if RD-bit is set. single-label queries to root-servers are the valid exception? today I checked our data for queries to localhost. As expected they do happen but very rare. So I wouldn't expect colla

Re: [DNSOP] A conversational description of sentinel.

Paul Hoffman: My preference is #1 because, in general, a label starting with _ has been meant for infrastructure, and that's what these labels are. Others might like #2 so they don't have to add configuration to BIND (and maybe other authoritative servers). just checked, my NSD and POWER

Re: [DNSOP] A conversational description of sentinel.

Paul Hoffman: I think Tony's idea is likely fine, but I also think kskroll-sentinel-is-ta- is perfectly fine as well. Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific. I also prefer that longer variant. Andreas ___ DNSOP m

[DNSOP] howto "internal"

Hello, some times ago there was an proposal (?) from Warren Kumari to define a zone "internal." for internal use. We consider a major DNS redesign of a large enterprise network. Part of the network is private (RFC1918 address space in use) some other parts are public. The whole network is curre

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

Am 24.07.2018 um 18:32 schrieb Tim Wicinski: > This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis Hello WG, I do support QNAME minimisation. As some may know, we operate a medium size enterprise and ISP network. There we use UNBOUND as recursive resolver. QNAME minimisation is en

[DNSOP] RFC7720 and AXFR

Hello, RFC 2870 (Root Name Server Operational Requirements) say 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. The update, RFC 7720 (DNS Root Name Service Protocol and Deployment Requirements) don't even m

Re: [DNSOP] RFC7720 and AXFR

Am 28.10.18 um 18:14 schrieb Paul Vixie: > there is no need to make production AXFR queries for the root zone from > "real" root servers any more. I agree to separate production and AXFR services. A formal statement of ICANN *which is not limited to l.root-servers.net.* would make things much

Re: [DNSOP] RFC7720 and AXFR

Am 29.10.18 um 14:49 schrieb Petr Špaček: > Well, AXFR is not strictly necessary. > > E.g. implementation of RFC 7706-like feature in Knot Resolver pulls zone > file from a HTTPS URL so it can reuse any CDN you like (or not). Well, good point! unbound behave similar. So it would be simply som

Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt

Am 01.11.18 um 00:03 schrieb Wessels, Duane: > I think you might be the first person to argue for supporting multiple ZONEMD > algorithms per zone. I actually expected more. I remember Stephen Farrell saying something like "while designing new protocols, algorithm agility is an important poin

Re: [DNSOP] Related Domains By DNS (RDBD) Draft

Am 25.02.19 um 21:38 schrieb Brotman, Alexander: > https://datatracker.ietf.org/doc/draft-brotman-rdbd/ Hello @all, I read the draft. Interesting idea ... page 3: s/namess/names/ page 3: "sample TXT record for the parent domain..." why should the record contain a "s=2018a". Isn't the selecto

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

Am 10.03.19 um 15:31 schrieb Tim Wicinski: > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. Hello, The document itself is written clearly. As a user of the mentioned LDNS implementation I find it useful

[DNSOP] simple question

Hello, consider a nameserver ns.example.com serving example.com. There is a delegation from com. including glue. Now we add a childzone sub.example.com. served by the same nameserver ns.example.com. should I add a entry in example.com to delegate the subzone to myself? Thanks for opinions! An

Re: [DNSOP] simple question

Am 13.11.2015 um 18:50 schrieb Joe Abley: As you say, best to install the delegation set in the parent zone even if the choice of nameservers for the parent and child means it will be obscured. thanks for the advise Andreas ___ DNSOP mailing list

[DNSOP] drop udp to stop DDOS?

Hello, a nsd user posted an interesting question: https://open.nlnetlabs.nl/pipermail/nsd-users/2016-September/002364.html Could we eliminate the DDoS threat by just turning off UDP? Recursive servers I understand probably have to keep accepting them, but authoritative servers are only inten

[DNSOP] search for reference

Hello, I'm searching for a reference (IANA?) that define the DNSSEC hash algorithm hmac-sha256 has assigned the number 159 ( see http://git.nlnetlabs.nl/ldns/tree/ldns/keys.h#86 ) I only found https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml defining the /na

Re: [DNSOP] search for reference

Mukund Sivaraman: TSIG uses DNS names for encoding the algorithm type. I didn't expected that... Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Re: The DNSOP WG has placed draft-momoka-dnsop-3901bis in state "Call For Adoption By WG Issued"

Am 24.01.25 um 21:45 schrieb IETF Secretariat: https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/ Hello, I support adoption. 4.1: Avoiding Fragmentation: you mean "Avoiding IP fragmentation"? clearance is important, as the draft is also about "Namespace Fragmentation" some wo