[DNSOP] Re: [TLS] Re: AD review draft-ietf-tls-svcb-ech

[Paul Vixie]

Signed isn't the same as authentic. Authentic means as the zone owner 
publishes. We must not lodge in this document a requirement that a DNS server 
not be protective. Protective means not all answers flow equally. 


p vixie 


On Oct 2, 2024 08:56, Paul Wouters  
wrote:

[drifting off topic] 


> On Oct 2, 2024, at 00:10, Paul Vixie  
> wrote: 
> 
>  
> 
> 
> i would not. much of the world now relies upon inauthentic dns responses for 
> defense against bad actors. 

that's a limitation of RPZ. Years ago I proposed to move the Answer to the 
Authority section so you can filter AND provide the data for dnssec validation. 
I even proposed to write a bis doc, but the authors/ISE left the rpz doc as a 
draft, leaving a potential bis doc in limbo. 

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

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

[DNSOP] Re: [TLS] Re: AD review draft-ietf-tls-svcb-ech

[Paul Vixie]

Deirdre Connolly wrote on 2024-09-30 10:59:
 > We could add a recommendation like "Clients using ECH SHOULD select a 
DNS resolver that they trust to preserve the confidentiality of their 
queries and return authentic answers, and communicate using an 
authenticated and confidential transport", but this draft seems like an 
odd place for that text.


I support this more than the DNSSEC recommendation


i would not. much of the world now relies upon inauthentic dns responses 
for defense against bad actors. here's how US NCCIS puts it:


https://www.cisa.gov/news-events/alerts/2021/03/04/joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through

it is precisely to prevent protective dns from being bypasses that many 
of us block all off-net DNS including off-net HTTPS to known DoH 
services. malicious insiders, intruders, malware, and poisoned supply 
chains do not want their DNS lookups to be monitored or blocked.


we can argue about where the advice should and shouldn't appear, but we 
mustn't appeal to "response authenticity" when recommending a recursive 
DNS service. response authenticity is what our attackers need.


--
P Vixie

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

[DNSOP] Re: AD review draft-ietf-tls-svcb-ech

[Paul Vixie]

>An attacker who can prevent SVCB resolution can deny clients any
>associated security benefits. A hostile recursive resolver can
>always deny service to SVCB queries, but network intermediaries can
>often prevent resolution as well, even when the client and
>recursive resolver validate DNSSEC and use a secure
>transport. These downgrade attacks can prevent a client from being
>aware that "ech" is configured which could result in the client
>sending the ClientHello in cleartext. To prevent downgrades,
>Section 3.1 of [SVCB] recommends that clients abandon the
>connection attempt when such an attack is detected.

i don't believe that this working group, or the ietf as a whole, ought to make 
a recommendation of this kind. ECH will be widely nonfunctional due to 
enterprise, family, and personal filtering. preventing an endpoint from seeing 
the ECH metadata in DNS may be a secure edge network operator's chosen method 
of avoiding errors that would otherwise affect their local end users. see 
also:

https://www.linkedin.com/feed/update/urn:li:activity:7246554223226560512/

note, i'm not asking for balance of political views to be expressed in the 
document. rather, i'm asking that no political view be expressed in the 
document, but my fallback will be to prevent a balance of political views to 
be expressed if any political view at all is expressed.

-- 
P Vixie

On Monday, September 30, 2024 3:40:44 AM PDT Eric Rescorla wrote:
> On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters  
> 40aiven...@dmarc.ietf.org> wrote:
> > Hi,
> > 
> > I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
> > summarized by the Document
> > Shepherd:
> > 
> > Please note that the text in this I-D was initially developed in the DNSOP
> > WG, went through IETF LC, and IESG review. The result of the IESG review
> > was to take the text in this I-D out of RFC 9460
> >  (was
> > draft-ietf-dnsop-svcb-http) and run the new I-D through the TLS WG. The
> > text in this I-D is essentially the same text taken from -11 of
> > draft-ietf-dnsop-svcb-http.
> > 
> > 
> > This is why I sent this review to both the TLS and DNSOP list. I have a
> > few minor issues in the draft that I think
> > 
> > need fixing:
> > These downgrade attacks can prevent a client from being aware that
> > 
> > "ech"
> > 
> > is configured which could result in the client sending the ClientHello
> > in cleartext.
> > 
> > However, when DNSSEC is used and the TLS client can see the errors at the
> > DNS layer,
> > it can detect this downgrade attack is happening, and decide whether or
> > not to continue with
> > starting a TLS connection. I think the text should explain the difference
> > in attack scenario in the
> > presence and absence of DNSSEC. It might even be worth it to RECOMMEND
> > DNSSEC, or recommend
> > a DoH / DoT / DoQ connection to a DNSSEC supported DNS service. When
> > referring to "DNSSEC", please
> > use a normative reference to RFC9364.
> 
> TBH, this whole section is kind of confusing, but I think it actually
> is noting exactly what you are suggesting:
> 
>An attacker who can prevent SVCB resolution can deny clients any
>associated security benefits. A hostile recursive resolver can
>always deny service to SVCB queries, but network intermediaries can
>often prevent resolution as well, even when the client and
>recursive resolver validate DNSSEC and use a secure
>transport. These downgrade attacks can prevent a client from being
>aware that "ech" is configured which could result in the client
>sending the ClientHello in cleartext. To prevent downgrades,
>Section 3.1 of [SVCB] recommends that clients abandon the
>connection attempt when such an attack is detected.
> 
> This section is kind of confusing, but I *think* what it's saying
> is that the attacker permits resolution of the A/ records
> but blocks resolution of SVCB (it's not clear to me how it does
> this in the case where you are using secure transport, is the
> idea that it's an intermediary between the recursive and the
> authoritative? If so, probably say so). As you say, this is
> observable when DNSSEC is in place, and S 3.1 of SVCB recommends
> abandoning the connection, just as you ask.
> 
>If DNS responses are cryptographically protected (e.g., using DNSSEC
>or TLS [DoT] [DoH]) and SVCB resolution fails due to an
>authentication error, SERVFAIL response, transport error, or timeout,
>the client SHOULD abandon its attempt to reach the service, even if
>the client is SVCB-optional.  Otherwise, an active attacker could
>mount a downgrade attack by denying the user access to the SvcParams.
> 
>A SERVFAIL error can occur if the domain is DNSSEC-signed, the
>recursive resolver is DNSSEC-validating, and the attacker is between
>the recursive resolver and the authoritative DNS server.  A transport

[DNSOP] Re: Approved: draft-ietf-dnsop-avoid-fragmentation

[Paul Vixie]

co-author, thank you for your brilliance, discipline and continuity.

-- 
P Vixie

On Friday, September 27, 2024 1:26:38 PM PDT Warren Kumari wrote:
> Hi there Authors, IESG, WG, and Secretariat,
> 
> draft-ietf-dnsop-avoid-fragmentation - "IP Fragmentation Avoidance in DNS
> over UDP"
>  is
> now approved.
> 
> I'd like to thank everyone, especially the authors and Benno Overeinder,
> for all of their diligent hard work to get this done.
> 
> This document was rough one, and sat in my queue for an exceptionally long
> time while we got agreement on how to address the last set of concerns.
> 
> I'd like to thank everyone again for their collegiate attitude, willingness
> to hear and consider each other's viewpoints, and patience.
> 
> Thank you,
> W




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

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Paul Vixie]

thanks for clearing this up. tls 1.3 failures are going to be pretty common, 
because in non-enterprise contexts without local certificate authorities, the 
risk imposed by ECH will be seen as too great. i guess we'll have to let the 
market sort it out.

-- 
P Vixie

On Thursday, July 25, 2024 7:24:30 AM PDT Ben Schwartz wrote:
> TLS 1.3 clients using ECH will not fall back to non-ECH upon unauthenticated
> failure, just as TLS clients of any kind will not fall back to a lower
> version upon unauthenticated failure.  To control the TLS version, or the
> usage of ECH, one must either control the client's behavior directly or be
> able to authenticate as the TLS destination to the client's satisfaction. 
> In an enterprise context, the latter is often accomplished by implanting a
> special local certificate authority into the client's trust store.




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

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Paul Vixie]

On Tuesday, July 23, 2024 1:56:50 PM PDT Ben Schwartz wrote:
> It seems like there's some confusion here.  ECH is an extension to TLS that
> is still under development (and now nearly final).  Use of ECH is optional
> in TLS 1.3.  Any entity that can control the TLS version in use also has
> the ability to disable ECH, so allowing TLS 1.3 does not require an
> administrator to permit ECH.
> 
> --Ben Schwartz

If a client who tries TLS 1.3 with ECH can be detected by an enterprise ("next 
generation") firewall using the spoofed-SYNACK trick so common for HTTPS, and 
made to fail, and would then have some reason to retry TLS 1.3 without ECH, 
rather than just giving up or moving straight to TLS 1.2, this is the first 
i'm hearing of it. is this advice-to-implementors specified somewhere? i'd 
like to see it referenced in:

https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/

...and i suggest simply referencing that advice in the draft under discussion.

-- 
P Vixie



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

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Paul Vixie]

-- 
P Vixie

On Tuesday, July 23, 2024 12:52:28 PM PDT Paul Wouters wrote:
> On Jul 23, 2024, at 12:09, Paul Vixie  
wrote:
> > Making TLS 1.2 available as a fallback is vital. Many secure private edge
> > networks will never allow TLS 1.3 because of ECH.
> 
> You can do TLS 1.3 without ECH ?

if an endpoint wants TLS 1.3 with ECH, there's no way to negotiate them down 
to TLS 1.3 without ECH. there is a way to negotiate them down to TLS 1.2.

> Making  a weaker version of TLS mandatory would be unwise, unless it’s to
> give more time for migration away from it.

migration for military, government, and many corporate networks can't happen. 
for reasons of law, regulation, or policy, they must see the client hello 
before they can decide whether to block the flow. "just secure your devices" 
can't work due to the way the supply chain works. the only alternative will be 
to block outbound entirely and force all traffic through a non-intercepting 
proxy.

ietf knew this, but RFC 8890 forbade us to consider it. i was a dissenter. the 
fact that you refer to TLS 1.2 as "weaker" may indicate a preference that we 
mandate a technology that often _cannot_ be used even those the alternative 
("effective mandate") will be a technology (explicit proxy) which is in fact 
weaker than TLS 1.2. we should not argue from talking points.

don't put it in terms of migration. just recommend that fallback be allowed. 
50 years from now, smarter people than us can think of a better way forward. 
as things are today, secure private edge networks including military, 
government, and many commercial networks, will not allow TLS 1.3 to be used.

paul


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

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Paul Vixie]

On Monday, July 22, 2024 5:11:23 PM PDT Jessica Krynitsky wrote:
> Thanks Ben and Erik for the comments!
> 
> Erik, yes I agree, I think we had TLS 1.3 in mind when writing the draft and
> when evaluating alternatives for this encrypted DNS scenario. I think we
> can make an edit to specify TLS 1.3 or at least post-handshake client
> authentication with TLS 1.2. It sounds like from both of these comments we
> need to spell out privacy considerations in more detail.
> 
> ...

Making TLS 1.2 available as a fallback is vital. Many secure private edge 
networks will never allow TLS 1.3 because of ECH. Think government, military, 
corporate. The moment we explicitly disallowed fallback, these networks would 
be forced into explicit edge proxies with private keys. I think that's an 
outcome worth avoiding.

So, +1 to the above.

-- 
P Vixie


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

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

[Paul Vixie]

see inline.

On Sunday, July 7, 2024 3:55:36 PM PDT David Farmer wrote:
> Paul,
> 
> I think this might be a little easier for people to parse, and I think it
> covers everything in yours;

that attempt is visible, but there's a fine point it loses.

> R3. UDP responders should compose response datagrams whose size does not
> exceed the requestor's offered buffer size (EDNS bufsize) or the interface
> MTU, the route MTU, or the path MTU, if any are known.

a datagram == a udp payload. it is subject to limitation by remote bufsize or 
local policy. 
the estimated or discovered MTU has to be 100 octets larger than that. so the 
above 
paragraph has a type error. so while this formulation is clearer than mine, 
it's also 
incorrect, and as you can see in my "second try" draft, i think the difference 
is important.

re:

> 
>- If the path MTU can be reliably discovered, then such discovery SHOULD
>be attempted, and the result used.
>- For IPv6, an interface MTU other than 1500 bytes should be
>advertised in a Router Advertisement [RFC4861].
>- If none of the MTUs are known, a default of 1500 bytes should be
>assumed. Further, the MTU should be reduced to account for packetization
> by the UDP and IP/IPv6 layers, which might add as many as 100 bytes,
> resulting in the RECOMMENDED 1400 Bytes.
> 
> R5. UDP requestors should set the requestor's offered buffer size (EDNS
> bufsize) to and compose request datagrams whose size does not exceed the
> minimum of the interface MTU, the route MTU, or the path MTU, if any are
> known.
> 
> 
>- If the path MTU can be reliably discovered, then such discovery SHOULD
>be attempted, and the result used.
>- For IPv6, an interface MTU other than 1500 bytes should be
>advertised in a Router Advertisement [RFC4861].
>- If none of the MTUs are known, a default of 1500 bytes should be
>assumed. Further, the MTU should be reduced to account for packetization
> by the UDP and IP/IPv6 layers, which might add as many as 100 bytes,
> resulting in the RECOMMENDED 1400 Bytes.
> 
> What do you think?
> 
> On Sun, Jul 7, 2024 at 1:19 PM Paul Vixie  wrote:
> > Looks like the second WG mailing list fell off of this thread. See below
> > for history. I realize that the text I proposed to Mr. Farmer was
> > incoherent, so here's a second try:
> > 
> > 
> > R3. UDP responders should compose response datagrams whose size does not
> > 
> > exceed either the policy maximum if specified, or the requestor's offered
> > buffer
> > 
> > size (EDNS bufsize), and will not after packetization by the UDP and
> > IP/IP6
> > 
> > layers (which might add as many as 100 octets) not exceed the predicted
> > end-
> > 
> > to-end network MTU for the path to the requester. Neither the interface
> > MTU if
> > 
> > known, or the route MTU if known, or the path MTU if known, shall be
> > exceeded.
> > 
> > If neither the route MTU or path MTU are known, a default of 1500 should
> > be
> > 
> > assumed. If interface, route, or path MTU can be reliably discovered, then
> > 
> > such discovery SHOULD be attempted. Absent such knowledge, the lower of
> > 
> > requester's offered buffer size (EDNS), or 1400, will be the maximum
> > datagram size for that response. The recommended 1400 value is simply 1500
> > (default MTU) minus 100 (room for transport and network headers) and these
> > values may be revised in the future.
> > 
> > If something like this can work, then something like it would have to also
> > be done for R5.
> > 
> > --
> > 
> > P Vixie
> > 
> > --  Forwarded Message  --
> > 
> > Subject: [v6ops] Re: [DNSOP] Re: Fwd: New Version Notification -
> > draft-ietf-dnsop-avoid-fragmentation-18.txt
> > 
> > Date: Saturday, July 6, 2024, 7:35:11 PM PDT
> > 
> > From: Paul Vixie 
> > 
> > To: v6...@ietf.org, David Farmer 
> > 
> > On Friday, July 5, 2024 12:48:18 PM PDT David Farmer wrote:
> > > Paul and Tim,
> > > 
> > > 
> > > 
> > > Would this fit the bill?
> > 
> > i don't think so, but it's a step in the right direction. we should not
> > 
> > mention PLPMTUD since it's considered controversial in the here and now,
> > and___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Fwd: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

[Paul Vixie]

Looks like the second WG mailing list fell off of this thread. See below for 
history. I realize 
that the text I proposed to Mr. Farmer was incoherent, so here's a second try:

R3. UDP responders should compose response datagrams whose size does not 
exceed either the policy maximum if specified, or the requestor's offered 
buffer 
size (EDNS bufsize), and will not after packetization by the UDP and IP/IP6 
layers (which might add as many as 100 octets) not exceed the predicted end-
to-end network MTU for the path to the requester. Neither the interface MTU if 
known, or the route MTU if known, or the path MTU if known, shall be exceeded. 
If neither the route MTU or path MTU are known, a default of 1500 should be 
assumed. If interface, route, or path MTU can be reliably discovered, then 
such discovery SHOULD be attempted. Absent such knowledge, the lower of
requester's offered buffer size (EDNS), or 1400, will be the maximum datagram 
size for 
that response. The recommended 1400 value is simply 1500 (default MTU) minus 
100 
(room for transport and network headers) and these values may be revised in the 
future.

If something like this can work, then something like it would have to also be 
done for R5.

-- 
P Vixie

--  Forwarded Message  --

Subject: [v6ops] Re: [DNSOP] Re: Fwd: New Version Notification - 
draft-ietf-dnsop-avoid-
fragmentation-18.txt
Date: Saturday, July 6, 2024, 7:35:11 PM PDT
From: Paul Vixie 
To: v6...@ietf.org, David Farmer 

On Friday, July 5, 2024 12:48:18 PM PDT David Farmer wrote:
> Paul and Tim,
> 
> Would this fit the bill?

i don't think so, but it's a step in the right direction. we should not 
mention PLPMTUD since it's considered controversial in the here and now, and 
there's no need to be provocative.

> R3. UDP responders should compose response packets that fit in the minimum
> of the offered requestor's maximum UDP payload size [RFC6891], the
> interface MTU, the network MTU value configured by the knowledge of the
> network operators, and the RECOMMENDED maximum DNS/UDP payload size of 1400
> bytes, or a different Path MTU value that is known to function without
> encountering fragmentation, as determined by PLPMTUD [RFC 8899] or some
> other future mechanism. (See Appendix A for more information.)

R3. UDP responders should compose response datagrams whose size does not 
exceed either the policy maximum if specified, or the requestor's offered 
buffer 
size (EDNS bufsize), and will not after packetization by the UDP and IP/IP6 
layers (which might add as many as 100 octets) not exceed the predicted end-
to-end network MTU for the path to the requester. Neither the interface MTU if 
known, or the route MTU if known, or the path MTU if known, shall be exceeded. 
If neither the route MTU or path MTU are known, a default of 1500 should be 
assumed. If interface, route, or path MTU can be reliably discovered, then 
such discovery SHOULD be attempted. Absent such knowledge, either the 
requester's offered buffer size, or 1400 if lower, will be the effective 
maximum 
datagram size. The 1400 value is simply 1500 (default MTU) minus 100 (room for 
transport and network headers) and these values may be revised in the future.

> R5. UDP requestors should set the requestor's maximum UDP payload size
> [RFC6891] to the RECOMMENDED maximum DNS/UDP payload size of 1400 bytes
> unless the interface MTU or the network MTU is known to be smaller or a
> different Path MTU value that is known to function without encountering
> fragmentation, as determined by PLPMTUD [RFC 8899] or some other future
> mechanism. (See Appendix A for more information.)

i'd like to see this revised similarly to my example above, if you agree.

-- 
P Vixie


___
v6ops mailing list -- v6...@ietf.org
To unsubscribe send an email to v6ops-le...@ietf.org

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

[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

[Paul Vixie]

On Thursday, July 4, 2024 6:03:44 PM PDT Tim Wicinski wrote:
> Geoff,
> 
> On Thu, Jul 4, 2024 at 8:58 PM Geoff Huston  wrote:
> > I think you appear to be getting "requestor" and "responder" confused in
> > your proposed text. Did you mean to say the following?
> 
> Arrgh - Guilty and thank you for that.
> 
> > UDP responders should compose response response packets with a maximum UDP
> > payload size that fits in the minimum
> > of the offered requestor's maximum UDP payload size, [RFC6891], the
> > interface MTU, the network MTU value configured by the knowledge of the
> > network operators,
> > and the RECOMMENDED maximum DNS/UDP payload size 1400.
> 
> You say "response response" in your text, but yes yes that was where I was
> going with it.
> 
> Paul, does this give the future proofing you were thinking of?

No, although it is strikingly similar to earlier text that was rejected. We 
should not minimize to 1400 if one of the other ingredients is larger. Also 
does not mention discovered path MTU if any. If we assume that both RFC 6891 
and RFC 8899 will be superceded at some point, we can still reference them 
since future readers should be able to figure out that what we mean is "EDNS 
bufsize or evolutionary replacement" and "PLPMTUD or evolutionary 
replacement". in pseudo-code this would appear as roughly:

MIN(interface_mtu,
policy_mtu,
edns_bufsize,
ELSE(discovered_pmtu, default_pmtu))

That is, first see if there is a discovered mtu (such as by PLPMTUD or some 
future method), and if not, assume that the path mtu is no more than 1400. 
Second, use the smaller of your own interface mtu, the policy mtu if any, the 
offered buffer size if any, or the result of step 1 (discovered pmtu if known, 
or else default mtu which is at the time of this writing known to be 1400).

It probably can't be better than that. If it could be, then I'd prefer to go 
back about a year in the edit history, so that we can distinguish between MTU 
and buffer size. A DNS responder can only affect buffer size, which includes 
the 
DNS header but not other headers. The responder's network stack will add 
headers for UDP and IP/IP6. In that world, we'd say that the default MTU was 
1500 not 1400, but that the DNS responder should always leave room for 100 
octets of transport and network headers. The equation for this would be:

let default_mtu = 1500
let header_estimate = 100
let pmtu = ELSE(discovered_pmtu, default_pmtu)
let mtu = MIN(interface_mtu, policy_mtu, pmtu)
let bufsize = MIN(mtu, edns_bufsize) - header_estimate

This was a very hard sell back in -03 of this draft, so I stopped pushing.

> thanks
> tim

I agree: thanks, Tim!

-- 
P Vixie


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

[DNSOP] Re: [v6ops] Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

[Paul Vixie]

On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
> On Tue, Jul 2, 2024 at 9:26 PM David Farmer  wrote:
> > 2. Also, maybe R5 should have text similar to R3 with "...the minimum
> > of...the interface MTU, the network MTU...and 1400 bytes..." Instead of
> > "It should use a limit of 1400 bytes, but a smaller limit MAY be used."
> 
> Something like this:
> 
> "UDP requestors should limit the requestor's maximum UDP payload size  to
> use the RECOMMENDED size of 1400 bytes, but a smaller limit MAY be used."

As before, I'd like to future-proof this document. 1400 may not survive and 
should not be a 
hard limit. If someone ever gets PLPMTUD working, or if local knowledge 
includes MTU 
over a topology as a static configuration, then the recommended value should be 
ignored, 
and the measured or locally defined limit should be the operational maximum for 
that 
datagram.

Thus, not only a smaller limit, but also a larger limit, may be sometimes used. 
This 
document need not enumerate all such cases, but should not require revision if 
1400 turns 
out to be like 640KB -- not a sensible limit for all possible futures.

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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Paul Vixie]

On Monday, July 1, 2024 2:54:55 AM PDT Davey Song wrote:
> Hi Paul,
> 
> I’m sending this email off-list to respond to your comment.

in fact you cc'd the mailing list, so i shall do likewise in my reply.

> ... However, the fact is that DNS has been widely used
> as a direction system for a long time with lots of tricks though.
> Individual tricks build walls for interoperability.

sadly, no innovator ever earned equity by adding simplicity to a system. the 
continuous result has been a series of negative externalities ("complexity 
costs") for the rest of a community or industry.

> Our friend PVM  thought
> that DNS could contain not only data but also programs in the future. What
> do you think?

noting that at the time javascript was first prototyped, there were a number of 
existing languages intended for precisely this kind of embedding which were 
not considered, any of which would have matured faster than javascript has 
done. this should inform us that any language encoded into the DNS would be 
found not-innovative-enough for some future equity-earner, and that continuous 
re-invention will be the result no matter what then exists.

however, your question shows in-clarity in what i wrote earlier. i am in fact 
advocating for putting something-like-a-program into the dns, to be consumed 
by either recursive dns servers, or stub resolvers, or apps, or all three. 
whether this is some kind of policy that describes how to learn load levels of 
content mirrors, or how to learn CDN topology, or how to learn other metrics 
-- doesn't matter to me. SPF shows a way to express policy as rules, but if 
someone insists that it be tiny Lua or TCL or Scheme fragments, i won't treat 
it as a proposal to a different need, only a proposal in a different format.

i'll have more to say in my reply to joe.

vixie


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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Paul Vixie]

somebody asked me a few months ago why "it's always dns"? meaning, why are so 
many mysteries and outages ultimately traced down to something broken in dns? 
i answered that dns as conceived worked very well, and the first round of 
changes (ixfr, update, notify, edns) helped it work well even at scale, but 
after the commercial web industry started turning dns into whatever their 
marketing departments needed it to be, it got very complex, and flaky.

hear: https://changelog.com/person/paul-vixie

joe, let's figure out how to "rigidly constrain" again. expressing fixed policy 
which can operate inside the recursive system would be a whole lot easier to 
diagnose whenever it's unreliable, but avoid the additional round trips that 
the CDN world fears so strongly. we should want that outcome, which 
corresponds to "anti-complexity".

davey, "another indirection" means both more round trips and more complexity, 
and will find few friends.

see: https://queue.acm.org/detail.cfm?id=1242499

vixie


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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Paul Vixie]

Bill Woodcock wrote on 2024-06-29 20:22:

On Jun 29, 2024, at 19:59, Paul Vixie ... wrote:

It's my hope that CDN support can be added to DNS in a way that allows all 
answers to be identical. ... we have to move away from CNAME especially at the 
apex. The great bogie man of CDN seems to be additional round trips.



Agreed.  ... Anything which entrenches DNS inside CNS because the CDN is too 
stupid to function without even-stupider DNS tricks that break, for instance, 
zone transfer, is really bad.  ...


Bill's mention of stupid dns tricks reminded me of this 2009 article:

https://queue.acm.org/detail.cfm?id=1647302

Epic fun times.

--
P Vixie

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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Paul Vixie]

It's my hope that CDN support can be added to DNS in a way that allows all 
answers to be identical. Modern clients even mobile ones are powerful enough to 
make application layer routing decisions locally. But we have to move away from 
CNAME especially at the apex. The great bogie man of CDN seems to be additional 
round trips. That's workable. 


DNS RPZ, mentioned below, is intended as a security enhancer below the 
recursive and ought not be used above the recursive. So, off topic here. But to 
be clear, ECS has shown that the CDN industry is willing to involve recursive 
servers in their path selection activities, we might expect more technology of 
that kind to result from this side meeting. 


p vixie 


On Jun 29, 2024 10:36, Jim Reid  wrote:



> On 29 Jun 2024, at 18:10, Ray Bellis  wrote: 
> 
> The DNS was never designed intended to deliver different answers to different 
> users.  DNSSEC solidified that and the practise IMNSHO should be discouraged, 
> not standardised. 

While this is undoubtedly true Ray, that ship sailed a *long* time ago*. I 
agree this shouldn’t (doesn’t?) need to be standardised. 

However if the side meeting is able a make valid case for work on the topic, it 
deserves to be heard. And if it doesn’t, the proponents can get to be heard and 
then dismissed. 

* IIUC BIND provides a few options to enable this bad idea: RPZ for instance. 

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

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

[DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

[Paul Vixie]

Mark Andrews wrote on 2024-06-26 16:02:




...


Adding a new RRTYPE requires zero infrastructure upgrades.  It’s a database 
entry at IANA.  Every DNS server on the planet should handle these 
transparently.  That was required by RFC 1034 and RFC 1035.  You can even add 
them to zones before the parsing software is updated using unknown type 
representation (RFC 3597) which was one thing that was missing from RFC 1035 
that would have made adding new types easier.  Nameservers and stub resolvers 
were always required to treat unknown records as opaque objects.


in terms of dns infrastructure this is true. while the open source 
implementations are fastest to adopt and deploy new rr types, even 
proprietary dns implementations are rarely more than a year behind.


but there's infrastructural middleware for which this is not true. 
registries and registrars and things like "webmin" are usually five to 
ten years behind on adding support for new rr types. thus, the SPF 
debacle in which the application had to back off and go with TXT. and 
thus the tendency today to use an existing rr type and a well-known 
subdomain beginning with an "_" as a way to deploy more or less immediately.


dns itself is not the problem. but there is a real problem here about 
which the dns technical community can do precisely nothing.



This doesn’t mean that there weren’t mis-implementations of the standards which 
failed to handle unknown types correctly but there have been 78 types added 
since RFC 1034 and RFC 1035.  That’s 2-3 per year.  Nameserver developers know 
how to add new record types quickly.


agreed, but that's not the point being argued.

--
P Vixie

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

[DNSOP] Re: draft-hinden-v6ops-dns

[Paul Vixie]

Paul Wouters wrote on 2024-06-19 18:31:

...

I also feel that a suggestion like "Switch UDP for TCP or QUIC" is not
really a decision that should be made by a v6ops document, but by the
DNSOP WG.

Paul


i'm pretty sure DNS-over-UDP packet size on IPv6 is likewise something a 
v6ops document should not be talking about, given we're doing so here.


--
P Vixie

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

[DNSOP] Re: draft-hinden-v6ops-dns

[Paul Vixie]

This document makes the argument that because of how things work at the 
moment, we should limit our aspirations.


I completely disagree.

re:

Florian Obser wrote on 2024-06-19 01:11:

Take note of the intended status. I thought that to be... ambitious ;)




--
P Vixie

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

[DNSOP] Re: [Editorial Errata Reported] RFC8945 (7983)

[Paul Vixie]

this is a good fix to a true error in this rfc.

RFC Errata System wrote on 2024-06-11 06:00:

The following errata report has been submitted for RFC8945,
"Secret Key Transaction Authentication for DNS (TSIG)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7983

--
Type: Editorial
Reported by: Terts Diepraam 

Section: 5.2

Original Text
-
If the TSIG RR cannot be interpreted, the server MUST regard the
message as corrupt and return a FORMERR to the server.

Corrected Text
--
If the TSIG RR cannot be interpreted, the server MUST regard the
message as corrupt and return a FORMERR to the client.

Notes
-
Server send an error to the client, not to itself.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC8945 (draft-ietf-dnsop-rfc2845bis-09)
--
Title   : Secret Key Transaction Authentication for DNS (TSIG)
Publication Date: November 2020
Author(s)   : F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. 
Gudmundsson, B. Wellington
Category: INTERNET STANDARD
Source  : Domain Name System Operations
Stream  : IETF
Verifying Party : IESG




--
P Vixie

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

Re: [DNSOP] Do we need new draft that recommends number limits ?

[Paul Vixie]

<>


+1.


p vixie

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

Re: [DNSOP] unrelated name server name recommendation

[Paul Vixie]

Paul Wouters wrote on 2024-03-04 11:14:

On Mar 4, 2024, at 14:04, Paul Vixie
 wrote:

this means a zone will always be reachable through at least one
in-zone data path (name server name and associated address
records.) the result would be that a full resolver would never have
to pause its current lookup while searching for address records
matching an out-of-zone name server name.

i think it's a solid recommendation,


It means every registrant, who doesn’t know about DNS, has to create
host objects for glue and whenever the ISP changes nameserver names
(eg gets bought, sold or merges), or IP address, the ISP has to talk
to the registrant to fix things at their registry. I can promise you
those in-domain name servers will quickly become very unreliable.


not. the rest of the paragraph you quoted six words from above was:


i think it's a solid recommendation, but can only be a SHOULD not a
MUST, both because of the installed base / long tail, and the
impossibility of enforcing it, and the market needs of parking lots.


it's not a "has to". i expect it either won't be used when a sale is 
possible, or will be removed prior to such sale. i see fujiwara's 
proposal as a way to reduce distributed system complexity for those who 
can behave this way, and strictly as a recommendation.



--
P Vixie

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

Re: [DNSOP] unrelated name server name recommendation

[Paul Vixie]

Ben Schwartz wrote on 2024-03-04 07:20:
To rephrase, it sounds like you are proposing a rule that zones should 
be configured to use at most one glueless delegation step.


i think it's the inverse. according to fujiwara-san's comments each zone 
must have at least one in-zone name server name:


>


this means a zone will always be reachable through at least one in-zone 
data path (name server name and associated address records.) the result 
would be that a full resolver would never have to pause its current 
lookup while searching for address records matching an out-of-zone name 
server name.


i think it's a solid recommendation, but can only be a SHOULD not a 
MUST, both because of the installed base / long tail, and the 
impossibility of enforcing it, and the market needs of parking lots.


--
P Vixie

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

Re: [DNSOP] BoF: New DNS Delegation, was DELEG Capabilities BoF

[Paul Vixie]

Thanks Roy. Would a new working group be open to skeptics? I remain 
concerned about gradually increasing systemic complexity, and I have 
some ideas about how some stated goals of the DELEG proposal could have 
complexity increase precisely linear to new functionality -- so, 
extending beyond but not replacing the NS RRset model.


But I would not want to crash a party.

Vixie

re:

Roy Arends wrote on 2024-02-01 03:46:

Dear DNSOP,

After the DNSOP Interim, I had a short discussion with Warren Kumari about the 
vagueness of the request. I have now updated the request to reflect the 
sentiment of the interim and to make sure that there is the opportunity to form 
a WG if there is the desire to do so.

https://datatracker.ietf.org/doc/bofreq-arends-deleg-capabilities/

Warmly,

Roy

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




--
P Vixie

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

Re: [DNSOP] Documenting DELEG design trade-offs

[Paul Vixie]

i do not foresee a time when any dns protocol agent won't need NS 
support any more, nor also UDP/53 support. so DELEG can at best add 
features for its adopters at the expense of permanent added complexity 
for the specification and for the system.


i realize that in today's client/server model ~everything is either a 
mobile device or a cloud, and that the deployment curve might not be as 
flat nor its tail as long as (for example) EDNS.


fujiwara's point that not everybody liked parent-side delegation when it 
was last debated deserves more thoughtful consideration than i've seen.


this text on page 1 of the draft is not evidence-backed:


   This limitation is a barrier for efficient introduction of new DNS
   technology.  New features come with additional overhead as they are
   constrained by the intersection of resolver and nameserver
   functionality.  New functionality could be discovered insecurely by
   trial and error, or negotiated after first connection, which is
   costly and unsafe.


the idea that DELEG will be extensible and will evolve over time does 
not foster confidence. i guess we should consider the camel. see also:


http://www.redbarn.org/files_redbarn/DNS-Experiment-2001.pdf

tim april's

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

Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)

[Paul Vixie]

thanks rob for your long service. we'll do as you suggest.

Rob Wilton (rwilton) wrote on 2024-01-29 02:48:

Hi Authors,

Just a note/reminder that I am stepping down as an AD in March.  I don’t 
think that I’ve seen any reply to my DISCUSS comments (perhaps the 
authors and/or WG are still discussing the resolution), but if you are 
able to speed this up at all so that I can clear my discuss before I 
step down that would be preferable.  Actually, if you manage to clear 
all the DISCUSSes on this doc before March, so that Warren can approve 
it before the new IESG is seated, that would probably make both yours 
and Warren’s lives slightly easier at the transition.


Regards,

Rob

*From: *DNSOP  on behalf of Robert Wilton via 
Datatracker 

*Date: *Tuesday, 2 January 2024 at 15:41
*To: *The IESG 
*Cc: *draft-ietf-dnsop-avoid-fragmentat...@ietf.org 
, dnsop-cha...@ietf.org 
, dnsop@ietf.org , 
be...@nlnetlabs.nl , swo...@pir.org 
, tjw.i...@gmail.com , 
tjw.i...@gmail.com 
*Subject: *[DNSOP] Robert Wilton's Discuss on 
draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)


Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 


for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



--
DISCUSS:
--

Hi,

Thanks for this document.

I'm echoing Paul's and the SECDIR review comments here on the use of MAY in
recommendations (since everywhere you see MAY it is equally valid for an
interpretation to treat it as "MAY NOT"), but I think that this makes the
document, as a proposed BCP, unclear enough that I'm raising this to 
level of a

DISCUSS.

(1) p 3, sec 3.1.  Recommendations for UDP responders

    At the time of writing, most DNS server software did not set the DF
    bit for IPv4, and many OS kernel constraints make it difficult to set
    the DF bit in all cases.  Best Current Practice documents should not
    specify what is currently impossible, so R2, which is setting the DF
    bit, is "MAY" rather than "SHOULD".

I think that this recommendation, particularly because it is using RFC 2119
language, is unclear.  I would suggest rephasing this to something like:

    R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment
    flag (DF) bit" [RFC0791] on IPv4.

(2) p 3, sec 3.2.  Recommendations for UDP requestors

    R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
    size to the RECOMMENDED size of 1400 or a smaller size.

I find this recommendation to be unclear because it mixes both a 
"SHOULD" and
"RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies 
to.  Is

the recommendation (i) that UDP requestors should limit the maximum UDP
payload.  Or (ii) is the recommendation that a limit of 1400 be used, or 
(iii)
perhaps both.  Maybe rewording this to something like the following 
would help:


    R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
    size to 1400 bytes, but MAY limit the maximum UDP payload size to a
    smaller size on small MTU (less than 1500 bytes) networks.

    or,

    R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
    size.  It is RECOMMENDED to use a limit of 1400 bytes, but a smaller
    limit MAY be used.

(3) p 3, sec 3.2.  Recommendations for UDP requestors

    R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
    reassembly to avoid cache poisoning attacks.

As written, I don't think that this is really a recommendation.  Either 
it is a

just a statement or fact (in which case it is not a recommendation), or it
should be upgraded to a SHOULD.

(4) p 4, sec 3.2.  Recommendations for UDP requestors

    R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
    reassembly to avoid cache poisoning attacks.
    R8.  DNS responses may be dropped by IP fragmentation.  Upon a
    timeout, to avoid resolution failures, UDP requestors MAY retry using
    TCP or UDP with a smaller EDNS requestor's maximum UDP payload size
    per local policy.

Again, I think that this document would be clearer if this was a SHOULD 
rather

than a MAY.

Regards,
Rob





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




--
P Vixie

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

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

[Paul Vixie]

i think offering more than one wire encoding to get the same outcome 
would be the opposite of simplicity. if the ietf were to decide that 
dnssec had been a mistake and universal deployment was no longer to be 
sought, then we would want to look carefully at the features it had 
contained and consider other ways to get them.


if it helps, imagine that the lifetime total cost of an "if" statement 
in an open source program is about $10,000.00.


re:

Zhiwei Yan wrote on 2024-01-19 00:42:

Hello, Paul,

Simplicity and ease of use are fundamental features that enable the 
large-scale deployment of a protocol. You are right, everyone hopes for 
the widespread deployment of DNSSEC to mitigate various security risks. 
While, this draft addresses two key aspects: on one hand, we aim to 
delve into the security vulnerabilities associated with delegation, and 
on the other hand, propose corresponding solutions that can be achieved 
through extending DNS, or assuming DNSSEC and simpler optimizations 
based on DNSSEC.


BR,

Zhiwei

在 2024/1/7 18:01, Paul Vixie 写道:



zuop...@cnnic.cn wrote on 2024-01-06 22:59:

...

Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like 
attack, because it allows a DNSSEC-validating resolver to generate 
negative answers within a range. ...


have you looked at dns rrl?

... But if a NSEC3 RR has an Opt-Out flag, it can’t be used for 
aggressive negative caching.  In addition, DNSSEC adoption rate 
remains low in some area and this situation may not change 
significantly over a long period of time for policy reasons.


i think as long as we keep adding features that are only necessary 
because dnssec lacks certain features or is not universally deployed 
or both, then dnssec will lack certain features or not be universally 
deployed or both. please be careful what you wish for.


Compared to DNSSEC, the draft is relatively simple, it uses OPT RR 
option to confirm NS record only when a resolver is requesting 
address (Glue record) of delegation points. And it is compatible with 
current DNS protocol.


it will always be within our powers to add complexity. google for "dns 
camel" to find out one author's thoughts about how to use that power 
more wisely.







--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Paul Vixie]

i think you mean RPZ here.

Paul Wouters wrote on 2024-01-10 07:01:

On Wed, 10 Jan 2024, Lanlan Pan wrote:

I have submitted a new draft to discuss the faked answer returned from 
the recursive resolver.


Your comments are appreciated.


As I've said during the discussions on RBL and an updated version for
RBL, if these things are done "for the user", the best thing is to put
the censored answer in the authority section. This way ignorant clients
keep working with the censor, but knowledgable clients can DNSSEC validate
the censorship using the original answer and optionally present a choice
to the enduser. It also prevents censorship forced against the user's
interest. eg it makes this properly optin (eg compliant with RFC 8890)

There should be no synthesizing of fake records as those cannot pass
DNSSEC validation. One has to assume the querier is DNSSEC enabled,
even if it is a stub. We already have extended error codes for
censorship (see 
https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations

error codes 15-18)

Paul


-- Forwarded message -
发件人： 
Date: 2024年1月10日周三 16:11
Subject: New Version Notification for 
draft-pan-dnsop-explicit-forged-answer-signal-00.txt

To: Lanlan Pan 


A new version of Internet-Draft
draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been 
successfully

submitted by Lanlan Pan and posted to the
IETF repository.

Name:     draft-pan-dnsop-explicit-forged-answer-signal
Revision: 00
Title:    Explicit Forged Answer Signal
Date:     2024-01-10
Group:    Individual Submission
Pages:    6
URL:  
https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt 

Status:  
 https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/ 

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal 




Abstract:

   This document describes that recursive resolver should give explict
   signal in the forged answer.

   Client could react more clearly based on the explict forged answer
   signal, to protect user on security and privacy.



The IETF Secretariat






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



--
P Vixie

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

[DNSOP] PolarDNS

[Paul Vixie]

saw this today, looks damned useful.

https://www.helpnetsecurity.com/2023/11/21/polardns-open-source-dns-server/

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

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

[Paul Vixie]

zuop...@cnnic.cn wrote on 2024-01-06 22:59:

...

Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like attack, 
because it allows a DNSSEC-validating resolver to generate negative 
answers within a range. ...


have you looked at dns rrl?

... But if a NSEC3 RR has an Opt-Out flag, it can’t 
be used for aggressive negative caching.  In addition, DNSSEC adoption 
rate remains low in some area and this situation may not change 
significantly over a long period of time for policy reasons.


i think as long as we keep adding features that are only necessary 
because dnssec lacks certain features or is not universally deployed or 
both, then dnssec will lack certain features or not be universally 
deployed or both. please be careful what you wish for.


Compared to DNSSEC, the draft is relatively simple, it uses OPT RR 
option to confirm NS record only when a resolver is requesting address 
(Glue record) of delegation points. And it is compatible with current 
DNS protocol.


it will always be within our powers to add complexity. google for "dns 
camel" to find out one author's thoughts about how to use that power 
more wisely.


--
P Vixie

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

Re: [DNSOP] Artart telechat review of draft-ietf-dnsop-avoid-fragmentation-16

[Paul Vixie]

Barry Leiba via Datatracker wrote on 2023-12-29 19:40:

Reviewer: Barry Leiba
Review result: Ready with Nits

Thanks for addressing most comments from my earlier review.  One remains, and I
didn’t see an email response about it, so I don’t know whether there was a
reason not to make a change or if it just got overlooked:

— Section 7.2 —

If a UDP response packet is dropped (for any reason), it increases
the attack window for poisoning the requestor's cache.

But Section 3.2 says this:

R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks.

…which seems to be contradictory.  Can you clarify this apparent contradiction
in one place or both?


the requirements are in conflict, and this is a good catch. in 7.2 we 
should say "dropped in transit, up to and including the network stack of 
the initiator" since if it's dropped by the initiator (in user mode) the 
attack window will be closed thereby.


in 3.2 we should say "SHOULD" not "MAY", per mr. wouters' earlier 
comments. in addition we should say "SHOULD detect reassembled DNS/UDP 
responses in the DNS response processing logic, since the fragments 
thereof would have been subject to off-path cache poisoning attacks."


it's a very subtle point and has been wordsmithed more than once here. 
we don't want the initiator's window of willingness to receive a 
response to be any longer than possible, because of off-path (TID 
guessing) attacks. and we don't want to reassemble, because of off-path 
(fragment replacement) attacks. so we really do not want fragmentation 
to occur because it makes both of those attacks easier to launch. TID 
guessing is made easier if the network drops fragments or drops 
oversized packets. fragment replacement is made easier if there were in 
fact ever any fragments.


by recommending that the initiator detect when fragments are present (or 
were present, if the network stack reassembled them first) and drop 
them, we reduce the chance of bad fragments getting through, because no 
fragments will get through. we also disincentivize the generation of 
fragments in the first place, because they'll be silently dropped by (a 
growing number of) initiators.


as you can see i've fought the words and lost.

--
P Vixie

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

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

[Paul Vixie]

Paul Wouters via Datatracker wrote on 2023-12-29 11:37:

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: Yes


--
COMMENT:
--


 ...

If what you want is "we really really want this but it cannot be done on every 
OS",
then I think SHOULD instead of MUST is fine, but MAY seems too weak.


I agree.



 R7. UDP requestors MAY drop fragmented DNS/UDP responses without
 IP reassembly to avoid cache poisoning attacks.

 R8. DNS responses may be dropped by IP fragmentation. Upon a
 timeout, to avoid resolution failures, UDP requestors MAY retry
 using TCP or UDP with a smaller EDNS requestor's maximum UDP
 payload size per local policy.

Same here. R7 and R8 are "recommendations" so I feel the MAY's should be 
SHOULDs.
Otherwise the recommendation becomes "do whatever you MAY please", in which case
why are these in the document?


I agree.


 R9. Use a smaller number of name servers (13 may be too large)

I would say "name server names" instead of "name servers", to avoid any 
ambiguity
of anycast name servers operating under the same name. Eg the document is not
saying "use less than 13 name servers", but it is saying "use less than 13 name
server names"


I agree.




 smaller than those usually used for RSA.

smaller than those of equivalent cryptographic strength using RSA


I agree.


--
P Vixie

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

Re: [DNSOP] QNAME minimization is bad

[Paul Vixie]

Joe Abley wrote on 2023-11-10 23:40:

On 10 Nov 2023, at 21:26, Brian Dickson  wrote:


Perhaps the DNSBL operators could individually or collectively operate 
resolvers which do that exact thing?


I'm not sure why the answer isn't "MTAs should run local resolvers configured in 
ways that best suit them".
...



i think operators of todfay's MTAs have no memory of the time before 
anycast, when every operator especially those of significant 
infrastructure ran their own RDNS locally. to them it's a mystery why 
F/L/OSS DNS software exists at all, or who uses it, or why.


apologies if your question was meant to be rhetorical.

--
P Vixie

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

Re: [DNSOP] QNAME minimization is bad

[Paul Vixie]

we need Q-M, since without it NXDOMAIN is ambiguous. a full resolver 
("recursive nameserver") who looks up wrong2.wrong1 deserves to know 
that wrong1 doesn't exist so that it need not ask the root name servers 
about wrong3.wrong1. whatever ambiguities may come from Q-M will have a 
lower cost than those it addresses and according to engineering 
economics would be addressed separately from the original problem and 
after the current solution, unless a new solution is available that 
addresses both.


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

[DNSOP] NOTIFY: How to locate the target

[Paul Vixie]

None of the above. Do what RFC 2136 does to send updates to the primary 
authority, or do what RFC 1996 does to send notifications to all listed 
authorities. Any new signaling is effectively a way to go out of band. The 
system is complete as it is. 


p vixie 


On Nov 8, 2023 12:06, Peter Thomassen  wrote:

Dear DNSOP, 

As laid out at the DNSOP session on Tuesday, 
draft-ietf-dnsop-generalized-notify (and also 
draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the 
parent-side endpoint (target) where the child DNS operator can send a NOTIFY 
for DS update (or other kind of signal). 

Locating the target via a DNS query needs a predictable qname and type. The 
feeling from the room was that for various reasons, a new rrtype with SVCB 
semantics should be used. 

As for the qname, the authors would like to gather some feedback from the list 
regarding the preferred approach. The below uses the domain "child.se" for 
illustration: 

Alternative #1(a): Look up record at se. (delegating parent's apex) 
- Simple 
- Clogs the apex with more records 
- Likely does not cover all use cases (such as per-registrar target, when they 
want to process the NOTIFY) 

Alternative #1(b): Look up record at _notify.se. (some underscore label below 
parent) 
- Slightly more complex than above 
- Avoids clogging the apex, at the expense of some namespace pollution 
- Covers same use cases 

Alternative #2: Look up record at child._notify.se. (or other magic label) 
- Allows parent to publish per-child targets (e.g. the registrar's endpoint) 
* Needs maintenance or synthesis 
- Magic label could be considered namespace pollution 
- Unneeded complexity if parent is not a registry (e.g. a university) 

Alternative #3: Try #2, and on failure fall back to #1(a) or #1(b) 
- Combines simplicity and flexibility, but conceptually most complex 
- Might cause two DNS queries 

Please weigh in on what you think is the best approach. 

Thanks, 
Johan, John, Peter 

-- 
https://desec.io/ 

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

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

Re: [DNSOP] Automated delegation management via DDNS

[Paul Vixie]

see inline.

Johan Stenstam wrote on 2023-10-25 01:09:

Greetings Working Group,

As many of you are aware Peter Thomassen, John Levine and I have been working 
on the generalised notifications for a while. The key idea there is obviously 
that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the parent scanner 
will allow the scanner to fast track the scan of that particular child thereby 
making everything converge faster and presumably make the child happier.

But scanners still suck in general.


can you more closely define "scan" in this context? i would expect a 
query for the notified type at the notified name, but not some kind of 
enumeration of multiple possibilities.




So now there’s a new draft, that further extends the same core idea (locate the 
target for the information being sent via a DNS lookup in the parent zone). 
However, the new draft (draft-johani-dnsop-delegation-mgmt-via-ddns-00) 
proposes that instead of sending a NOTIFY (triggering a scan from the 
recipient) the child sends a DNS UPDATE containing the exact change with a 
signature that can be verified by the recipient.

The recipient is typically not the primary name server for the parent, but 
rather a small service that does the same policy verifications, etc, that a 
scanner would do before committing the change.


i am uncomfortable using the UPDATE RCODE for a purpose unrelated to 
zone modification. perhaps propose a new RCODE having the same message 
form as UPDATE?




There are two key advantages to this alternative:

1. ...

2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the 
management of delegation information for *all* zones, regardless of whether the 
parent is signed or not, regardless of whether the child is signed or not, is 
an advantage.


some years back this working group adopted a ubiquity regime for DNSSEC 
in that all new specifications "must" expect DNSSEC to be in use and 
"should" depend on it when in-scope functionality is needed. has that 
changed?


--
P Vixie

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

Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-avoid-fragmentation-15

[Paul Vixie]

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

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Paul Vixie]

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

Re: [DNSOP] Clarifying motivation for Compact DoE

[Paul Vixie]

see inline.

Shumon Huque wrote on 2023-08-08 12:13:
At any rate, as I've remarked before, I'm not convinced that the 
optimizations offered in Compact DoE were actually necessary as an 
operational matter. But I'll leave it to our colleagues at Cloudflare to 
argue that case. My interest in publishing this spec is (1) to 
officially record one of the now dominant implementations of DNSSEC 
amongst the commercial online DNS signers, and (2) to restore more 
precise NXDOMAIN visibility.


+1.

also: provide coherent implementation guidance for operators who want this.

--
P Vixie

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

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

[Paul Vixie]

George Michaelson wrote on 2023-07-26 16:11:

...

maybe the truth is, we've got 15 bits of zero in the header forever, amen.


that's how i treated it when i crafted EDNS0. we'd have to negotiate any 
new use, and we've since learned that billions of middleboxes will treat 
that as a 16-bit field which must always be 0 or 1, no matter what the 
endpoints may have agreed to.



clue-stick hits welcome. Avoid the stomach.


i think that some 30 years before there was an RFC called "pervasive 
monitoring is an attack" there should have been an RFC called "middle 
boxes are an attack". forget about killing hitler's grandparents or 
whatever -- this is what a time machine is needed for.


--
P Vixie

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

Re: [DNSOP] Compact DoE sentinel choice

[Paul Vixie]

on "mollify".

Viktor Dukhovni wrote on 2023-07-25 22:59:

On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:


At the name that does not exist, generate and sign (on the fly) a CNAME
record with RDATA of something like "nxname.empty.as112.arpa" (or something
functionally equivalent).


Sadly, this reports that the CNAME *target* does not exist, but the name
in question certainly does (it holds a CNAME).  This also does not
exclude the existence of subdomains of the name (which NXDOMAIN does,
when one isn't bending over backwards to interoperate with servers that
return NXDOMAIN for ENTs!).

Also, with the target zone unsigned, the response is subject to forgery,
returning real data for the target.


Only one signature is required, since there is an answer, rather than just
an NSEC(3) with bitmap.


Does it mollify the folks who want an NXDOMAIN signal?  I guess it is
not obviosly worse than an apparent NODATA, and the target could even
be a fixed non-existent name in a suitable zone under control of the
signer, which would have a real (signed) NXDOMAIN proof, avoiding
an unsigned target in as112.  But I remain sceptical about the wisdom
of such a design.


as a pattern intended to replace signed nxdomain for those dnssec 
authorities with an allergy to responses larger than 512 octets, a 
bespoke cname would be a bad thing. however a validly signed cname to 
validly signed nonexistent name would be fine, because the rcode in that 
case would be 3 in the rdns->stub response. i'm not sure how this would 
solve the 512 octet allergy threshold though.


olafur's original reasoning in the CF blog post was that since a client 
would take the same next step if it received noerror/nodata as it would 
if it received nxdomain, CF would be sending the shorter of these two 
apparently equivalent signals. i disagreed, partly because there would 
be a second query for A if a query for MX or for  returned 
noerror/nodata but not if it returned nxdomain, but mostly because DGA 
botnets can be detected in formation by looking at nxdomain storms, but 
not by looking at noerror/nodata storms.


any of the proposals that restore unambiguity to the name-doesn't-exist 
condition are fine by me. notably, i'd vastly prefer signed nxdomain, 
which most dnssec authorities don't have a 512 octet allergy threshold 
for, including dnssec authorities who send a _lot_ more nxdomain answers 
than any CDN send. however, if that won't be done, let there be an RFC 
for some new more complex signal pattern to describe the trifecta of 
"nxdomain, nonexistence proof, nonwildcard proof" condition.



ENTs are distinguishable (they would get the current ENT response of
NSEC/RRSIG bit map)


Well current, by the book, ENT response is NOT NSEC/RRSIG (unless you
mean current compact denial rule-bending behaviour).

Rather for a standard ENT, we have:

 enszzz.example. IN aaa.ent.example. IN NSEC NSEC RRSIG A ...

The ENT is just an ancestor of the "next" name in a covering NSEC
record.


very few of the lookups where noerror/nodata vs. nxdomain ambiguity is 
problematic are nonterminals. if that's making a solution elusive, feel 
free to note that ENTs aren't nonexistent, so Compact DoE doesn't apply.



Am I incorrect in the asserted behavior of such a synthesized CNAME
(and that it would match the requirements)?


It would be a stretch.  Mind you, with a target in globally shared zone,
caching of its non-existence saves followup queries for all zone using
the scheme.  If the target is signed and has a long negative TTL,
efficiency is retained, but it we don't get "nothing below" semantics,
and with some auths mixing CNAME and other data, don't even necessarily
conclude there's no other data at the name.


it would be a hack. but not intolerable if the target wasn't bespoke. 
you can get the same caching efficiencies from a per-CDN "Negative 
Zone"(*) since it would be receiving CNAME chains from many millions of 
customer domains.


(*) https://en.wikipedia.org/wiki/Negative_Zone


So I am disinclined to go there, barring lots of evidence that it
actually satisfies the various motivating use-cases and has broad
support.


be too, but if so it still deserves to be a Road Not Taken in the RFC, 
along with a pointer to the wikipedia page above.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[Paul Vixie]

John Levine wrote on 2023-07-19 14:43:

It appears that Paul Wouters   said:

On Jul 17, 2023, at 22:50, Paul Vixie  wrote:

... RFC 4408 was folly. ...


The IETF did make a mistake there for sure.


I wouldn't disagree, but you can barely see the spots in the dirt
where the barn was before the horse left. Viz the pile of junk at the
apex of any domain of any organization of any size. If performance or
token collisions were a practical problem, surely someone would have
noticed by now.


that's false in several ways. we do notice. we cope, at some cost. we 
ought to learn a lesson from each mistake, and gradually turn ship. your 
fatalism is unbecoming.


--
P Vixie

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

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

[Paul Vixie]

George Michaelson wrote on 2023-07-18 22:41:

...

my concerns with the PSL governance aren't relevant either. I am sure
it was purposeful. I don't have to like things for them to provide
upsides.


when we've tried to talk about solving the PSL's original problem 
differently, we've run into the brick wall of "well it's just for web 
cookie same-origin policy, let's let the browser makers decide what to do."


it's not. (not just a web thing.) yes the web also needs it. but every 
dns-aware application also needs it. we just can't get those people to 
represent themselves as well as the browser makers can.


some friends and i are working on something. but if we can't get someone 
not-from-the-web to say why something-like-PSL is important, it will not 
matter. see also attached image.


--
P Vixie

Title: Redirect Notice
Redirect Notice The previous page is sending you to https://www.pelicancrossing.net/netwars/2019/03/layer_nine.html. If you do not want to visit that page, you can return to the previous page.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

[Paul Vixie]

George Michaelson wrote on 2023-07-18 17:42:

I know, I could submit these to the PSL website directly. I am asking
a meta question: do we think that operationally, if a PSL exists, that
all ccTLD and TLD should be on it?


no. as we learned from delegation-only, some TLDs don't.

i see ~36mil unique A RRsets in *.family passive dns, ~16mil unique  
RRsets, and ~155kilo MX RRsets.


far fewer in *.museum, but still, present.

the PSL wasn't created without a reason.

--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[Paul Vixie]

John R. Levine wrote on 2023-07-17 18:22:

On Mon, 17 Jul 2023, Shumon Huque wrote:

...
This is not a new issue. It is the well known record subtyping
problem that was advised against in RFC 5507 (IAB; "Design Choices
When Expanding the DNS"). That advice was targeted to new RR type
design, but it applies just as well to this type of use of TXT
RDATA resident at the same name.


Agreed, but that horse had already left the barn when we published the 
first SPF RFC 4408.
RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain 
verification well (wildcards aren't a factor) and would in no way be 
precluded by the SPF design. perhaps a sub-domain under 
._wellknown.$apex, to match current style in the w3c world.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[Paul Vixie]

Joe Abley wrote on 2023-07-17 12:50:
On Mon, Jul 17, 2023 at 21:41, Brian Dickson 
> 
wrote:

TCP traffic is several orders of magnitude more expensive than UDP.
Anything that bumps up the proportion of TCP traffic in a 
statistically meaningful way causes issues.


I see UDP as a legacy transport, required for backwards comparability 
but that's about it. The writing is very much on the wall, there.


-1.

If the stability of anybody's infrastructure depends on people choosing 
a particular transport, I would suggest they might have reason to be 
worried. Simply hoping that people don't start using TCP in a 
significant way is putting your stability in a lot of other peoples' hands.

also -1. state has mass. avoiding it will remain worthwhile.

--
P Vixie

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

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Paul Vixie]

Robert Edmonds wrote on 2023-06-29 14:58:

Tim Wicinski wrote:

...

Feedback Welcome

tim

...



I originally developed one of the implementations named in this draft
[1] and if I recall correctly it did not occur to me that the API I was
developing should ever be standardized, let alone the underlying data
model being used to generate API responses, which I don't think this I-D
has ever touched on. E.g., the 'rdata' field may return a string or an
array of strings; if you have an array of length 1, does this mean a
resource record or a resource record set is being represented? ...


the implementation you pioneered eventually started an industry, and all 
of us wanted compatibility across access formats. it likely will never 
be extended to include the REST portion of the API, but the JSONL format 
is most convenient to accessors if it's not useless different.


rdata is now described as an array, since that's what all 
implementations now return. we added a note that it may be a string and 
that accessors should be prepared for this for backward compatibility. i 
think that could be removed at this stage (years later.)



So, it seems a bit odd to me to try to put a particular narrowly scoped
idiosyncratic consensus format used by a few particular API services
through the RFC process. There are many kinds of databases, API
services, and formats that do not have RFC documents describing them.
For instance, the pcap savefile format is widely used and presumably a
lot of governments buy a lot of products that support the pcap format,
and as far as I can tell the canonical specification for that format is
a file in a particular Git repository [2] maintained by a group of open
source contributors. Why isn't that approach feasible for this
particular use case, which is much more of a niche use case than packet
capture in general?


i'll be happy to host the specification on 
https://github.com/dnsdb/dnsdbq if that's the IETF's preference. this 
command-line API client (in C) intends to speak to as many API servers 
as possible. it was inspired by the API client you pioneered (in 
Python). i also wrote a Go version but it's not open source. in any 
case, SIE Europe U.G., a non-profit in Germany where i am a founder and 
director, hopes that some document somewhere will describe the format of 
our API server's output. we are a partner of farsight/domaintools so our 
format is the same as theirs. but we want our members to be sure that 
any processing they wish to do with our database output has no "lock-in" 
properties. therefore, documenting this only on the domaintools web site 
would not be adequate.


--
P Vixie

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Paul Vixie]

Wes Hardaker wrote on 2023-05-01 14:57:

Paul Vixie  writes:


if we need more terms let's invent. but this term has established meaning.


There I fixed it for you:


that's a meme, right?


If we need more terms let's invent. But this term has established meaning*s*.


the first use is still in wide use. i understand there's also wide 
misunderstanding. but just as the RBL will always mean blackhole list to 
many people (not a block list no matter what the marketing department 
may believe or prefer), so it is that a lame delegation still means to 
many what it means upon being coined in ~1989 or so at CSIRO.


if you want to fix it, for me or anybody else, i suggest not trying to 
do so with a meme. i'm joining your thus-cheapened date precisely once.


--
P Vixie

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Paul Vixie]

Joe Abley wrote on 2023-05-01 14:15:> Yes -- some people (not me) would 
evidently describe a server that they
didn't receive a response from as lame. Such a situation could be a 
result of a bad configuration but also any number of other things, such 
as a network problem or a misconfigured firewall.


because the problem could be a middlebox on your end (edns botchery), a 
fiber cut, ddos protection on the far end, or other non-dns prime cause, 
nothing about unreachability or silence nec'ily has to do with the server.


to be a lame _delegation_ means some error or misconfiguration in the 
server. normally this means it's supposed to be authoritative but the 
zone expired or the operator forgot or similar. or there is no server 
there any more (it was decomm'd or renumbered). icmp host-unreach or 
port-unreach would be symptoms of that, if you can hear them.


if we need more terms let's invent. but this term has established meaning.

--
P Vixie

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

[DNSOP] can someone forward this to benno?

[Paul Vixie]

i don't know why it was rejected as spam but his sysadmin might.
--- Begin Message ---
This is the mail system at host ietfa.amsl.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

 (expanded from ):
host mx.soverin.net[185.233.34.143] said: 554 5.7.1 Spam message rejected
(in reply to end of DATA command)
Reporting-MTA: dns; ietfa.amsl.com
X-Postfix-Queue-ID: EAF7AC1519A1
X-Postfix-Sender: rfc822; paul@redbarn.org
Arrival-Date: Wed, 26 Apr 2023 08:56:51 -0700 (PDT)

Final-Recipient: rfc822; benno@NLnetLabs.nl
Original-Recipient: rfc822;expand-dnsop-chairs@virtual.ietf.org
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx.soverin.net
Diagnostic-Code: smtp; 554 5.7.1 Spam message rejected
--- Begin Message ---



Shumon Huque wrote on 2023-04-26 08:43:

I support adoption too.

As I've mentioned earlier, this mechanism is widely deployed and needs a 
published specification. Adopting the work will also allow us to 
formally specify an accurate NXDOMAIN signal (and work out its related 
details more fully).


Shumon.


+1.

On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski  
...


Please also indicate if you are willing to contribute text, review, etc.



willing to contribute and review.

--
P Vixie

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

Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC

[Paul Vixie]

Shumon Huque wrote on 2023-04-26 08:43:

I support adoption too.

As I've mentioned earlier, this mechanism is widely deployed and needs a 
published specification. Adopting the work will also allow us to 
formally specify an accurate NXDOMAIN signal (and work out its related 
details more fully).


Shumon.


+1.

On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski  
...


Please also indicate if you are willing to contribute text, review, etc.



willing to contribute and review.

--
P Vixie

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

Re: [DNSOP] [Ext] Meaning of lame delegation

[Paul Vixie]

Peter Thomassen wrote on 2023-04-15 10:13:



On 4/10/23 15:39, Wessels, Duane wrote:
“A lame delegation is said to exist when one or more authoritative 
servers designated by the delegating NS rrset or by the apex NS rrset 
answers non-authoritatively for a zone”.


... or by the *child's* apex NS rrset ...

(The delegating zone also has an apex NS rrset. We know that that's not 
meant, but somebody looking up the terminology because they are not so 
familiar might need that extra clarity.)


i accept this as a friendly amendment.


--
P Vixie

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

Re: [DNSOP] [Ext] Meaning of lame delegation

[Paul Vixie]

Wessels, Duane wrote on 2023-04-10 06:39:

I think Paul’s definition is good and matches the way I think of a lame 
delegation.

My one quibble would be with the ending part that says “that zone is said to 
have…” This is somewhat confusing because the definition combines both a 
parent-child delegation and an apex/self delegation.  If we’re talking about a 
name server in the delegation from com to example.com, I’m not sure it is 
correct to say that the example.com zone has the lame delegation.

Perhaps:

“A lame delegation is said to exist when one or more authoritative servers 
designated by the delegating NS rrset or by the apex NS rrset answers 
non-authoritatively for a zone”.


i accept this as a friendly amendment.


On Apr 9, 2023, at 12:31 AM, paul=40redbarn@dmarc.ietf.org wrote:


"If one or more authoritative servers designated by the delegating NS rrset or by 
the apex NS rrset answers non-authoritatively for a zone, that zone is said to have a 
lame delegation."

p vixie

On Apr 9, 2023 04:13, Paul Hoffman  wrote:
I have been on vacation this week and am just seeing this thread now. Now that 
a bunch of people have spoken up on the topic, if someone wants to propose a 
*specific* change to the definition in draft-ietf-dnsop-rfc8499bis, this would 
be a very good time to do it, given that we are after WG Last Call but waiting 
for AD writeup. Otherwise, the current wording will be used for IETF Last Call.

--Paul Hoffman



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




--
P Vixie

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

Re: [DNSOP] Meaning of lame delegation

[Paul Vixie]

Joe Abley wrote on 2023-04-04 09:14:

> ...

I think it's pretty common to talk about one nameserver for a zone being lame 
and another nameserver for the same zone not. Certainly that's not an uncommon 
configuration to find in the wild.

I have always used "lame delegation" to refer to the situation where one 
nameserver in a delegation NS set (above the zone cut) not responding authoritatively for 
the QNAME that triggered the referral; that particular nameserver is lame for that 
particular zone. I think the response component is important since it speaks to how a 
nameserver is configured, which is important. ...


That's what the term "lame delegation" meant in BIND 4 back in 1989 or 
so when Mark Andrews, then at CSIRO, contributed the logic and the 
associated syslog() call. it wasn't popular since it told recursive 
server operators about authority configurations they could not fix.



It's kind of fun that there are so many ways that people think of this term 
when, in my experience, people generally agree enough when they are actually 
trying to debug something for the term to be useful.


a few years back somebody told me i named the RBL wrong and it's 
actually an acronym for something i didn't mean and don't agree with. 
"kind of fun" is now how i experienced that, but YMMV.


--
P Vixie

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

Christian Elmerot wrote on 2023-03-29 08:24:


On 2023-03-29 15:45, Paul Vixie wrote:


however, olafur's original CF blog post about CDoE also talked about 
packet size (desiring explicitly to fit in 512b). justification was 
about fragmentation avoidance, not CPU time needed to construct 
responses that were smaller than 512b being less than for responses 
that were larger than 512b. i think it's worth asking if this still 
matters, or else, is the current perceived benefit of CDoE simply that 
a NODATA response is easier to construct and contains no wildcard 
disproof?


The original blog does bring up the CPU argument: 
https://blog.cloudflare.com/black-lies/

from the Conclusion:

"We’re proud of our negative answers. They help us keep packet size 
small, and CPU consumption low enough for us to provide DNSSEC for free 
for any domain"


after X years your load has scaled to use all headroom added by your 
supply chain? usually these things relax. are you sure you still need to 
ask the world to accept NODATA in place of NXDOMAIN?


be sure that while olafur's blog is proud of its negative answers, those 
answers are non-negative, denying rrsets but not names, and the cost of 
that shortcut is a burden on internet security workers everywhere. we 
need to know when a name is asserted to not exist, and when.



and yes packet size still matters
can you help me understand why? for the networks i touch, PPS matters 
quite a lot but BPS differences between 512b and 1500b do not.


--
P Vixie

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

Joe Abley wrote on 2023-03-29 01:56:

Hi Paul,

On Tue, Mar 28, 2023 at 14:51, Paul Vixie 

... for perspective, no root name
server has deployed this alternative form of Denial of Existence, ...


Root servers don't do online signing; they serve a pre-signed zone. They 
don't have a motivation to reduce the cost of signature generation at 
response time because that cost is already zero.


oops. duh.

however, olafur's original CF blog post about CDoE also talked about 
packet size (desiring explicitly to fit in 512b). justification was 
about fragmentation avoidance, not CPU time needed to construct 
responses that were smaller than 512b being less than for responses that 
were larger than 512b. i think it's worth asking if this still matters, 
or else, is the current perceived benefit of CDoE simply that a NODATA 
response is easier to construct and contains no wildcard disproof?


--
P Vixie

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

see inline.

Viktor Dukhovni wrote on 2023-03-27 18:00:

[ Multi-response to four upthread messages. ]

---

...

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?


that may depend on the beholder's eye. for perspective, no root name 
server has deployed this alternative form of Denial of Existence, and i 
believe this includes the f-root anycast instances operated by 
cloudflare under ISC's management. root name servers receive an awful 
lot of junk, and aren't in general overfunded, so if compactness of DoE 
was compelling for anybody, it seems like it would be for them. yet:



; <<>> DiG 9.18.9 <<>> +dnssec luasfluh. @f.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55686
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;luasfluh.  IN  A

;; AUTHORITY SECTION:
.   86400   IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2023032800 1800 900 604800 86400
.   86400   IN  RRSIG   SOA 8 0 86400 2023041005 
2023032804 951 . lNcrq1jIeyKGIpkcgMdpPW77yeCLJ+2vU9+HM9Jwr0m1g6RZE8YyxlRA 
+q2oIuDHailclFDPMdjgX2lAMhxaNjWl/H+c2fjZN4+yIRWDcUPnDou5 
sn0S5s2fZQTqdnVghSz4JVXJUCo6bTPWDoA8kt/kuXL/bamISWiI0P39 
VYplvnIVVm7/oQ8gYmWChNfl3TkCXZsbLtsKc2sW5Ssjb50Gs7WKduvo 
UCJRmviRNfJvWcZt1nzZWNGTlwDQcJKTLQDSdXXQd+j4FyUpgIAS3THd 
GzpQblEEKSgYRrGUGbZJ9QKAy0niI2D0JVqHmeHP+g3M8CC7QKKK3FsH Xb9Paw==
lu. 86400   IN  NSEClundbeck. NS DS RRSIG NSEC
lu. 86400   IN  RRSIG   NSEC 8 1 86400 2023041005 
2023032804 951 . KS2/AAlD6atD3EfuRwCciYyBtl4aedoOMd2Z60EzZFoXbbGm9ghYPFeB 
xO+7MpYUTeNQ8ZSI9hZXeNf5ood3QORw4Wevo+XxoQoFnHxyXnLjlpXA 
2h+N3/yPjt20iCTD6zF1n/AOxDnATzIabj6StaMO4dMD7pXTHQxWE+a5 
vCQNRrWVQKv43QFj7zkEBaYX7YHFwKyODdIXnIBnrq1sItGqpZ8nYoaZ 
odCGzFyaMh3vN1FPbrgVhTDeDFFAkQ8k9nZjmQ+r6YtZqgdsx9zY5Lao 
K/EfL6+2UtGiQSVi1O/KzxjZ933t0BkyFNv6jqZANNfTIt1PBvbFWDH+ jfiCbw==
.   86400   IN  NSECaaa. NS SOA RRSIG NSEC DNSKEY
.   86400   IN  RRSIG   NSEC 8 0 86400 2023041005 
2023032804 951 . s9mtWsArs0D1e93ri9e7FVsvMH8gQE/R2zO2plcvd+gkbNuuQwR+SyYT 
rJu7s0mUkuKCsNyU26k8E4ve5S7RbI7Zkg5mGVUoaoLOlk229l3PGPzj 
pj1k8fyHUh1ed1PyYxq1UlnIxPAGiSCocKHlB5Dp1CHACCw4zYT4bl/V 
czCCcyqesCD+eTI+CF1hMiZOOIc9heViHENFzG1qPCH8PLDHJVpl3cJm 
H0zriGwGQk8D/JGp2M7SEgr/JmJCSpmHwmMbwC//UUaPKvpFLqoEFr5x 
6TCxDDg5u8eynptBeuoRqKYBWey+nl1pAC30tBhkjwqCjS19fNBVhmbh BbygbA==

;; Query time: 3 msec
;; SERVER: 2001:500:2f::f#53(f.root-servers.net) (UDP)
;; WHEN: Tue Mar 28 12:42:04 UTC 2023
;; MSG SIZE  rcvd: 1028


i strongly suspect that the era has passed during which compactness of 
DoE was worth its complexity cost. however, i think that's a decision 
for each operator. my only objective concern is that all Denial of 
Existence signals emitted by any DNS server be distinguishable from 
NODATA and distinguishable from ENT. so if "compact DoE" goes forward 
those should be hard requirements.



The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
... 
i feel you, brother. however, if operators insist that they've got to 
have this, we'll have to accept the complexity costs necessary to meet 
my above-described hard requirements.


--
P Vixie

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

Shumon Huque wrote on 2023-03-14 09:05:

...

So, I think the only way we could safely do RCODE replacement for signed 
responses is by the use of an EDNS signal.


sadly, +1.

--
P Vixie

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Paul Vixie]

Peter Thomassen wrote on 2023-03-05 14:56:

(Compact NSEC answers prevent zone enumeration just as well, if not better.)


that makes it even cooler, and it was already cool. (so long as the 
nxdomain signal is not suppressed as in the cloudflare prototype.)


--
P Vixie

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

Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC

[Paul Vixie]

Florian Obser wrote on 2023-03-01 22:42:


I might not be caffeinated enough yet, but I think the next domain name
in section 5 should be \000.ent1.example.net:

   ent1.example.net.  3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT

In section 6, calling getaddrinfo() return values exit codes is a bit
odd, maybe this will do?

Address lookup functions typically invoked by applications won't see
a practical impact from this indistinguishability.  For a non-
existent name, the getaddrinfo() function for example will return a
value of EAI_NODATA rather than EAI_NONAME.  But either way the
effect on the caller is the same: it will obtain a response with a
non-zero return value and no available addresses.


that's just not true, no matter how it's worded.

if i get NODATA i might try other record types (for example,  after 
A, A after , or both  and A after MX).


if i get NXDOMAIN, i won't.

there's also a huge impact on operational security.

indistinguishability would a huge problem.

please outlaw it.

--
P Vixie

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

Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS

[Paul Vixie]

thanks for this. can you propose new text? educating the authors to the 
point where they can speak for your experience may be error prone.


re:

Vladimír Čunát wrote on 2023-01-28 09:42:
With Knot Resolver + Knot DNS the fragmentation issues are currently 
being addressed quite simply:


  * IP_PMTUDISC_OMIT to avoid spoofed MTU
  * UDP size limit, 1232 by default (and of course honoring if the other
side wants lower, etc.)

Other points from the draft, perhaps less important:

  * fragments are ignored if they arrive over an XDP interface (XDP
usage is not typical)
  * TCP is attempted after repeated UDP timeouts
  * minimal responses: yes (not configurable)
  * smaller signatures: yes, ecdsap256sha256 by default


I also believe that the MTU spoofing should be reflected in this draft's 
recommendations.  With the current list I _suspect_ attackers could 
relatively easily force all 512B+ answers to TC=1 + TCP (if on IPv4).



1232: I haven't gone in detail over the relevant measurements so I'm not 
even 100% sure they're conclusive, but it might really will be better to 
increase that default.  I don't expect any other changes related to this 
draft for future.



Use 'minimal-responses' configuration: Some implementations have a 
'minimal responses' configuration that causes DNS servers to make 
response packets smaller, containing only mandatory and required data


Nit: this formulation makes me wonder what this recommends for SVCB-like 
records.  Strictly taken I'd say it clashes with some SHOULDs from the 
soon-to-be RFC.  Either way, SVCB-like queries could be prone to 
generating large answers (if this SHOULD is followed).



--Vladimir



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




--
P Vixie

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

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

[Paul Vixie]

On Fri Jan 20, 2023 at 6:53 PM UTC, Paul Wouters wrote:
> It seems there should be more discussion which hopefully would lead to
> a converging BCP before moving forward. Hearing from other main
> implementations would be extremely helpful here.

i have always been a fan of ISC's work, but i agree with two implications
of the above observation. first, as stated, we should hear from more than
one dominant implementations. second, unstated above but implied, the
priorities of an implementer are sometimes time-variant (the implementer
may think differently later) and often narrow (having more to do with the
problems that implementer sees than with what the community can foresee.)

long before the heat death of the universe, packets must grow in order to
amortize header processing costs against larger payloads. yet fragmentation
must not return. we ought to pave a step or two down the path that EDNS
incorrectly precluded us from in its earliest and most ignorant form.

so, i appear to be +1 to mr. wouters' suggestion above, for those reasons.

vixie

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

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-dns-catalog-zones-08

[Paul Vixie]

Joe Abley wrote on 2022-12-09 14:59:


On Fri, Dec 9, 2022 at 23:17, Catherine Meadows via Datatracker 
mailto:nore...@ietf.org>> wrote:
Nits: There are a lot of unexplained acronyms, especially at the 
beginning:
RR, SOA, NS RR, RDATA, PTR, and so on. These should be spelled out the 
first

time they are used at the document.
Most of these are the formal names of well-known code points in the DNS 
as well as being acronyms.

should be Rdata or RData but never RDATA.

--
P Vixie

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

Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6

[Paul Vixie]

i consider every example in that draft to be implied by the current 
2317, and all are in wide use. it's a better-written document, though 
lacking coverage of some common use cases such as comcast's delegation 
to my house of a /24.



;; ANSWER SECTION:
1.150.104.24.in-addr.arpa. 3600 IN  CNAME   1.0-255.150.104.24.in-addr.arpa.
1.0-255.150.104.24.in-addr.arpa. 3600 IN PTRinternal.gw1.rits.tisf.net.


the /24 and /16 subdelegation cases follow directly from 2317's claims, 
even though i had to have this told to me by comcast at the time before 
i could see that.


i sort of regret $GENERATE, it would be better if the zone did not have 
to be macro-expanded in this way before it could be axfr'd (or ixfr'd). 
if i had it to do over again i'd have proposed some kind of RR-encoded 
metadata to show the desired $GENERATE-like effect. but let's not take 
that on right now, ok?


so:

Tim Wicinski wrote on 2022-12-08 09:52:


Some time back Tony Finch proposed a 2317bis - 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00

which the WG adopted but died for lack of interest.

It would be useful to revise this document

tim

+1, and i'll commit to reviewing it.

--
P Vixie

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

Re: [DNSOP] .alt filtering in recursive servers

[Paul Vixie]

Mark Andrews wrote on 2022-11-11 02:26:



...

   4.  Caching DNS Servers: Caching servers MUST [or SHOULD] NOT
   attempt to resolve .alt names in the global DNS root.  They
   MAY respond to queries for such names with NXDOMAIN [or
   REFUSED?].


Caching servers MUST NOT intercept DO=1 queries as the client
will not be able to validate such responses.  The caching
recursive server MAY synthesise a provable NXDOMAIN response as
per RFC 8198.  Caching servers SHOULD perform QNAME minimisation
as per RFC 7816 for the .alt namespace by default.  Querying for
alt/DS or alt/NS will achieve this without leaking the query type.


i'm comfortable with either. a query for anything.ALT appearing on any 
wire is a sign of misconfiguration. dropping it, answering insecurely, 
answering servfail, or letting qname minimization from the root zone 
happen and sending secure nxdomain, are all in-scope here. as long as we 
are protecting the root zone from .ALT query storms, we're good. no 
other predictable or reliable response should be specified. makers and 
operators who allow .ALT queries to appear on the wire should learn fear 
and should live in fear. being liberal in how we receive those queries 
is in absolutely nobody's best interests.


--
P Vixie

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

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

[Paul Vixie]

Joe Abley wrote on 2022-11-07 13:38:

...

I continue to think the necessary/useful debate is a silly one. In the context 
of a referral response, glue means additional-section records that the sender 
of the referral imagines might possibly be helpful to the receiver (which in 
turn means it might be helpful to the sender, since the sender is in the 
business of sending things that can be used). The sender has no way of knowing 
for sure whether that will turn out to be true at the time when the response is 
sent.


back before the dawn of time, akira kato and i tried to reason about 
these distinctions, so that additional data rrsets could be prioritized 
according to utility, and "unnecessary" truncation could be avoided. 
this was specifically in the context of referral responses, since other 
uses of additional data (like MX or SRV) were always for convenience.


below-delegation had a higher priority than in-bailiwick which had a 
higher priority than out-of-bailiwick. i still think this is so.


the sibling case is either degenerate (mutual dependency) which should 
just fail, or normal in which case you'll get the additional data you 
need when you try to chase the out-of-bailiwick NS.NSDNAME.


i think codifying this terminology apart from the question of referral 
response priorities was always a stretch and need not be pursued.


--
P Vixie

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

Re: [DNSOP] [Ext] root crud, Possible alt-tld last call?

[Paul Vixie]

John Levine wrote on 2022-10-25 14:30:

> ...

...  Considering the vast amount of junk traffic that the roots
get now, it's hard to imagine that .alt would add enough to care about.


we don't and can't know that. in any case we should first do no harm.

the DNS is capable of signaling that a given domain isn't operable in 
the DNS, like delegating to localhost, DNAME'ing to AS112, assigning a 
pseudo-random DS for which there is no corresponding DNSKEY, &etc. if 
queries in DNS for names ending in .ALT are proof of misconfiguration, 
then the result of those queries can be arbitrary, and should optimize 
for the health of the DNS rather than the utility of the misconfigured.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

David Conrad wrote on 2022-10-23 12:00:

Rob,


not rod, but i have three comments.

On this mailing list, I think there is a pretty good understanding of 
the intent of .alt and I don’t think there is much in the way of 
disagreement on that intent. As far as I can tell, the points of 
contention are:


1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name 
resolution systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those 
issues.


first, +1 to the above and to the elided text formerly below.

second, it's worth a bit of puttering to figure out how to prevent more 
pollution (queries of non-DNS namespaces or non-global-DNS namespaces) 
from hitting the root. delegating .ALT the same way 10.in-addr.arpa is 
delegated (prisoner.iana.org and so on) may be a fine idea.


third, in recognition of this concern:

... 

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS 
name resolution protocol is specified to not be plain text (presumably 
any new protocol would be encrypted), then users of that protocol have 
an expectation that their queries are protected.  ...


implementation guidance contained in the .ALT "specification" should 
include the need to detect ".ALT" from the right hand side before 
deciding whether or not to do special non-DNS processing on the 
remaining left hand side. this is because the non-DNS syntax on the left 
hand side might include .ALT for other reasons, or may use "." 
differently than DNS would do. this is messy but inevitable given that 
DNS camped on to the entire domain namespace in its earliest days.


--
P Vixie

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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Paul Vixie]

Martin Schanzenbach wrote on 2022-10-23 04:38:

On 23.10.22 10:50, Suzanne Woolf wrote:

...

The chairs would like to hear it if anyone has anything new to say about such a 
registry on its technical merits, including specific registry policy and 
operational challenges with administering it if the non-technical risks could 
be managed.


i think everything has been both said and challenged. my own position 
hasn't evolved, and it's short so i'll summarize it here:


* first come first served
* same character set rules as DNS
* IDN is not disallowed
* short RFC to name the codepoint and refer to the carve-out's naming system
* administered by IETF not ICANN
* IANA to maintain a registry
* allocation cannot be denied

but, read on:

Martin Schanzenbach wrote on 2022-10-23 04:38:

In my opinion lots of technical justifications were given in the various
threads and those were not really addressed or refuted in any way but the
mentioned "non-technical risks" and "out of scope for dnsop" highlighted.
At the same time it appears to me that those risks do not (?) seem to manifest
themselves for .arpa. Is there an explanation or an indication why this would be
the case for .alt?


quoting suzanne's message to which the above text is a reply: >


those were bad times. green papers, lawyers, oh my. noone who lived 
through the years of contention over who would control the root zone and 
how is going to be easily dragged back into it. in today's equilibrium 
the decision to allocate TLD codepoints rests with ICANN. so to get 
".ALT" it will be nec'y to assert IETF's authority on the basis that 
this is a reservation not a delegation. it can be done (in my opinion) 
but nobody wants to bell that cat. getting ICANN to create and adopt a 
policy for reservation would be much harder. putting this under ".ARPA" 
would be much easier.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Martin Schanzenbach wrote on 2022-10-23 04:34:

...
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?


yes.


It is as if we are chasing a moving target where the primary point of
contention always seems to escape us. The goalpost seems to be moving.


building a standards and innovation community out of humans has 
predictable downsides.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

see inline.

Brian Dickson wrote on 2022-10-21 14:17:



On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie <mailto:p...@redbarn.org>> wrote:


...
can you say more about why you think this? (what incompatibilities
lurk?)


The different anchor points are (would be?) tied to different purposes, 
intended behavior for namespaces and resolvers (including leaked 
queries), and relatively low level-of-effort for DNS-friendly 
experimentation.


ah.



So, my read on the general sentiment is:

  * "alt" => not DNS, or at least not DNS-friendly, including has DNSSEC
preventing resolution via validating resolvers.
  * "alt.arpa" => extending DNS without conflicting with existing
ICANN-regulated namespaces, is DNS-friendly, has DNSSEC unsigned
delegation point included (so won't be made unuseable when slightly
modified validating caching resolvers are involved)



i only care about the first bullet-point above. extending DNS may be 
important but it's not the same as the carve-out i am looking for.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Joe Abley wrote on 2022-10-21 13:51:

On Oct 21, 2022, at 12:52, Paul Vixie  wrote:


it's a registry of carve-outs for use inside DNS, which happens to facilitate 
client development by giving agents such as browser plugins a clear activation 
signal that's unambiguous with respect to the DNS.


...

In that context, what we are talking about is defining a carve-out from the 
namespace that is not for use by the DNS, but instead intended for other naming 
systems.


+1.

--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Brian Dickson wrote on 2022-10-21 12:42:



On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie 
<mailto:40redbarn@dmarc.ietf.org>> wrote:


...

it's not a fight, and the internet standards community should
facilitate such carve-outs whenever possible.

...

I think your suggested carve-out would need a different anchor point in 
the DNS namespace, ...

can you say more about why you think this? (what incompatibilities lurk?)

--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

see inline.

Wes Hardaker wrote on 2022-10-21 09:09:

Joe Abley  writes:


Normally, a registry is created when it will help the operation of
the protocol.  The problem here is that there's an _anti_-protocol,
and therefore it's mystifying to me how a registry helps anything,
since there is no way to know whether a registry will actually help
or in some cases even hurt.


Yes. This.


-1.


To put this another way: the proponents of the currently active non-DNS
naming systems are creating these systems with an active desire to avoid
a centralized form of control over the name space they're creating.  And
by having a registry, it would re-insert some level of control that
they're explicitly fighting against.
it's a registry of carve-outs for use inside DNS, which happens to 
facilitate client development by giving agents such as browser plugins a 
clear activation signal that's unambiguous with respect to the DNS.


it's not a fight, and the internet standards community should facilitate 
such carve-outs whenever possible.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-03.txt

[Paul Vixie]

On Tue Sep 13, 2022 at 2:03 PM UTC, Ralf Weber wrote:
> > On Tue, Sep 13, 2022 at 7:18 AM Petr Špaček  wrote:
> >> Speaking with my BIND hat on, I would prefer Informational.
> >>
> Here we go. I fully support what Petr said. Initial (very cold cache)
> DNS resolution only works from the parent down and usually is way faster.

having implemented and operated this recursive server logic over many years,
i can assure you that its cold-cache performance is broadly unremarkable.

> As you may recall I did not support adoption of this draft because of
> the same concerns initially and my stance has not changed. So if this
> becomes and RFC it can’t be more then informational or experimental.

it mustn't be required but also must be permitted. that does place a
constraint on the protocol's future evolution. so it's possible that
neither "informational" or "experimental" are strong enough. i think
if the document states that the feature is optional for implementors
and operators, then its status could be proposed standard, safely.

vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-03.txt

[Paul Vixie]

On Tue Sep 13, 2022 at 1:47 PM UTC, Tim Wicinski wrote:
> >
> This is good feedback, and it helps us.  We should also hear from
> other implementers about their opinion on this.

in an unreleased recursive name server, all parts of resimprove were 
implemented as of 2005 or so, which is what led to the publication of
the original resimprove draft a few years later. i don't think this
qualifies the authors and operators of that software as "implementers"
as used in the above request, but if so, let me say i don't need it to
be mandatory. see also my reply up-thread speaking as a draft co-author.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-03.txt

[Paul Vixie]

On Tue Sep 13, 2022 at 11:17 AM UTC, Petr Špaček wrote:
> On 07. 09. 22 3:28, internet-dra...@ietf.org wrote:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
>
> I wonder about this Datatracker line:
>
>   Intended RFC status (None)
>
> What do authors plan, or WG leans to?

it was originally part of resimprove which at the time was intended to be
non-modifying for the protocol. the important part NOW is that this behaviour
should not be undercut by subsequent protocol changes. for any implementation
it would be treated as an optional feature, and for any operator is should
be something they can turn on or off according to their local policy.

> Speaking with my BIND hat on, I would prefer Informational.
>
> Protocol in this draft is pretty complex, and so far the sky did not 
> fall despite resolvers not implementing it.

i think the sky cannot fall in the way you imply, and that it has in fact
fallen regularly in the eyes of the security community. i am aware of at
least one "public dns" system with a semi-unpublished API allowing cache
invalidation, because by default DNS caching works too well. it is very
much necessary that the system as a whole offer standardized signalling
for system-wide "rm -rf $zone", because private API's and pairwise trust
relationships have not scaled and their existence puts pressure against
independent (non-"public") recursive dns implementation and operation.

> Based on this observation I think it should not be mandatory, and also 
> that parent-centric DNS resolver implementations should not be 
> "outlawed" by this (to-be) RFC.

i don't object to either non-mandatory or non-conflict. however, as i wrote
above, i'd like this document to cement the system level capability of this
feature. for example if i find a zone authority server who will not give a
delegation response when queried at a delegation point because its
implementor or operator believes that NS RRs are not necessary for correct
system operation, i don't want to have to work around it by asking for a
random subdomain name under the delegation point. rather, i want to be able
to report it to the dns-violations github site.

hopefully this overlaps with your world view.

vixie

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Paul Vixie]

Schanzenbach, Martin wrote on 2022-08-22 12:17:


So maybe Unicode provides sensible guide lines for acceptable strings under 
.alt _for the registry_?

just... no. if somebody wants to put binary gibberish "under" .ALT, in a way 
that browser plugins never get to see because it's not valid unicode, that is _their 
problem_. we can state implications, nothing more.


I agree. It is just unclear to me how the registry itself would support this. I 
am no IANA registry expert. But if any byte string is theoretically allowed as 
a 2LD, then how would this look like?


i totally misunderstood you. for the 2LD, it has to be a name that the 
IETF is capable of registering, which means it has to be a label that 
would be legal under dns. for 3+LD, binary gibberish would be allowed, 
implicitly, by the specification's silence on that matter.


my apologies for not realizing what you were proposing.

--
P Vixie

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Paul Vixie]

Schanzenbach, Martin wrote on 2022-08-22 11:24:




On 22. Aug 2022, at 20:15, Paul Vixie  wrote:
...
noting: by describing this as a reserved name subspace, we implicitly expect that the 
presentation form of any namespace thus enabled will be "compatible enough" 
with DNS presentation form to allow the reservation keyword (.ALT) to be entered or 
displayed, and detected. we can in the specification for the subspace reservation even 
state that implication. however, if someone wants to go rogue on that, we shouldn't try 
to stop them. (as if we could.)


But I also think that if it is expected that name systems may "go rogue" e.g. use a new 
innovative new string encoding, then the registry might have trouble listing/registering the 2LD 
"byte string" chosen by the name system?


that's not our problem. we're reserving part of the namespace, and 
that's all. if someone wants to use it in a way that fails, that's 
totally their affair.



So maybe Unicode provides sensible guide lines for acceptable strings under 
.alt _for the registry_?
just... no. if somebody wants to put binary gibberish "under" .ALT, in a 
way that browser plugins never get to see because it's not valid 
unicode, that is _their problem_. we can state implications, nothing more.


--
P Vixie

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Paul Vixie]

Schanzenbach, Martin wrote on 2022-08-22 11:02:

...

On 22. Aug 2022, at 19:07, Ray Bellis  wrote:
...
On 22/08/2022 15:05, Paul Hoffman wrote:

...

I do not see why names under .alt must be compliant standard DNS names for any 
reason.


+1.

noting: by describing this as a reserved name subspace, we implicitly 
expect that the presentation form of any namespace thus enabled will be 
"compatible enough" with DNS presentation form to allow the reservation 
keyword (.ALT) to be entered or displayed, and detected. we can in the 
specification for the subspace reservation even state that implication. 
however, if someone wants to go rogue on that, we shouldn't try to stop 
them. (as if we could.)


--
P Vixie

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[Paul Vixie]

Vladimír Čunát wrote on 2022-08-21 11:30:

On 19/08/2022 20.06, Paul Wouters wrote:

Security Considerations could say that .alt queries MUST NOT be
forwarded to other DNS servers for resolution.


There's a dilemma with SUDNs.  If a resolver isn't allowed to "send the 
name upstream", it might not be able to return DNSSEC-correct denial.  
While it's often fine to return a forged bogus answer, it's certainly 
not a perfect setup.  For example, with validators that don't support a 
SUDN yet forwarding to resolvers that already supports that SUDN - 
generating retry loops and eventually SERVFAILs.


the design effectively avoids that condition. a stub or recursive who 
knows about .ALT won't forward the query or recurse. one who does not 
know will forward or recurse and get a secure denial of existence which 
will be cacheable. if it's a recursive and also implements qname 
minimization then the nonexistence of .ALT and all subdomains will be 
cacheable. if it implements DNSSEC and its forwarder if any also does, 
then the cached negative .ALT signal will be authenticated.


--
P Vixie

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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Eliot Lear wrote on 2022-08-18 13:11:

...

I could see the value in reserving dns.alt, and the potential mischief 
that could ensue by not doing so.


that way lies madness. let the FCFS process and technical review include 
space for objecting to the requested 2LD label.


--
P Vixie

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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Stephen Farrell wrote on 2022-08-18 12:43:


Hiya,

On 18/08/2022 20:26, Paul Vixie wrote:
i don't think the .ALT draft is going to move forward without such 
change, so the distinction will be between .ALT as proposed and .ALT 
as evolved, not between .ALT and some other SUDN.


I think I agree. But to check: are we saying that the .alt
I-D ought be changed (possibly outside dnsop) so that there's
an IANA registry for one level of name beneath .alt with "RFC
required" as the requirement for adding an entry? (So those
RFCs could come from the IETF, IRTF, ISE etc. at present.)


i don't know (nor do i suspect) (for or against) that it would have to 
occur outside of dnsop. we are the catch-all wg for dns nowadays; 
anything not delegated elsewhere (like dprive) seems to come here.


and i don't know whether warren agrees with the 2LD.ALT vision. as the 
author of the current .ALT draft his opinion should matter to us.


--
P Vixie

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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ben Schwartz wrote on 2022-08-18 12:11:


On Tue, Aug 16, 2022 at 10:15 PM Schanzenbach, Martin wrote:

 > ...

That is exactly why IMO the namespaces under .alt must have a
technical merit and this merit gives the protocol a shot at a (or a
few based on the technical design) (free) name under .alt.
It should not be possible to get such a name in the registry without
a technical justification (e.g. a spec that proposes a new way of
doing name resolution). No political or policy considerations necessary.
And this is why there must be a registration policy and process.

What you are describing does not resemble draft-ietf-dnsop-alt-tld, 
which would define the "alt" SUDN.  That document says:


    There is no IANA
    registry for names under the ALT TLD - it is an unmanaged namespace,
    and developers are responsible for dealing with any collisions that
    may occur under .alt.

If you want a SUDN for technically meritorious non-DNS names, perhaps 
you should distinguish that proposal from .alt.


i don't think the .ALT draft is going to move forward without such 
change, so the distinction will be between .ALT as proposed and .ALT as 
evolved, not between .ALT and some other SUDN.



This merit needs to be established, yes. And I think it should be
done through review by the IETF or the ISE.
And yes, there is a reason why this sounds a bit like a RFC6761
SU-TLD, because the motivation makes sense to me.

In this case, the path forward is clear: propose GNS as a 
standards-track RFC, proceed through to publication, and use the RFC 
6761 process to claim a SUDN for it. ...


we're not "in" that case. RFC 6761 is in abeyance, its merits having 
been widely questioned. many RFC's sneak through and this was one.


Publication of a standards-track 
RFC is the IETF's sole mechanism for indicating support for the merit of 
a technical proposal, and is also the threshold for use of RFC 6761.


However, if the IETF does not have consensus to adopt GNS as a standard, 
then it is difficult to see why the IETF would allocate a portion of the 
namespace for it.


that whole model is unworkable, and i expect the .ALT document to 
replace RFC 6761. IETF needs different powers than those now described.


--
P Vixie

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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Brian Dickson wrote on 2022-08-17 16:56:



On Aug 17, 2022, at 3:12 PM, Timothy Mcsweeney  wrote:
...
More importantly this proposal now sounds like an non-DNS un-restricted naming 
scope which puts it out the DNSOP charter right?



It is the boundary between DNS and non-DNS, both technically and semantically.
The DNSOP part is the specific name and request to IANA/ICANN to ensure it is 
enshrined as not just not existing, but so that it will never exist (in the 
ICANN root zone).

Once that is done, what it gets used for etc is then out of scope. It is like 
an escape clause.
...


+1.

--
P Vixie

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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-17 08:01:


On 17/08/2022 15:56, Timothy Mcsweeney wrote:


...


I believe the intention was that the DNSSEC nsec records in the root
zone would deny that .alt exists, helping to enforce separation from the 
"DNS protocol namespace" and anything under .alt.


+1.

--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Paul Vixie]

Hugo Salgado wrote on 2022-08-16 14:19:

Dear authors.
In the second paragraph of section 3 "Upgrading NS RRset Credibility"
there is a mention of "Positive responses...", which I am not sure of
its exact meaning. Do you mean ANSWERS>0? Or AA=1?


i think if the text were "positive responses" then your question would 
be a nonsequitur, but the actual text i see is "positive answers" which 
does indeed raise your questions.



I'm thinking of a (broken) nameserver that responds to NSs queries with
NXDOMAIN (but does answer to other types)[1]. Is that a positive
response, which should be cached with an authoritative data ranking?


i think we're sending an RD=0 question to a server we think is the 
closest enclosing delegator for the zone we are revalidating, and that 
it has to answer AA=0 (because it is a delegated name) with an RRset of 
type NS, or else it's nonresponsive. i leave it to my coauthors to find 
a way using only english words to best express that constraint.


thanks.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Paul Wouters wrote on 2022-08-15 13:22:

Schanzenbach, Martin wrote on 2022-08-15 11:49:

 ...
 So, from my authors hat, I would appreciate FCFS; ideally also existing
 RFC/Other Specification + Implementation(s) for a registration in the
 registry.


"existing RFC" means all alternative name resolutions have to flow
through either the IETF or ISE. That is not something the IETF would
want to take on I think.


i think otherwise. the IETF exists for the purpose of supporting this 
kind of thing. IANA has to have a higher power to tell it about code 
point assignments. what we don't want, most of all, is to introduce a 
new such authority.


david's read of the timeline is that ICANN has responsibility for the 
whole domain style naming space, and by that interpretation the .ALT 
question would be theirs to grapple. i disagree for many reasons which i 
fear will have to be discussed before this is over, but, not today.



"Other specification" would likely lead to many copy & paste drafts
based on the first draft that is used to get an entry in .alt, with
only the name changed.


i think we should be fine with that; we're enabling it not managing it.


Meanwhile, IANA will have to host 60M entries in the .alt registry.


that would be a success disaster, and self limiting. to get traction, a 
new non-tcp/53 non-udp/53 would have to publish plugins for a lot of 
browsers and get uptake by libcurl and other places. that won't happen 
60M times. in fact long before the natural limits of deployment kicked 
in, the natural limit of namespace pollution would remove the incentive.


in any case the worst case if we do a carve out is a lot better than the 
worst case if we don't, so the details beyond that aren't important.



I guess we could prevent draft--alt-name-cocacola if we consult the
Trademark Clearing House, but maybe this is a clear signal that we
are turning the IETF into ICANN and it is time to take a step^Wleap
back.

The IETF cannot bear the burden of managing or policing a non-IETF
namespace war, even handling a FCFS registry will take too many
resources.


i had this exact conversation with bob moskowitz some decades ago and he 
considered trademarks to be a full-tree issue. i then created host names 
for a computer lab which duplicated each and every one of his employer's 
trademarks (which were i think automobile names) and invited a lawsuit.


coca-cola.alt is not different in its trademark relevance from 
coca-cola.example.com or coca-cola.gns.alt. we're not going to 
differentiate, and i predict we're not going to let it stop us any more 
than we would or could prohibit an IPv6 address ending in ::c0ca:c01a.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Schanzenbach, Martin wrote on 2022-08-15 11:49:

...
So, from my authors hat, I would appreciate FCFS; ideally also existing 
RFC/Other Specification + Implementation(s) for a registration in the registry.


+1.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 11:25:



On 15/08/2022 19:17, Paul Vixie wrote:


of course i meant that each such namespace would get its own
"sub-domain" under .alt (e.g., .GNS.ALT).


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...


if there's a market for it (some way that lots of somebodies can make or 
save money or both) that too shall come. but that's not _our_ (IETF or 
DNSOP)'s worry.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 11:08:

On 15/08/2022 18:55, Paul Vixie wrote:


...
if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. 
that helps me understand the open ended _effective_ intent of STD-13, 
which is to build roads not walls -- in the best tradition of the 
Internet.

...


I have no problem with ".alt" being carved out like that, it's the 
potential proliferation of a multitude of such carve-outs that bothers me.


i think all of us have been squeamish about proliferation of carve-outs, 
which is one reason Jon Postel gave me when i asked him in ~1985 for a 
carve-out for .UUCP -- and while i disagreed at the time i have come 
around to his point of view on the matter.


I also suspect that those specs that need it will in pratice be unable 
to co-exist unless each such namespace then gets its own "sub-domain" 
under .alt (e.g. .gns.alt).


of course i meant that each such namespace would get its own 
"sub-domain" under .alt (e.g., .GNS.ALT). according to david, these 
won't lead to a "land rush" because it would look like a "naming 
ghetto". i'm not concerned about lack of popularity, only whether we 
(IETF) have supplied some mechanism for domain style naming evolution. 
if someone later comes up with a better mechanism we can consider it. we 
need "something" and warren's .ALT draft is "something".



...
Maybe there'll be an opportunity for having "real" domain names that 
effect a namespace switch via a DNAME or CNAME record into .alt? ;)


i think that's inevitable, and i expect to see development of a new RR 
type which can be placed at the apex of "example.com" telling some 
parameters for use of a .EXAMPLE.ALT "sub-domain". the IETF is not the 
protocol experimentation police unless some definite prediction of harm 
becomes the consensus. DNSOP in particular has an "if you want to do 
this, here is one way" rubric for its work. (see EDNS Client Subnet.)


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Eliot Lear wrote on 2022-08-15 07:41:

...

On 15.08.22 16:11, David Conrad wrote:

...

We have no idea whether GNS will take off in popularity or fade away 
into non-existence. Given the way "configuration is forever”, any 
partitioning of the namespace will be a feature for the foreseeable 
future.


agreed, tails are long. that's why my analysis included guesses at the 
best and worst possible impact of reserving part of the domain style 
namespace for non-udp/53 non-tcp/53 purposes. given other code point 
reservations present in the udp/53 tcp/53 world, this one can at worst 
be harmless to the things IETF is responsible for evolving, and could be 
beneficial to things the IETF is not responsible for evolving. so, QED?


I agree.  We shouldn't bet the Internet name space on something 
failing.  What I like about .alt (or whatever we end up calling it) is 
that it requires a single or small number of changes, not one change per 
name space.  That will help reduce leakage.


+1. noting, there should be a registry of second level domain style 
names, maintained by IANA, with an RFC for each one describing what 
protocol (whether Internet or otherwise) is used for names in that 
"sub-tree", and references to permalinks where the non-tcp/53 non-udp/53 
system is further described. ("build roads not walls.")


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 10:14:



On 13/08/2022 23:56, Paul Vixie wrote:


it's very much worth re-reading RFC 921 and RFC 952 to understand ...


STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire 
protocols for interrogating that system, mostly surplanting the use of 
host files.


On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name 
System" namespace from the STD-13 one embodied in the ICANN-managed root 
zone that we have now.  I think they're the same thing.


your well chosen words ("effectively", "de-facto", and "mostly") are 
important here. it was neither expected not desired that /etc/hosts 
(which many of us autogenerated from HOSTS.TXT and added our local names 
thereto) or YP/NIS or any other non-udp/53 non-tcp/53 name-to-address 
translation capability would go out of use. indeed, there has Never been 
a day since "domain style names" were first described when non-udp/53 
non-tcp/53 naming systems systems were Not in wide use.


effectively + de-facto = 0 in this timeline. mostly > 0, to be sure.

if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that 
helps me understand the open ended _effective_ intent of STD-13, which 
is to build roads not walls -- in the best tradition of the Internet.


--
P Vixie

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

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

[Paul Vixie]

Jim Reid wrote on 2022-08-14 05:16:

...


thanks jim for upleveling this; i hadn't noticed it previously.


On 14 Aug 2022, at 04:55, Wes Hardaker  wrote:

Something like:

# Deprecating SHA-1 algorithms in DNSSEC

The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records.
Validating resolvers MUST treat DS records as insecure.  If no other DS
records of accepted cryptographic algorithms are available, the DNS
records below the delegation point MUST be treated as insecure.


wes, i think the language of RFC 4034 is better than "must treat as 
insecure". here's the text i mean:



5.2.  Processing of DS RRs When Validating Responses

   The DS RR links the authentication chain across zone boundaries, so
   the DS RR requires extra care in processing.  The DNSKEY RR referred
   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
   used in the validation process.


to follow this example the final sentence ("if no other...insecure") 
would read as follows:


"A DS RR having an SHA-1 digest field must not be used in validation."

...because "must treat as insecure" doesn't have the same edge cases.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

David Conrad wrote on 2022-08-13 18:55:

Paul,

On Aug 13, 2022, at 3:32 PM, Paul Vixie  
wrote:

i suggest that we adopt the technology "domain names (which is a concept that 
precedes DNS itself)" whenever we are trying to talk about the name space as 
distinct from the protocol.


Sorry, which technology are you suggesting we adopt?  Or did you get 
auto-corrected from “terminology”?


oops. yes.


ideally the domain name system would have left a carve-out for domain names that were not 
expected to be served through the first such "domain name system", but were 
rather reserved for future domain name systems.


The domain name namespace (labels separated by dots) is obviously agnostic to 
how it is implemented. The problem isn’t that parts of the namespace can’t be 
reserved: anything can be reserved for anything, regardless of protocol (see 
.ONION or .LOCAL).  The problem is that every resolver implementation and 
deployment on the Internet, which assumes anything that looks like a domain 
name IS intended for the DNS, has to be modified to “do something different” 
when it sees that reservation and failure to do so mean the name is going to be 
looked up via the DNS.


that's a problem for future innovators. many resolvers look for 
domain-style names in other places than DNS (/etc/hosts, YP, etc). i 
think the point of a carve-out is to let people try things. how those 
people get broad adoption for their ideas is not the IETF's immediate 
concern.





by camping onto the whole of the domain name space, DNS (the domain name 
system) has blocked research into new naming systems.


It didn’t block research into overloading the domain name namespace into 
protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, Butterfly, 
etc., all demonstrate), it made it unscalable because of conventions of 
operating system vendors and application developers and assumptions of users.


if by unscalable you include the idea that if someone experiments with 
.XXX they run the risk of having IANA later allocate that to some unique 
purpose, then i agree with your use of that word.





warren's .ALT proposal can begin to undo that harm. internet standards should 
describe roads not walls. i am no fan of blockchain naming, but i'd like those 
systems to reach the market rather than be prevented from doing so.



Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And you 
also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
address the markets they’re trying to address? I’m not against moving forward 
with .ALT, but I’ll admit some skepticism that it will work as intended: it 
feels to me that it’s more an exercise in “if you build it, they will come” but 
without James Earl Jones.


i think GNU would use it. others can decide what to do. the worst case 
risk is low, the best case benefit is high. so, to be clear, "yes".




As John Levine points out, this isn’t a technology issue: it is 
social/politica/economic/bureaucratic. ...


i'm aware of legal matters which could pertain, but i am not IETF's 
lawyer so will not seek to advise them. what matters as an engineering 
question is that the domain name system camps onto the whole of the 
domain-style / hierarchical / structure space of names, and this was an 
error, and a carve-out is needed to facilitate innovation.




Regards,
-drc

yours always,

--
P Vixie

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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Paul Hoffman wrote on 2022-08-13 15:42:

On Aug 13, 2022, at 3:32 PM, Paul Vixie  
wrote:

i suggest that we adopt the technology "domain names (which is a concept that 
precedes DNS itself)" whenever we are trying to talk about the name space as 
distinct from the protocol.



The term "domain name" is already defined in RFC 8499. If you don't like that 
definition, please suggest changes that will find consensus in the WG.


i'm not going to lawyer this. if you prefer that we use the term 
"domain-style" (RFC 952) or "hierarchical names" (RFC 921) or 
"structured names" (RFC 921 again), i'll do it, but others might not. to 
communicate effectively requires not only a dictionary but the knowledge 
that one's listener may have a different one. in any case the confusion 
will remain no matter what term is used unless the additional text 
("which precedes the domain name system itself") is added to every such 
reference.


if you're willing to lawyer this, let me know how i can help.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

see inline.

Warren Kumari wrote on 2022-08-11 10:20:

Warren’s meta-comment -[ Please read this ]-


thanks for this, it was marvelously clarifying. i have a quibble which 
might best be taken as a potential warning. but first, let me emphasize:


TL;DR: Domain names are older than the DNS protocol and have always been 
used in multiple contexts. DNS naming conventions and protocol are by 
far the most widely used naming system in the public Internet, and have 
provided an extremely useful naming space default for Internet hosts and 
users. ...


it's very much worth re-reading RFC 921 and RFC 952 to understand how it 
was that domain-style names (an RFC 952 term, which RFC 921 described as 
"structured names" or "hierarchical names") preceded what we today call 
the "domain name system." we ought to have built in a carve-out for 
domain-style / hierarchical / structured names explicitly known to not 
be part of the domain name system. it's not too late; see warren's draft 
for a way to fix in 2022 what we broke in 1984.


https://www.ietf.org/id/draft-ietf-dnsop-alt-tld-15.html

i think a lot of us in the 1980's didn't realize that connectivity would 
never be end to end, and that concentric rings of connectivity would 
always exist, and that no universal naming system could encompass it 
all, but that one universal name space absolutely could do so if 
properly future-proofed.


... So, I withdrew my request for presentation time, but I *am* still 
planning on organizing a group to try and get some better focused 
discussions on this entire topic.  So, watch this space!


fingers crossed -- sign me up!


--


now for my quibble, which might be taken as a warning.


FAQ - Namespaces (please also see the meta-comment at the top of this email)
---
1:
...  It also
needs to work with existing applications, like 'ssh' and 'ping' and 
browsers and anywhere else you can realistically expect a name to show 
up ...


it does not. the dns is overwhelmingly used to reach web services, 
whether those are "sites" or API's. the web community eventually lost 
confidence in the evolution of Do53 and pushed DoH and now DoQ, just as 
thry lost confidence in the evolution of TCP and pushed QUIC. if that 
community loses confidence in the evolution of DNS and pushes some new 
web-only naming system, they may succeed but if they fail it won't be 
because of shell commands like ssh or ping. in fact it's more likely 
that shell-containing systems will add support for "W3NS" or whatever.


we must be responsive to the community of interest, or risk losing it.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Peter Thomassen wrote on 2022-08-13 13:36:

On 8/13/22 15:26, Paul Vixie wrote:

...

we don't need new terminology ("dotted names") to talk about domain 
names, which are older in concept and implementation than the dns is.


Sure, you're right. I used "dotted name" here only to prevent that when 
I write "domain name", people will think "DNS name". I think that's a 
common mix-up.


i suggest that we adopt the technology "domain names (which is a concept 
that precedes DNS itself)" whenever we are trying to talk about the name 
space as distinct from the protocol.


ideally the domain name system would have left a carve-out for domain 
names that were not expected to be served through the first such "domain 
name system", but were rather reserved for future domain name systems. 
if we'd known at the time that IP was going to beat OSI we'd've planned 
better? i know a lot of us would have liked YP/NIS to have been able to 
live inside YP.ALT or some such. similarly for XNS and DECNet and OSI 
and AppleTalk and so on.


by camping onto the whole of the domain name space, DNS (the domain name 
system) has blocked research into new naming systems. warren's .ALT 
proposal can begin to undo that harm. internet standards should describe 
roads not walls. i am no fan of blockchain naming, but i'd like those 
systems to reach the market rather than be prevented from doing so.


But I did not mean to introduce new terminology. The point of my message 
was that I disagree with
People have projects outside the DNS and want to name them with DNS 
names.


thanks for making that clear. introduction of the new term "dotted 
names" was a distraction from your intent.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Peter Thomassen wrote on 2022-08-13 09:23:



On 8/13/22 11:57, John R Levine wrote:

...


It's not a technical problem, it's a social or political one.  People 
have projects outside the DNS and want to name them with DNS names.  
Sometimes you can't have what you want.


The issue is *precisely* that they want dotted *names*, *not* DNS names, 
but there is overlap in namespace.


warren explained this. domain names are older than the dns. hosts.txt 
had them. to be a "domain" name just means it has hierarchy in that each 
name is within some domain of other related names. sri-nic.arpa was a 
domain name. its parent domain was arpa. all of this preceded the dns.


what people want is domain names. right now dns camps onto the whole 
space of domain names, because it expected to be the last and final 
deliverer of domain names. it's called the "domain name system" after all.


dns should decamp from some part of the domain name space, so that 
naming research using domain names can continue beyond dns. warren 
explained that this was his goal with the ".alt" name reservation.


we don't need new terminology ("dotted names") to talk about domain 
names, which are older in concept and implementation than the dns is.


--
P Vixie

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

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Vixie]

Paul Hoffman wrote on 2022-08-08 06:31:

On Aug 8, 2022, at 3:16 AM, Independent Submissions Editor (Eliot Lear) 
 wrote:


...


draft-ietf-dnsop-alt-tld and SAC113 would give the authors of the draft you are 
considering an easy method to do the type of naming they talk about in their 
draft. So would using a TLD that is exceptionally unlikely to be allocated in 
the global DNS, such as:
   #gns
   =gns
(or, for a more marketing spin)
   gns!

These are all perfectly valid names; they just happen not to use the LDH 
pattern that people expect from the global DNS.


it's possible that web browsers could try these names using their 
gethostbyname() path, and if the system library (or more likely the 
browser's runtime) understands what these mean ("don't use DNS") then 
happiness could result. however, there are a lot of different systems 
each with its own library, and a lot of different browsers each with its 
own runtime. so adoption will be arduous.


i think the ietf could define a new namespace which included the dns 
namespace as a component. this new namespace would probably have to be 
administered by icann, since ietf isn't going to want to negotiate with 
every new "alternative namespace" provider. such a new namespace could 
be differentiated with some kind of syntactic element such as #, =, or ! 
as given above.


i also think icann could define a new namespace which was included 
within the existing dns namespace, but probably not with an unmarketable 
name like ".alt" or ".arpa". let's instead imagine that it was ".ext" 
for "extensions" and that each namespace provider could get a name 
reservation and even a delegation point (".gns.ext") if they wanted by 
petition, contract, and payment to icann.


experimentation in namespacing is frozen, and we won't evolve beyond the 
concepts which gave rise to DNS unless we decide where it will fit in. 
that's a vital problem, regardless of the merits of any single proposal.



If the GNS team indeed wants to make it clear that their naming is not part of 
the global DNS, simply rooting their names in one of these TLDs (available now) 
or one of the ones from draft-ietf-dnsop-alt-tld or SAC113 (possibly available 
in the future) would avoid all of the interoperability problems they create in 
the draft.

+1.

--
P Vixie

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