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

[A. Schulze]

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 words later:
  Therefore, IP
  fragmentation should be avoided by following guidance on maximum
  DNS payload sizes [I-D.ietf-dnsop-avoid-fragmentation] and
  providing TCP fall-back options [RFC7766].

this centence is covered by the initial
   Specifically, this means that the
   following minimal requirements SHOULD be implemented for a zone:

but is RFC7766 say "MUST" for TCP. The wording may be more precise on this.

Andreas

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

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

[A. Schulze]

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

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

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

[A. Schulze]

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 
 tells me how I could
use mutual TLS to authenticate (and I think, authorize) a zone transfer.

What it does not tell me is whether there should be any Extended Key Usage
bits set on the certificates.  Are the WebServer/WebClient required? 
forbidden? tolerated?


Hello,

the e-mail eco-system is fine with the current values.

$ openssl x509 -noout -ext extendedKeyUsage -in /path/to/mailservers/cert.pem
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication

So I see no reason to add something like "DNSServer/DNSClient" as Extended Key 
Usage

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] nsec3-parameters opinions gathered

[A. Schulze]

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 without additional effort.

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 to be able to 
verify a zone file as it is :-)

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 selector name already 
defined by the label itself?

6.2. a.com->b.com->c.com->a.com
isn't it better using the example domain? "a.example -> b.example -> c.example 
-> a.example"

is there a reason that loops only *SHOULD* end after 3 lookups?
SPF for example has a *hard* limit of 10 lookups 
(https://tools.ietf.org/html/rfc7208#section-4.6.4)

Page 6 / example:
"The published record would be: ..."
I'm missing the label *where* this record would be published.

Just an idea: is this something we could work on during the IETF 104 hackathon?

Andeas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 point"
We see the results today in DKIM and DNSSEC. It's really hard to change crypto 
primitives.

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC7720 and AXFR

[A. Schulze]

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 some homework for ICANN to provide the zones in a stable 
manner.
I don't know if that's maybe already the case for lax.xfr.dns.icann.org and 
iad.xfr.dns.icann.org.

Out job is provide example configurations for knot resolver and unbound
and probably other resolver...

On the long term this could motivate more admins to apply RFC7706
(Decreasing Access Time to Root Servers by Running One on Loopback)

Anyone from ICANN to take that job?

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC7720 and AXFR

[A. Schulze]

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 more clear.

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] RFC7720 and AXFR

[A. Schulze]

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 mention AXFR at all.
All I found is https://tools.ietf.org/html/rfc7720#section-2

o MUST implement core DNS [RFC1035] and clarifications to the DNS 
[RFC2181].

Is AXFR a strict requirement for root-servers today?

Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 enabled in 
relaxed mode.
We do this since more then two years (unbound 1.5.7 or so)
It's working as expected without major problems or issues.

Prior activation of that feature we designed a backup strategy for domains that 
will trigger failures.
We could "reroute" queries for problematic domains to an other resolver 
configured more relax.
This happen by manual interaction if QNAME minimisation is identified as root 
cause for a specific resolving issue.

For some months that list of "broken domain" is empty.
I see optimizations in unbound as reason for not having any trouble with QNAME 
minimisation,

Hope, that helps...
Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] howto "internal"

[A. Schulze]

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 currently organized as 
subdomains of example.com. 

One problem is the inability of users to distinguish the public/private state 
of different subdomains.
sub1.example.com is public, sub2.example.com isn't :-/

For that I like the proposal to use "internal." But that's far away from being 
a standard.
So I like to ask about alternatives...

Thanks for suggestions
Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[A. Schulze]

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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[A. Schulze]

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 POWERDNS serve A record for _foo.examle.  
without noise...

so: #1

Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 collateral damage if our resolver answer NXDOMAIN  
some day.


Every stub resolver should be smart enough to avoid unneeded network  
traffic + latency.


I support the draft.

Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[A. Schulze]

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 email.

A week later my system detected .cz publish a DS record.

thanks .cz!
Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] search for reference

[A. Schulze]

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] search for reference

[A. Schulze]

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 /name/ but no /number/

Thanks,
Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] drop udp to stop DDOS?

[A. Schulze]

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 intended for recursive servers to  
query, so would it be safe to just drop port 53 UDP requests?


are there any experiences/opinions on that?
Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] simple question

[A. Schulze]

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@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] simple question

[A. Schulze]

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!
Andreas

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop