[DNSOP] Idea/suggestion on refs

[Brian Dickson]

One of the potential challenges for RFCs is references to works-in-progress or 
other less-than-stable items (URIs).
Here is my thought: would updating those be something that could be handled by 
errata rather than doing a -bis?
Brian
Sent from my iPhone
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] DNS Grease?

[Brian Dickson]

On Wed, Apr 24, 2024 at 3:19 PM David Schinazi 
wrote:

> I see, thanks for clarifying. So this proposal would require every
> implementation that chooses to ever deploy a new codepoint to implement
> this new extension, for all eternity. That seems brittle to me, as things
> would break in the presence of a single lazy implementer. What made GREASE
> viable was the fact that it only takes work from one popular implementation
> to create herd immunity, even if all other implementers are lazy. I don't
> think it would have been viable otherwise.
>

I disagree with that characterization.

I see the EDNS grease thing as more of a "belt and suspenders" thing,
making it more reliable, versus being a prerequisite for grease testing.

We already have at least one, and probably several, codepoints that all
implementations need to implement for all eternity. Not all of them are
obvious or commonly known, but they are definitely present (AIUI).
A couple of examples off the top of my head:

   - EDNS (for DNSSEC)
   - DNAME support (for DNSSEC)

Brian


> David
>
> On Wed, Apr 24, 2024 at 2:59 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Apr 24, 2024 at 2:28 PM David Schinazi 
>> wrote:
>>
>>> If I understand your proposal correctly, this would require the receiver
>>> to support this new EDNS option in order to properly remove values that the
>>> sender thought were unused but that the receiver did not. Such a
>>> requirement on receivers makes it impossible for the sender to know it can
>>> safely GREASE, because the sender has no way of knowing that the receiver
>>> supports this new EDNS option. In general, the idea behind GREASE is that
>>> any sender can use it without requiring any changes on the receiver.
>>>
>>
>> Not exactly, at least I don't think so.
>>
>> The presumption would be at some point in time, new code points are
>> deployed. If the "grease" specific thing were well publicised, and new code
>> points referenced it, it might be possible to infer that newer code points
>> are deployed only if they are covered in grease.
>> And conversely, code points prior to the EDNS grease thing would not be
>> covered in grease.
>>
>> Thus, senders using grease would be able to know that either a code point
>> was free to use for grease operations (because the receiver does not return
>> the grease EDNS thing), or that the grease coverage facilitated flagging of
>> code points subsequent to the EDNS grease thing.
>>
>> It's kind of like a flag day, but more of a soft opening, i.e. a
>> dependency situation.
>>
>> Brian
>>
>>
>>>
>>> David
>>>
>>> On Wed, Apr 24, 2024 at 2:09 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque  wrote:
>>>>
>>>>> Thanks for your comments David. I hope it will progress too, and good
>>>>> to hear that that grease worked well for TLS and QUIC.
>>>>>
>>>>> On random vs reserved values, we do intend to propose some reserved
>>>>> ranges (there is a placeholder section in the draft for this already). And
>>>>> then try to have a debate about the pros and cons (e.g. is reservation 
>>>>> just
>>>>> going to cause middleboxes to treat the greasing range specially, etc). 
>>>>> For
>>>>> the larger fields, yes, we could allocate larger reserved ranges and pick
>>>>> randomly from those. For the smaller fields (that accommodate just a
>>>>> discrete set of flags, rather than a number), we could reserve just a 
>>>>> small
>>>>> handful of flags. For any proposal that uses purely random unallocated 
>>>>> code
>>>>> points, I think we'd need software to have pre-configured (or 
>>>>> configurable)
>>>>> end-of-test dates as one way to avoid future interoperability issues.
>>>>>
>>>>> Even for the larger ranges though, there is a more granular
>>>>> classification (such as data vs meta vs q-types in the RR-type space) 
>>>>> where
>>>>> more nuanced treatment is needed, such as defining multiple reserved 
>>>>> ranges
>>>>> and expecting distinct response behavior for each.
>>>>>
>>>>
>>>> I have an idea, which may or may not be useful, for avoidance of
>>>> testing ran

Re: [DNSOP] DNS Grease?

[Brian Dickson]

On Wed, Apr 24, 2024 at 2:28 PM David Schinazi 
wrote:

> If I understand your proposal correctly, this would require the receiver
> to support this new EDNS option in order to properly remove values that the
> sender thought were unused but that the receiver did not. Such a
> requirement on receivers makes it impossible for the sender to know it can
> safely GREASE, because the sender has no way of knowing that the receiver
> supports this new EDNS option. In general, the idea behind GREASE is that
> any sender can use it without requiring any changes on the receiver.
>

Not exactly, at least I don't think so.

The presumption would be at some point in time, new code points are
deployed. If the "grease" specific thing were well publicised, and new code
points referenced it, it might be possible to infer that newer code points
are deployed only if they are covered in grease.
And conversely, code points prior to the EDNS grease thing would not be
covered in grease.

Thus, senders using grease would be able to know that either a code point
was free to use for grease operations (because the receiver does not return
the grease EDNS thing), or that the grease coverage facilitated flagging of
code points subsequent to the EDNS grease thing.

It's kind of like a flag day, but more of a soft opening, i.e. a dependency
situation.

Brian


>
> David
>
> On Wed, Apr 24, 2024 at 2:09 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque  wrote:
>>
>>> Thanks for your comments David. I hope it will progress too, and good to
>>> hear that that grease worked well for TLS and QUIC.
>>>
>>> On random vs reserved values, we do intend to propose some reserved
>>> ranges (there is a placeholder section in the draft for this already). And
>>> then try to have a debate about the pros and cons (e.g. is reservation just
>>> going to cause middleboxes to treat the greasing range specially, etc). For
>>> the larger fields, yes, we could allocate larger reserved ranges and pick
>>> randomly from those. For the smaller fields (that accommodate just a
>>> discrete set of flags, rather than a number), we could reserve just a small
>>> handful of flags. For any proposal that uses purely random unallocated code
>>> points, I think we'd need software to have pre-configured (or configurable)
>>> end-of-test dates as one way to avoid future interoperability issues.
>>>
>>> Even for the larger ranges though, there is a more granular
>>> classification (such as data vs meta vs q-types in the RR-type space) where
>>> more nuanced treatment is needed, such as defining multiple reserved ranges
>>> and expecting distinct response behavior for each.
>>>
>>
>> I have an idea, which may or may not be useful, for avoidance of testing
>> random code points which are subsequently used, when the two endpoints have
>> differing ideas of which code points are in use.
>>
>> (Philosophically, I prefer negotiated/signaled over unilateral/reserved
>> things. Reserved ranges are the latter. The suggestion here is one
>> potential method or approach for the former.)
>>
>> Would using an EDNS option to signal the set of values that the sender
>> believes are "grease" (and are set in the outgoing packet) work?
>>
>> The recipient would flag the values that are "in use" from among the
>> "grease" values, and the original sender would handle the non-grease
>> response elements flagged by the recipient.
>>
>> This would also allow for one or more grease values to be probed
>> simultaneously or individually, in order to assess/investigate sources of
>> non-response. Including information from both ends via EDNS allows for
>> correlation of those including both the path and the authoritative server
>> EDNS information as data points.
>>
>> For example, if RRTYPE=FOO were a grease value sent by a resolver, it
>> would have EDNS thing "grease-list:RRTYPE=FOO,..." (modulo bike shed color)
>> added. The authoritative server would generate whatever response it had for
>> RRTYPE=FOO, and add a corresponding EDNS thing "non-grease-list:RRTYPE=FOO".
>> The resolver would be able to safely ignore anything/everything in the
>> response, and optionally cache tuple of (authority-IP,code-point) so as to
>> potentially avoid using it as grease, or to log something to the effect of
>> "FOO is now in the wild, maybe you need to update this resolver's
>> software?".
>>
>> This would allow for random grease rather than rese

Re: [DNSOP] DNS Grease?

[Brian Dickson]

On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque  wrote:

> Thanks for your comments David. I hope it will progress too, and good to
> hear that that grease worked well for TLS and QUIC.
>
> On random vs reserved values, we do intend to propose some reserved ranges
> (there is a placeholder section in the draft for this already). And then
> try to have a debate about the pros and cons (e.g. is reservation just
> going to cause middleboxes to treat the greasing range specially, etc). For
> the larger fields, yes, we could allocate larger reserved ranges and pick
> randomly from those. For the smaller fields (that accommodate just a
> discrete set of flags, rather than a number), we could reserve just a small
> handful of flags. For any proposal that uses purely random unallocated code
> points, I think we'd need software to have pre-configured (or configurable)
> end-of-test dates as one way to avoid future interoperability issues.
>
> Even for the larger ranges though, there is a more granular classification
> (such as data vs meta vs q-types in the RR-type space) where more nuanced
> treatment is needed, such as defining multiple reserved ranges and
> expecting distinct response behavior for each.
>

I have an idea, which may or may not be useful, for avoidance of testing
random code points which are subsequently used, when the two endpoints have
differing ideas of which code points are in use.

(Philosophically, I prefer negotiated/signaled over unilateral/reserved
things. Reserved ranges are the latter. The suggestion here is one
potential method or approach for the former.)

Would using an EDNS option to signal the set of values that the sender
believes are "grease" (and are set in the outgoing packet) work?

The recipient would flag the values that are "in use" from among the
"grease" values, and the original sender would handle the non-grease
response elements flagged by the recipient.

This would also allow for one or more grease values to be probed
simultaneously or individually, in order to assess/investigate sources of
non-response. Including information from both ends via EDNS allows for
correlation of those including both the path and the authoritative server
EDNS information as data points.

For example, if RRTYPE=FOO were a grease value sent by a resolver, it would
have EDNS thing "grease-list:RRTYPE=FOO,..." (modulo bike shed color)
added. The authoritative server would generate whatever response it had for
RRTYPE=FOO, and add a corresponding EDNS thing "non-grease-list:RRTYPE=FOO".
The resolver would be able to safely ignore anything/everything in the
response, and optionally cache tuple of (authority-IP,code-point) so as to
potentially avoid using it as grease, or to log something to the effect of
"FOO is now in the wild, maybe you need to update this resolver's
software?".

This would allow for random grease rather than reserved grease, I think,
and would be more appropriate for exercising the full range of code points.

Brian


>
> Shumon.
>
> On Tue, Feb 27, 2024 at 5:59 PM David Schinazi 
> wrote:
>
>> I think this draft is a great idea and I'd love to see it progress.
>> GREASE did well in TLS and worked wonders in QUIC - it helped us catch
>> multiple real production issues early on.
>>
>> That said, I do worry about the idea of using random unallocated values.
>> Not all software gets updated, and no software gets updated immediately
>> worldwide, so this idea is bound to cause interoperability failures down
>> the road. For the 16-bit values, definitely allocate a few hundred GREASE
>> codepoints and then pick a random one from that allocated list. For the
>> fields smaller than 8 bits, things are obviously more difficult but I think
>> you'll be much better off reserving a much smaller number of codepoints and
>> using those instead of using random ones. One instance of an non-updated
>> implementation spraying what values it thinks are unallocated could be
>> enough to prevent future extensibility.
>>
>> David
>>
>> On Mon, Feb 26, 2024 at 10:39 PM Mark Andrews  wrote:
>>
>>> Yep, we are in a much better position than we were in 2019.  Most
>>> failures are
>>> well < 1% when talking to authoritative servers.  Broken firewall
>>> defaults have
>>> been fixed and mostly deployed.
>>>
>>> > On 27 Feb 2024, at 16:41, George Michaelson  wrote:
>>> >
>>> > so yet again, I voice things which show my ignorance, not yours. I
>>> > thank you for the gentle clue-stick hit, it was educational.
>>> >
>>> > -G
>>> >
>>> > On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque 
>>> wrote:
>>> >>
>>> >> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews  wrote:
>>> >>>
>>> >>>
>>>  On 27 Feb 2024, at 15:53, George Michaelson 
>>> wrote:
>>> 
>>>  Not in any way to stop this specific draft, I wonder if this is a
>>> more
>>>  general principle of exercising code points which are not marked
>>>  "never to be used" and should also be raised cross-area, or in
>>> another
>>>  place?
>>> 

[DNSOP] Resolver cooperation (re: key tags but not only key tags)

[Brian Dickson]

Thinking about the KeyTrap problem, and the discussions here about
potential approaches to mitigation of "bad stuff", one thought that came to
mind was that everyone would necessarily have the same data to crunch (or
avoid), and there might be ways to leverage the work required.

This is just an initial though, and might have obvious shortcomings, but
those might have suitable ways of being avoided.

The general idea would involve:

   - Some kind of identification and trust for resolvers or resolver
   operators
   - Attestation of specific tuples as being problematic
   - Specification on what the problem is
   - Possibly proof of work or similar
   - A place to publish those results for the benefit of other resolver
   operators
   - Local policy on whether/how to trust the published results
   - Methods for both manual and automated publication

The example use case would be a few operators of large well-known resolver
sets, publishing to some well-known location when DNS entries are found
which exhibit specific criteria. Other operators could have local
configurations of quorum (how many reports by different operators are
required), which operators to trust (or rules for establishing trust such
as GPG-type things).

If the details can be worked out and such a system were deployed, it would
have the potential to significantly raise the bar for attackers.
It could also provide mechanisms that scale, for warning operators of new
attacks (presuming some sort of language or encoding for what the problem
seen is or which DNS tuples are problematic.)
The attestation etc would be intended to prevent attackers causing DOS via
false positives. There might be benefit to revocation of reports based on a
counter-quorum, if that activity is expected or observed.

There are obviously scaling issues in adding this to things resolvers need
to do. Suitable scaling approaches for publication and signaling might be
able to be established, or perhaps software vendors could add ways for
publication/consumption on their respective packages, similar to e.g. code
signing or fingerprint publications.

Any reactions and feedback are welcome, or just discuss it in a thread...

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

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

[Brian Dickson]

On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews  wrote:

> There is nothing to prevent us saying that responses to priming queries
> SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in
> the response or that the root server address should be looked up as if they
> are glue in the root zone. The rules in RFC 1034 don’t handle priming
> queries well in a number of ways.
>
>  1) all the addresses should be returned or TC should be set.
> 2) the address of the root servers should be looked up as glue in the root
> zone if not found elsewhere
> 3) the addresses of the root servers should be included as glue in the
> root zone if not otherwise there.
>
>
I just (finally) gave this a second look/thought.

I think Mark A's assertion/summary isn't quite 100% correct, based on the
following particular details:
- The concept of a DNS zone (from classic 103[345] RFCs) is a contiguous
portion of the DNS tree.
- The root server names are underneath 'root-servers.net'.
- There is a delegation to 'net' from the root zone.
- The servers themselves (as identified by their IP addresses) are
authoritative for both '.' (root zone) and 'root-servers.net'
- Thus, it is NOT the case that responses from the "root servers" to
queries don't require the TC bit to be set if the entire set of
authoritative A/ records does not fit in the Additional section.
- A careful parsing/analysis would suggest instead, that the A/ records
are in fact in-bailiwick (or whatever we call it these days) from the '
root-servers.net' zone.
- As such, if the entire set of A/ records does not fit, there are two
alternative approaches:
 - Set TC
 - Add a referral to the 'net' zone with its glue (not 100% sure this is
correct, but that's what I think would need to happen to satisfy
resolvability of the NS names to A/ addresses).

Apologies if my analysis is wrong or the terminology is wrong or the
suggested referral is incorrect...

Brian



> --
> Mark Andrews
>
> > On 2 Feb 2024, at 06:15, Wessels, Duane  40verisign@dmarc.ietf.org> wrote:
> >
> > 
> >
> >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman 
> wrote:
> >>>
> >>> As Mark just clarified. This isn't glue, so perhaps the text just needs
> >>> updating.
> >>
> >> The current text is:
> >>
> >> If some root server addresses are omitted from the Additional
> section, there is no expectation that the TC bit in the
> >> response will be set to 1. At the time that this document is written,
> many of the
> >> root servers are not setting the TC bit when omitting addresses from
> the Additional section.
> >>
> >> Note that  updates 
> with respect to the use of the TC bit.
> >> It says "If message size constraints prevent the inclusion of all glue
> records for in-domain name servers,
> >> the server must set the TC (Truncated) flag to inform the client that
> the response is incomplete
> >> and that the client should use another transport to retrieve the full
> response."
> >>
> >> Maybe we should add to the second paragraph:
> >>
> >> Note, however, the root server addresses are not glue records, so
> setting the TC bit in truncated responses from
> >> the root servers is not required by RFC 9471.
> >>
> >> Does this solve your and Warren's issues?
> >
> >
> > I have to confess that “root server addresses are not glue records” is a
> very subtle point that was lost on me, and
> > maybe lost on a lot of us, as evidenced by this discussion.
> >
> > I’m not particularly comfortable with the terseness of the statement
> above.  The terminology RFC doesn’t really help here because it doesn’t
> provide a definition of what glue is glue or what is not glue.  It just
> references semi-conflicting statements in other RFCs.
> >
> > So I think if 8109bis is going to make the statement that root server
> addresses are not glue, it deserves more explanation of why that is the
> case.
> >
> > I also worry that it creates a new problem, which is what sort of
> truncation policy applies to a priming response?  If RFC 9471 does not
> apply, does RFC 2181 Section 9 apply?  Is a priming response with zero root
> server IP addresses acceptable?
> >
> > DW
> >
> >
> > ___
> > 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30

[Brian Dickson]

On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker  wrote:

> IESG Secretary  writes:
>
> > The Domain Name System Operations (dnsop) WG will hold a virtual
> > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam
> > (17:00 to 18:00 UTC).
>
> I'm sadly very day-job conflicted with this slot, but greatly look
> forward to watching the replay afterward (I may try to sneak an earpiece
> into my head but it's unlikely I can pull that off).
>
> I'll note that if we're going to go down the road of such a major
> change to parent/child/resolver interactions, it is highly important we
> get opinions and viewpoints from all segments of the DNS industries to
> ensure this is widely deployable.  Having said that, if I can't keep my
> own zones in sync properly with my registry's advertised data: it's time
> to do something about the problem.  [yes I recognize this is not an
> adequate summary of the problem space, but it's a part].  Whether this
> is the right solution or not will depend on feedback from many voices.
>
>
Ditto, sort of. (Busy with day-job search etc.)

My $0.02 is to paraphrase https://xkcd.com/1069/  (where the pick up line
about putting "U" and "I" next to each other in the English language, gets
trashed by a reference to orthography):

If we're going to add something like DELEG, I'd very much like to see a
corresponding apex record/flag on the child.
It's the one opportunity to "fix" the RRR non-role that DNS operators have
and the unilateral nature of parent-side NS records.
(If someone can come up with a "backronym" for ATE, then the pair would be
DELEG-ATE. :-) )

But seriously, having a signed parental record that can, among other
things, get paired up with a signed child apex record which would confirm
(or deny) the validity of a delegation to a specific nameserver, would be a
very nice thing.
(Permanently lame child servers would need to stand up a zone just for the
denial assertion, but having resolvers obtain, use, and cache that would
improve the situation for all parties.)

I.e. this would facilitate revalidation (as previously proposed), except
that it would handle permanently lame delegations, including the "all
nameservers are lame" situation.

Now that I think about this a bit more, there are problems with being able
to sign a child zone that denies the legitimacy of the delegation.
It might need to exist underneath the namespace of the nameserver name,
e.g. with an underscore prefix.
Modulo the signing and location, it would probably be sufficient for such a
record to be "yes"/"no", as to whether the child thinks the delegation is
legitimate.
(This would basically be an anti-bootstrap record, if that description
makes sense.)

Of course, it would also be nice if the Registries were to take on and fix
the delegation issue (including the conflicting registrar ownership and
usage of host objects), but if the DNS protocol can facilitate a signed
(secure) work-around, that gets DNS to the goal state sooner (a lot
sooner?).

The other things I'd like to see (which may already be in the draft):
- Require DNSSEC if/when DELEG (and ATE) are in use
- If child (ATE) is included, I'd really like the delegation confirmation
to be a MUST. If you are a resolver, the scalability/stability/security of
DNS depends on you respecting (validated) signals from authoritative
servers, IMNSHO.
- Resolver-auth signaling of understanding DELEG (probably more important
for any semantic things if/when those arise), presumably via EDNS.
- Client-resolver signaling too? Are there new capabilities or better
security etc available if/when clients are upgraded appropriately?

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

Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Brian Dickson]

On Sat, Jan 20, 2024 at 3:24 PM Tim Wicinski  wrote:

>
> All
>
> Peter has integrated feedback from the first working group last call, and
> we'd like to do a followup last call.  The diff with the current version
> is here:
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-dnssec-bootstrapping-05=draft-ietf-dnsop-dnssec-bootstrapping-07=--html
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-bootstrapping
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
>
> The Current Intended Status of this document is: Proposed Standards
>
> Please review the draft and offer relevant comments.
>

I have reviewed the draft, and support publication as an RFC.

One minor comment is that I think it could be explained early in the
document somewhere, about why/how this all works and is secure and scalable.
What seems to be missing is the explanation:
- The Child DNS Operator is assumed to be doing locally secured DNSSEC
signing of the Child zone, or has a secure method of obtaining and
publishing the already-signed Child zone (e.g. zone transfer with TSIG).
- Since the Child DNS Operator has the signed child zone, the Child DNS
Operator is able to obtain and publish the corresponding records in a
trusted fashion.
- The Signaling {name,zone,record(s)} are a secure method of indirection
- The key (literally) is the delegation NS records in the Parent which
point to the Name Servers of the Child DNS Operator. If and only if all of
the conditions are met, can this bootstrapping protocol be used:
  - NS points to CDO
  - CDO nameservers are in a DNSSEC signed zone (meaning fully validated
secure chain of trust from root to nameservers' names)
  - CDO nameservers publish Signaling records in their own signed zone(s)

I'm not sure whether any aspects of the comment above would improve the
draft. Either way (with or without), I'm fine with proceeding to published.

Brian Dickson
P.S. I'm no longer at GoDaddy, and no longer have any knowledge of the
state of the implementation there. It may be advisable to contact someone
there and adjust the implementation status info appropriately.


>
> For WGLC, we need positive support and constructive comments; lack of
> objection is not enough.
> So if you think this draft should be published as an RFC, please say so.
>
> If you feel the document is *not* ready for publication, please speak out
> with your reasons.
>
>
> This starts a two week Working Group Last Call process, and ends on:
> February 3, 2024
>
> thanks
> tim
>
> ___
> 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] WGLC draft-ietf-dnsop-rfc8109bis (2nd round)

[Brian Dickson]

On Thu, Dec 28, 2023 at 1:35 PM Tim Wicinski  wrote:

>  All,
>
> We wrapped up the second working group last call for
> draft-ietf-dnsop-rfc8109bis with no comments pro or con.
> The chairs can only assume the working group is not interested in moving
> this work forward.
>

Speaking only for myself, I missed the call for comments etc., and suspect
others did as well.

While most of the content is relatively minor clean-up, I think having such
clean-up done on comparatively important RFCs such as this is a good thing.

My suggestion (feel free to ignore) would be to re-issue this call in the
new year, once folks have returned from their holiday breaks.

I'm in favor of moving this work forward.

Brian


>
> We are going to discuss this with Warren on our next steps here.
>
> Tim
>
>
>
> On Mon, Dec 18, 2023 at 3:14 AM Tim Wicinski  wrote:
>
>>
>> The WGLC closes next week, Saturday, December 24.
>>
>>
>> This should say *Sunday* December 24.
>>
>> thanks
>>
>> Tim
>> (currently double checking some appointments)
>>
>>> ___
> 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] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)

[Brian Dickson]

Sent from my iPhoneOn Dec 13, 2023, at 1:32 PM, Warren Kumari  wrote:On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouters  wrote:Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-07: 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-dns-error-reporting/

--
DISCUSS:

--

This document gives no guidance on the content of the TXT resource
record RDATA for this record.

Based on this, I assume the error report query is of qtype TXT, but this is not
specified anywhere in the document. Someone could use a qtype of CNAME or ANY
or just A or . Can this be stated explicitly ?Erm, I think that it is? Section 3.  Terminology"   Report query:  The DNS query used to report an error is called a  report query.  A report query is for a DNS TXT resource record  type.  The content of the error report is encoded in the QNAME of  a DNS request to the monitoring agent."Section 4.  Overview"The resulting report query is sent as a standard DNS query for a TXT   DNS resource record type by the reporting resolver."7.  IANA Considerations   "IANA is requested to assign the following Underscored and Globally   Scoped DNS Node Name registry: RR Type  _NODE NAME  Reference -    --  - TXT  _er [this document]"

In Section 6.1.1. Constructing the Report Query, only the QNAME construction is
documented, not the QTYPE (or CLASS but there is a reference that says only IN
is supported)

While no guidance on (TXT?) RDATA sending is fine, there should really be a
Security Consideration on what to do with any RDATA. Let's avoid another vector
for log4j.Yup, this is a good point — the document says:" It is RECOMMENDED that the authoritative server for the agent domain replies with a positive response (i.e. not NODATA or NXDOMAIN) containing a TXT record.". Would simply noting that this is untrusted data and should be sanitized / something before stuffing it into logs / displaying it / etc? 
Maybe recommend or even require that such a TXT be an empty record (length zero), or something like that?But allow for non-compliant implementations, of course. Eg ignore any content even if it doesn’t have the recommended data.Brian
The reporting resolver MUST NOT use DNS error reporting to report a
failure in resolving the report query.

This might be tricky to implement. The resolver might not know why another
thread is resolving some A/ record. For example if nohats.ca uses a
reporting fqdn of foobar.fi, why shouldn't validation failures on foobar.fi try
to report that to foobar.fi, if they themselves use a reporting fqdn.

Similarly, recommending disabling DNSSEC for these queries can be tricky, if
resolving the reporting fqdn requires a number of related DNS queries for NS,
DS, A/, CNAMEs). I think it is better to not recommend this and let
failures be failures. If the reporting fqdn fails to resolve, abort trying to
report the failure.

Which of course brings up: Should there be a consideration for the reporting
fqdn not being in-domain ? eg ns1.nohats.ca serving nohats.ca should probably
not use er.nohats.ca.

The er QNAME construction assumes there was only 1 QTYPE. There are drafts
being floated that have more than one QTYPE. How to construct the QNAME for
those?
___DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimization is bad

[Brian Dickson]

Sent from my iPhone

> On Nov 10, 2023, at 12:02 PM, John R Levine  wrote:
> 
> 
>> 
>>> I'd like to write a draft that updates RFC 9156 by describing
>>> situations like this that caches could recognize and avoid useless
>>> churn, added to section 2.3 which already suggests special casing
>>> underscored labels.
>> 
>> I must confess that I do not see what is suggested in this thread
>> which is not already in section 2.3. Unbound implements some of the
>> RFC ways, see its iterator/iterator.h (all parameters named
>> *MINIMISE*).
> 
> If you see a name that is four all-digit labels and it's not in in-addr.arpa, 
> stop minimizing and just send the query.  Similar for 18 hex digits not in 
> ip6.arpa.  I realize these are specific cases but at least in the mail world 
> they are very common ones and minimization more than doubles the traffic 
> DNSBLs would otherwise get.

Perhaps the DNSBL operators could individually or collectively operate 
resolvers which do that exact thing? Or make arrangements with one of the large 
public resolver operators to support that or to stand up an instance 
specifically only for this function?

Mail servers might need configuration changes, of course, but this would still 
involve many fewer moving parts than a substantial fraction of the 3M resolvers 
that your request is indirectly asking to make changes.

The mail server set up could be as simple as a caching forwarder with a set of 
forwarding stanzas for DNSBLs plus default forward stanzas to the regular 
resolvers the server uses. 

Iterate updates as suitable resolvers become available.

That setup could be a standalone package optionally suggested by the various 
mail server packages.

The performance of mail servers would likely be improved, so it would be a 
win/win for them and the DNSBL operators.

Brian

> 
> Again, there might be others.  Data eagerly sought.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> ___
> 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] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Brian Dickson]

I support advancing this document.

Brian Dickson (speaking only for myself)

On Fri, Nov 10, 2023 at 4:46 AM Peter Thomassen  wrote:

> Dear DNSOP,
>
> (This is mainly for those who did not attend today's DNSOP session in
> Prague.)
>
> The chairs announced today that the below WGLC meant to say that some
> reactions in support of this draft are needed for the document to move
> forward. (In contrast to only asking for objections.)
>
> So, if you support this document, please speak up.
>
> Thanks,
> Nils + Peter
>
>
> On 9/19/23 21:48, Tim Wicinski wrote:
> >
> > This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-bootstrapping
> >
> > Current versions of the draft is available here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/>
> >
> >
> > The Current Intended Status of this document is: Standards Track
> >
> > This Document will update  7344 and 8078 if approved.
> >
> > The Document updates brings up something I wanted to raise.
> > Peter and I chatted about some simple nits (remove references from the
> abstract),
> > but I wasn't sure if the sections updating older documents was formal
> enough.
> > DNSOP has produced a few documents recently that update previous work
> > (8767, 8020 and 9077 come to mind), and we are advice on that.
> > (I may very well be overthinking this, which is what I told Peter)
> >
> >
> > Please review the draft and offer relevant comments.
> > If this does not seem appropriate please speak out.
> > If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
> >
> > This starts a two week Working Group Last Call process, and ends on:
> October 3, 2023
> >
> >
> > thanks
> > tim
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Like our community service? 
> Please consider donating at
>
> https://desec.io/
>
> deSEC e.V.
> Kyffhäuserstr. 5
> 10781 Berlin
> Germany
>
> Vorstandsvorsitz: Nils Wisiol
> Registergericht: AG Berlin (Charlottenburg) VR 37525
>
> ___
> 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] QNAME minimization is bad

[Brian Dickson]

On Fri, Nov 10, 2023 at 11:30 AM Denny Watson  wrote:

> On 11/10/2023, Stephane Bortzmeyer wrote:
> > On Fri, Nov 10, 2023 at 02:45:08PM +,
> >   Denny Watson  wrote
> >   a message of 50 lines which said:
> >
> >> One thing that is of interest to me; There appears to be no way for
> >> the owner of the dataset being queried (they should understand what
> >> exists in their zones better than anyone else) to signal that
> >> beneath this domain cut you should just request the full QNAME.
> >
> > It does not seem a good idea, politically. It would enable any
> > registry to shutdown QNAME minimisation for the zones it is
> > authoritative for.
> >
>
> This seems weird to me.  Registries are not normally in the DNS path
> _unless_ they control the full zone.
>
> Are there many instances where that someone registers a domain, point
> that domain NSs to the registry and then create a number sub-zones and
> point NSs to systems that they control?  If they wish to control DNS do
> they not they normally instruct the registry to publish NS records to
> the TLD?.. and if the registry does have the full zone, they can see the
> full QNAME that the user is attempting to reach.
>
> .. or perhaps I am missing something.
>
>
It's relatively subtle: the TLD is normally not in the path when QNAME
minimization exists.

Putting something at the TLD level to disable QNAME minimization, would
affect all queries for all names in that TLD.
Which would basically trigger full QNAME queries for delegations to
second-level domains, the exact behavior that 9156 seeks to avoid.

Brian



> --
> Denny Watson
> Lead Investigator
> The Spamhaus Project
>
> ___
> 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] QNAME minimization is bad

[Brian Dickson]

On Fri, Nov 10, 2023 at 6:45 AM Denny Watson  wrote:

> On 11/10/2023, Paul Wouters wrote:
> > On Fri, 10 Nov 2023, John R Levine wrote:
> >
> >> Subject: [DNSOP] QNAME minimization is bad
> >>
> >> Well, not always bad but sometimes.
> >
> > A bit misleading subject :P
> >
> >> I'd like to write a draft that updates RFC 9156 by describing
> >> situations like this that caches could recognize and avoid useless
> >> churn, added to section 2.3 which already suggests special casing
> >> underscored labels.
> >
> > Couldn't the RBL's add an underscore in their base zone name to trigger
> > the special casing in 9156? That would not require a new RFC and
> > perhaps might not require code updates?
>
>
There may be other things RBLs (and owners of in-addr/ip6 child zones)
could do which would not require RFC changes or code changes.

Whether it is feasible for RBLs may involve more questions and answers to
fine-tune the suggestion to meet their needs.

It may also require a bit of testing to determine behavior and feasibility
versus resolvers doing 9156 minimization and 8198 aggressive NSEC.

Sign the zone(s), specifically using NSEC, not NSEC3.

This will allow resolvers doing 9156 and 8198 together to skip ENTs beneath
nodes in the tree, and more quickly walk the tree to the leaf nodes or to
discover non-matches.

This should reduce the query load on the auth servers.

Note that there is still room for improvement (and possibly a new RFC), by
soliciting NSEC records alongside positive responses.
As it stands, there needs to be a query at the name immediately beneath an
existing node in the tree to obtain an NSEC record.


> The current situation represents countless software packages that would
> need to be reworked to accommodate a new QNAME request starting with an
> underscore.  It's a bit of a heavy lift.  While I personally believe it
> would be better to get these sorts of queries out of DNS, this again
> points the the install base problem, still also a heavy lift.
>
> One thing that is of interest to me; There appears to be no way for the
> owner of the dataset being queried (they should understand what exists
> in their zones better than anyone else) to signal that beneath this
> domain cut you should just request the full QNAME.
>

See above: signing the zone should allow skip-ahead activity, particularly
in IP6 space.


>
> I also suspect (perhaps I missed it) that modifying the values in SOA
> returned for NOERROR + NODATA would be of value for negative caching.
> Again, the data owners should have a better understanding of their zones
> than anyone else.
>
>
Correct. In 8198:

... the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field...

are the attributes that control behavior for aggressive NSEC usage.
Those can be overridden by resolver operators, so choosing relatively
moderate values may be advisable.

Brian


> --
> Denny Watson
> Lead Investigator
> The Spamhaus Project
>
> ___
> 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] NOTIFY: How to locate the target

[Brian Dickson]

I think what we have here is (as Daffy Duck famously put it) "pronoun
trouble".

The target for a NOTIFY would necessarily be found in the SOA record of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.

The SOA record would need to be initially configured appropriately, based
on instructions from the Registrar (for example), or the CCTLD operator
(for non-RRR situations).
That initial step is converting what would otherwise have needed to be
out-of-band into an in-band mechanism.
NB: that information would be intended for human consumption and zone
configuration, or for use by appropriate tools that get supplied the
parameter(s). I don't think specifying locations for tooling to scrape data
and use it is a good idea.

The NOTIFY would most likely be signaling the existence of something like a
CDS and/or CDNSKEY record.

The NOTIFY would not be sent to a destination derived from the parent
zone's SOA, in all likelihood.

BTW, this use of registrant's zone's SOA.MNAME supports both the non-hidden
master/signer, and the hidden master/signer use cases, AFAICT.

Brian

On Wed, Nov 8, 2023 at 12:49 PM John R Levine  wrote:

> On Wed, 8 Nov 2023, Joe Abley wrote:
> > I think the idea is that these two existing and well-implemented
> mechanisms should be considered first to see if they fit before anybody
> goes to the trouble of inventing new ones.
>
> The most likely use case for this stuff is for a domain registrant to
> update the DNSSEC info in a TLD, and I'm pretty sure you know more about
> the way .ORG is set up than I do. Since the registrant is a customer of
> her registrar, that's where the NOTIFY needs to go.
>
> How well do you think it would work to send NOTIFY to the anycast mirrors
> that serve the .ORG zone?  FWIW, even for my own tiny DNS setup, I use
> NOTIFY to sync with a mirror at a nearby ISP and I have to notify his
> hidden primary which does not appear in any NS or SOA records.
>
> R's,
> John
>
> ___
> 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] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

[Brian Dickson]

On Fri, Oct 13, 2023 at 10:48 AM John Levine  wrote:

> I was looking at these two drafts. The first one says that scanning
> for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
> second one says to scan for DS bootstrap.  I am experiencing cognitive
> dissonance.
>

I believe a more concise summary of the Notify vs CDS would be:

   - Notify is better than scanning
   - This is analogous to "Winning $1,000,000 in the lottery is better than
   winning $10."

It also is more helpful to consider the parties and benefits of using
Notify.
CDS scanning will always be necessary, for the use cases relevant here.

   - Notify does not impact the scanning activity at all.
   - Notify *does* reduce the time for a *specific* domain to have the CDS
   processing done.
   - Notify benefits the Registrant, not the Registry or Registrar.


Similarly, the bootstrap process is likely to be further refined, if it is
not already refined thusly:

   - The DNS operator should maintain bootstrap zones for each scanning
   entity (TLD or Registrar, as appropriate)
   - Each scanning entity would then "walk" the corresponding bootstrap zone
   - The feedback between initial DS publication at the TLD parent and the
   bootstrap zone would look a lot like the mechanism used for CDS itself:
  - Publish (CDS or bootstrap)
  - Check TLD until DS is observed
  - Change/remove record (CDS or bootstrap)
   - This turns the relevant bootstrap zones into what are effectively
   FIFOs, with the scanning entity having some ability to control the size of
   the zone being scanned (by scanning more frequently)
   - Since each of the bootstrap zones are DNSSEC signed with NSEC, they
   can be very efficiently walked (this is a feature, not a bug)
   - The scanner can further be optimized into a poll-then-scan-if-needed,
   by using SOA record polling on the zone. Only scan if the poll returns a
   new SOA SN.
   - The use of Notify would be a trigger for the poll-then-scan, with the
   Notify being scoped to the bootstrap zone itself


Hopefully this fixes your cognitive issue. :-)

Brian



>
> I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to
> the parent of a delegated name to tell it to do the bootstrap rather
> than scanning. The issues in section 3 about why scanning is bad and
> in section 4 about where to send the notification are exactly the same
> as what's there now.
>
> I suppose you could overload NOTIFY(CDS) and the parent does one or
> the other depending on whether the zone already is signed but it seems
> to me that the operations are different so the notification might as
> well be different too.
>
> Bonus update: if we do this, in the bootstrap draft take out section
> 4.3 on triggers and instead say to use notify.
>
> R's,
> John
>
> ___
> 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] Call for Adoption: draft-bellis-dnsop-qdcount-is-one

[Brian Dickson]

On Thu, Sep 28, 2023 at 10:00 AM Tim Wicinski  wrote:

>
> We want to thank Joe and Ray for getting this republished with the notes
> from the previous meeting.
>
> Thanks Ted and Eric for their comments today, we will remember them.
> I will say that this chair likes the appendix, to remind me what I
> have glossed over, as the authors have already corrected me on this week
> (thank you).
>
>
>
> This starts a Call for Adoption for draft-bellis-dnsop-qdcount-is-one
>
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
>

I support adoption by the WG. I am willing to review and contribute text.

Brian


>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: October 12, 2023
>
> Thanks,
> For DNSOP co-chairs
> tim
>
>
> ___
> 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] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

[Brian Dickson]

I support adoption.
I am willing to review and contribute.
There is a good chance of using the feature, particularly for the
CDS/CDNSKEY use case.

Brian

On Thu, Sep 14, 2023 at 7:10 PM Suzanne Woolf  wrote:

> Dear colleagues,
>
>
>
> This note starts a Call for Adoption for
> draft-thomassen-dnsop-generalized-dns-notify.
>
>
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
>
>
> Some time in the next two weeks, please review this draft to see if you
> think it is suitable for adoption by DNSOP, and send any comments to the
> list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
> It’s particularly helpful if you can comment on whether you would implement
> or use this feature.
>
> This call for adoption ends: 28 September 2023
>
> Thanks,
> Suzanne
>
> For DNSOP co-chairs
>
>
>
>
> ___
> 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] Compact DoE sentinel choice

[Brian Dickson]

On Thu, Jul 27, 2023 at 2:49 PM Brian Dickson 
wrote:

>
>
> On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni 
> wrote:
>
>> 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.
>>
>> > 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.
>>
>> > 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.
>>
>
>
Never mind, I was wrong. Please ignore.

(non-apex BNAME might have been a good thing, combining CNAME+DNAME).

Brian



> Hmmm... I think I have a solution (which is an even uglier hack), which
> does all of the above PLUS the nothing-below semantics (I think).
> The added bonus is it lowers the bar for auth implementers (I think?).
> It goes against the letter of rfc4592, but because the target is intended
> to be an empty zone, the coherence problem becomes moot.
>
> The idea is to add to each zone served by the CDoE provider, the following
> record (relative to the owner name of the zone):
> * DNAME signed_providers_own_empty_zone.example
>

> This still has the single signature benefit.
> It's cacheable.
> The cost of also returning the empty zone SOA denying all children (plus
> signatures) gets to be amortized over all the responses from each resolver
> (modulo TTL obviously).
> Since the DNAME targets always result in NXDOMAIN, the signal is preserved
> (or resurrected).
> Since the results are ALWAYS going to be NXDOMAIN no matter how resolvers
> do the rewriting, the incoherence is moot.
> It has the side effect of generating CNAMEs too, I think, so fully
> backward compatible to anything really ancient.
> Yes, it is incredibly ugly and hacky.
> And yes, I managed to drag DNAME into one of my wonky solutions. :-)
>
> But seriously, I think it might be workable, if the CDoE implementers can
> live with it (or can generate those on-the-fly).
> The add-to-zone method avoids needing to write any software, and reduces
> the signatures needed in answers, so possibly even of use to the non-CDoE
> situations.
>
> Brian
>
>
>>
>> So I am disinclined to go there, barring lots of evidence that it
>> actually satisfies the various motivating use-cases and has broad
>> support.
>>
>> --
>> Viktor.
>>
>> ___
>> 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] Compact DoE sentinel choice

[Brian Dickson]

On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni 
wrote:

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

Hmmm... I think I have a solution (which is an even uglier hack), which
does all of the above PLUS the nothing-below semantics (I think).
The added bonus is it lowers the bar for auth implementers (I think?).
It goes against the letter of rfc4592, but because the target is intended
to be an empty zone, the coherence problem becomes moot.

The idea is to add to each zone served by the CDoE provider, the following
record (relative to the owner name of the zone):
* DNAME signed_providers_own_empty_zone.example

This still has the single signature benefit.
It's cacheable.
The cost of also returning the empty zone SOA denying all children (plus
signatures) gets to be amortized over all the responses from each resolver
(modulo TTL obviously).
Since the DNAME targets always result in NXDOMAIN, the signal is preserved
(or resurrected).
Since the results are ALWAYS going to be NXDOMAIN no matter how resolvers
do the rewriting, the incoherence is moot.
It has the side effect of generating CNAMEs too, I think, so fully backward
compatible to anything really ancient.
Yes, it is incredibly ugly and hacky.
And yes, I managed to drag DNAME into one of my wonky solutions. :-)

But seriously, I think it might be workable, if the CDoE implementers can
live with it (or can generate those on-the-fly).
The add-to-zone method avoids needing to write any software, and reduces
the signatures needed in answers, so possibly even of use to the non-CDoE
situations.

Brian


>
> So I am disinclined to go there, barring lots of evidence that it
> actually satisfies the various motivating use-cases and has broad
> support.
>
> --
> Viktor.
>
> ___
> 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] what could we do with 15 unused bits of QDCOUNT?

[Brian Dickson]

Top-reply (since there are already a bunch of threaded replies that might
benefit from this):
Queries are small, and have room in the first packet for EDNS (and often
the resulting size will still be < 576).
Idea:
EDNS "signal" + bits -> tells server the client knows about the new meaning
of the 15 bits of QCOUNT, and is sending its client-side version of what
those bits are.
I.e. the bits are NOT changed from zero in the header in the *query*, only
in the *reply* and only if the server understands this EDNS option.
IFF a server understands this EDNS parameter, it responds with the
corresponding EDNS parameter (possibly without bits, either same EDNS
parameter or a sibling parameter), and sets the 15 bits per whatever the
rules are.
Reason:
Putting bits in the header (when mutually understood and agreed upon)
ensures they are in the first portion of the response, even if the response
gets fragmented. E.g. for entropy, this is an important feature, to protect
against things like "fragmentation considered poisonous".

Brian


On Wed, Jul 26, 2023 at 4:12 PM George Michaelson  wrote:

> if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> the header.
>
> What would be interesting uses of the flow-label? Oh wait.. that's
> right, nobody really knows at scale how to use flow-label either.
>
> I tend to "use it for 15 bits of signalling" because there are a lot
> of things I wish were signalled from client to server.
>
> "I am new code"
> "I am at least not ancient code"
> "I'm the same as that other guy you saw over "
> "I like TCP and want to do a persisting session"
> "tell me if you are doing a|b|c|d"
> "I like chocolate and want a pony"
>
> maybe the truth is, we've got 15 bits of zero in the header forever, amen.
>
> (I deliberately didn't put this in the draft- post from Ray so as not
> to pollute an objective discussion of what it is or is not the value
> proposition)
>
> clue-stick hits welcome. Avoid the stomach.
>
> -G
>
> ___
> 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] what could we do with 15 unused bits of QDCOUNT?

[Brian Dickson]

On Wed, Jul 26, 2023 at 5:09 PM Robert Edmonds  wrote:

> George Michaelson wrote:
> > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> > the header.
> >
> > What would be interesting uses of the flow-label? Oh wait.. that's
> > right, nobody really knows at scale how to use flow-label either.
> >
> > I tend to "use it for 15 bits of signalling" because there are a lot
> > of things I wish were signalled from client to server.
> >
> > "I am new code"
> > "I am at least not ancient code"
> > "I'm the same as that other guy you saw over "
> > "I like TCP and want to do a persisting session"
> > "tell me if you are doing a|b|c|d"
> > "I like chocolate and want a pony"
> >
> > maybe the truth is, we've got 15 bits of zero in the header forever,
> amen.
> >
> > (I deliberately didn't put this in the draft- post from Ray so as not
> > to pollute an objective discussion of what it is or is not the value
> > proposition)
> >
> > clue-stick hits welcome. Avoid the stomach.
> >
> > -G
>
> With a maximum length QNAME inside a UDP query packet there are slightly
> under a couple thousand bits available for EDNS. Those bits at the end
> of the packet are easier to get to, ecosystem-wise, so if those use
> cases are worthwhile they should probably be done with EDNS.
>
>
It depends.
E.g. one variable in the mix is UDP fragmentation, which can put the EDNS
component outside the first fragment.
Header bits are always in the first fragment, so depending on the specific
attack scenario and deployment state of things (like avoid-fragmentation),
entropy in the first packet is still valuable.

Brian
___
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?

[Brian Dickson]

On Wed, Jul 26, 2023 at 4:12 PM George Michaelson  wrote:

> if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> the header.
>
> What would be interesting uses of the flow-label? Oh wait.. that's
> right, nobody really knows at scale how to use flow-label either.
>
> I tend to "use it for 15 bits of signalling" because there are a lot
> of things I wish were signalled from client to server.
>
> "I am new code"
> "I am at least not ancient code"
> "I'm the same as that other guy you saw over "
> "I like TCP and want to do a persisting session"
> "tell me if you are doing a|b|c|d"
> "I like chocolate and want a pony"
>
> maybe the truth is, we've got 15 bits of zero in the header forever, amen.
>
> (I deliberately didn't put this in the draft- post from Ray so as not
> to pollute an objective discussion of what it is or is not the value
> proposition)
>
> clue-stick hits welcome. Avoid the stomach.
>

15 bits of entropy would maybe be a good use, particularly for short QNAMEs
(and with QNAME minimization, that definitely applies to root and TLD
queries).
That would augment or compensate for fewer bits available for 0x20 entropy.

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

Re: [DNSOP] Compact DoE sentinel choice

[Brian Dickson]

On Tue, Jul 25, 2023 at 3:39 PM Shumon Huque  wrote:

> On Tue, Jul 25, 2023 at 11:28 AM Viktor Dukhovni 
> wrote:
>
>> On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote:
>>
>> > Ok, yes, I understand now, thanks. An NXNAME ignorant validator
>> > will treat a response to a query for the NXNAME type specifically
>> > as bogus, and could spray a bunch of follow-on queries to other
>> > servers for the zone before giving up and returning SERVFAIL.
>> >
>> > If the Compact DoE authority is specially defined to return only
>> > "NSEC RRSIG" in the type bitmap for explicit NXNAME queries
>> > for a non-existent name, doesn't that solve the problem?
>>
>> Yes, that could solve the problem, though NXNAME-aware resolvers would
>> need a somewhat tricky cache state, that holds and returns:
>>
>> - The NSEC record with the "NSEC RRSIG NXNAME" bitmap for most
>>   RTYPEs
>> - The "NSEC RRSIG" bitmap if explicitly asked for NXNAME.
>>
>> The draft should describe the behaviour expected from auth servers,
>> and validating resolvers, including their responses upstream.
>>
>
> Yes, we could certainly do that.
>
>
>> To me a single signed record that proves NXDOMAIN regardless of the
>> query RTYPE sure looks simpler!  The above is noticeably kludgier.
>>
>
> My preference would be to try to make this issue irrelevant by having
> DNS servers treat meta-types specially and return an error, or at least,
> in the case of resolvers, not cache any responses received for them.
>
> One challenge is that there isn't a unique range that identifies metatypes.
> Range 128 - 255 seems to unfortunately be for both meta-types  and
> q-types.
> I did a quick test of BIND and Unbound just now - they return FORMERR
> for almost all of this range, but respond to specific q-types they support
> (IXFR/AXFR/*).
>
> And then, there is the issue of the period of time where we are using
> private RR type codes. There is no meta-type subset range in there that
> is treated differentially.
>
> Viktor - your original suggestion was to only define the ENT sentinel
> instead of NXNAME. How would that solve the problem of systems and
> applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG"
> is a normal ENT response  from a non Compact DoE implementation, or an
> NXDOMAIN response from a Compact DoE implementation.
>
>
>> Especially simple would be using just distinct combinations of
>> "NSEC" and "RRSIG" for NXDOMAIN vs ENT, with no new sentinel
>> types, provided resolvers can gracefully handle bare-bones
>> bitmaps that include a proper subset of "NSEC RRSIG".
>>
>
> I think that suggestion would need detailed testing and also possible
> arguments with DNSSEC protocol correctness people. The NSEC
> record is designed to prove its own existence and is required to have
> NSEC and RRSIG in its type bitmap if I recall.
>


So, to recap the requirements that this is attempting to provide a solution
for:

   - Online signers want to be able to provide a response for names that
   don't exist, in signed zones, without doing NXDOMAIN (which requires 2-3
   signatures)
   - Some current implementations don't either provide answers that don't
   give clear distinction between NXDOMAIN and ENT
   - Other current implementations provide bitmaps in NSEC(3) records that
   claim types exist when they do not
   - The goal is to give answers that work for both CDoE and regular
   offline-signed zones, and permit distinguishing ENT from NXDOMAIN, and
   where CDoE signers only need to generate one signature.

The non-NXDOMAIN answer is problematic already, I believe.

What if it were possible to provide a solution to all of those
requirements, AND give resolvers an actual cacheable NXDOMAIN?

It's ugly, it's a kludge, it will likely be shouted down, but I think there
is one method that could work.

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).
Only one signature is required, since there is an answer, rather than just
an NSEC(3) with bitmap.
The target of the CNAME is out of bailiwick, so the resolver would need to
obtain that, and get the NXDOMAIN result from that response (which results
in NXDOMAIN to the client).
All of these are cacheable.
If/when empty.as112.arpa is signed, the full chain would be protected by
DNSSEC.
ENTs are distinguishable (they would get the current ENT response of
NSEC/RRSIG bit map)

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

(It's not a DNAME, but is kind of close to it. :-) )

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

Re: [DNSOP] Compact DoE sentinel choice

[Brian Dickson]

On Mon, Jul 24, 2023 at 1:55 PM Viktor Dukhovni 
wrote:

> In today's session we had some discussion of the choice of sentinel
> RTYPEs for ENTs vs. NXDOMAIN.
>
> There isn't much in the meeting to cover the fine details of various
> alternatives, so I hope a followup message will make my comments more
> clear.
>
> 1.  I am all in favour of distinguishing NXDOMAIN from ENT.  This is
> a reasonable prerequisite for any proposal.
>
> 2.  That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
> responses:
>
> a.  Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
> b.  Sentinel RTYPE for ENT with just NSEC + RRSIG for NXDOMAIN.
> c.  Distinct sentinel RTYPEs for both ENTs and NXDOMAIN.
>
> Presently, the draft is proposing option "a".  My point is that with "a"
> we get a response that is promising the existence of an RRset for a name
> that does not exist:
>
> Q: nxdomain.example. IN NXNAME ?
> A: ???
>
> - How should such a query be answered?  How should the answer be cached?
> - How is denial of existence of that RRset validated by legacy resolvers?
>
> It is far from clear that there's a clean/consistent answer to the above
> questions.
>
> On the other hand, with "b", we can still distinguish NXDOMAIN from ENT,
> because NSEC records with just "NSEC RRSIG" in the type bitmap are not
> valid for ENTs.  Once the providers currently "abusing" this response
> form also for NXDOMAIN adopt the final spec, the ambiguity goes away.
>
> And, in this, it is possible to answer queries for the ENT sentinel
> RTYPE, by returning an associated empty RDATA and RRSIG that can be
> cached.  The ENT is then a bit less "empty" than before, but the
> resulting state is consistent.
>
> Q: enthere.example. IN ENTNAME ? ;
> A: enthere.example. IN ENTNAME "" ; Zero-length RDATA
>enthere.example. IN RRSIG ENTNAME ...
>
> The result can be cached, and it is not inconsistent with the existence
> of the node as an (almost) empty non-terminal.
>
> The compact version of an ENT gains a additional RRset, but this can be
> validated by legacy resolvers with no issues.
>

This "b" proposal is definitely prefered for all the reasons Viktor
outlined.

However, I had a thought about NSEC(3) bitmaps vs actual RRs.
Since the compact responses are created and signed on-the-fly, there may be
more explicit ways of signaling NXDOMAIN.

I haven't thought this through completely, so it may be wrong or a really
bad idea, but it might be worth thinking about and/or testing if it isn't
totally wacky.

I believe there are three potential query/answer things that on-line
signers want to compactly respond to:

   1. Name exists, other types exist, queried type does not exist
   2. Name exists, no types exist (ENT), queried type does not exist
   3. Name does not exist

What if, rather than a response that needs inference for (3), an explicit
response is provided, in the form of a signed record?
It might not ever need to occur in an NSEC bitmap, since the name itself
doesn't exist.

So, for ENT, respond with "b" per Viktor (sentinel bitmap)
For NXDOMAIN, respond with an actual NXNAME (no RDATA) and corresponding
RRSIG.

And for clarity, this would only be sent by an auth server doing compact
DoE. Any other server doing offline signing would never *need* to send
NXNAME records (but in theory, could, in addition to the normal NXDOMAIN
response.)

To explain the logic here: I'm borrowing this from DNAME, which provides
DNAME (signed) plus CNAME (unsigned) to handle the backward compatibility
issues in case the client does not understand DNAME. In the case of DNAME,
DNAME is a (significant) optimization, is signed and validatable and
cacheable; it is clearly preferable that the client understand and use
DNAMEs if they exist. But, it is still only an optimization, as the
legitimate (but unsigned) CNAME response is included.
The reverse would be true for NXNAME: A client that didn't know about
NXNAME would still be able to infer the NXDOMAIN (assuming it had the
proper logic implemented). A client that knows about NXNAME might be able
to use and cache that response with less work.

I think the backward compatibility (if I am correct, and it tests true)
would mean this could be unilaterally be deployed by auth servers
immediately, avoiding any chicken/egg or critical mass problems.

NB: *lack* of NXNAME does not automatically promote a name into existence.
NXNAME is merely a shortcut to avoid inferences and extra work by signers
and resolvers.

Thoughts?
Brian
___
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

[Brian Dickson]

On Mon, Jul 17, 2023 at 12:20 PM John R Levine  wrote:

> Just to be clear, I think it's quite reasonable to encourage people to put
> tokens at _name but I still see it as a matter of taste, not a technical
> issue.
>
> On Mon, 17 Jul 2023, Brian Dickson wrote:
> > TCP being triggered on resolver-auth is much more of concern,
> particularly
> > when the underlying cause (large RRsets) is preventable.
>
> I take your point, but we're not talking about a lot of traffic.  If any
> particular token is checked as often as once a day, that's a lot.  At what
> scale does the TCP traffic become an issue?
>

The stuffed apex does not only include those tokens, e.g. SPF and friends,
which get queried A LOT.
So, adding validation tokens to the apex causes collateral damage via
non-token apex records.

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.

E.g. Suppose TCP is 1% of traffic. Something bumping it to 1.5% might seem
benign, but in reality is causing 50% extra cost.
Whatever the impact, if it does not have some corresponding benefit
overall, or particularly relative to op-ex vs revenue, that's a bad outcome.

DNSSEC is maybe a red herring, because there are operational benefits on
the overall query ecosystem.
Specifically, with aggressive NSEC, resolver-auth load (and particularly
DOS/DDOS triggered load) actually goes down A LOT, in the worst case
scenarios.


>
> >> The only somewhat plausible argument I see against stuffing the apex is
> >> that if people are sloppy, they might invent tokens that could be
> confused
> >> with each other.
> >
> > The technical term would be "collision" rather than "confusion".
> > One harm of collision is the impact on automation. Whether at the apex or
> > in underscore prefixes, the collision "space" suffers from the "birthday
> > paradox" scaling problem.
>
> The birthday paradox is relevant if you only have 366 birthdays, but not
> if people are using 20 character identifier strings which give you a
> 10^25 point name space.  (See the Cisco TXT records in my previous
> message.)  This is an aesthetic preference, not a technical one.
>

In the absence of the aforementioned draft, there is no specific guidance
that would lead ALL token issuers to use 20 character identifiers.
And without doing so, the likelihood of some issuers having conflicting
semantic choices (and thus token choices) is non-trivial.

E.g. any mail package that gets used, or hosting software, or third party
apps generally.

E.g. I've seen a software vendor "foo" with their registered domain
"foo.example", who have lots of customers running "foo" as a service.
The vendor was given guidance to use "_foo_example" (an encoding of their
domain) rather than "_foo", to protect themselves from collisions.
But there is also a likelihood of some non-zero subset of operators of "foo
as a service" picking "_foo" and causing collisions.
The draft would provide sufficient guidance to reduce the latter from being
relatively common (lots of assumptions etc., but better than no guidance.)

Brian
___
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

[Brian Dickson]

On Mon, Jul 17, 2023 at 11:05 AM John R Levine  wrote:

> >>> TCP, you already have worse problems, like DNSSEC doesn't work.
> >
> > Triggering TCP is still not good, even if it all works. It is still
> > better avoiding by not stuffing the APEX. So I think we still want
> > to leave something in there.
>
> In view of the wide use of DNSSEC and DoT and DoH, I think the argument
> that triggering TCP is bad stopped being persuasive a while ago.  (Don't
> we hope people sign the DNS responses with the tokens?)
>

Hi, John,
I believe you've conflated two different things here.

DoT and DoH are (for the most part) used in client-recursive
communications. (I have no comment on those vis a vis TCP).

TCP being triggered on resolver-auth is much more of concern, particularly
when the underlying cause (large RRsets) is preventable.

DNSSEC impact is mitigated largely by migration to algorithms that are
sufficiently small in RRSIG and DNSKEY sizes to avoid triggering TCP, such
as alg 13.

As an auth operator (at scale), TCP being bad is very obvious (to us), and
I'd hope persuasive without having to provide detailed stats whenever this
question is raised.

Endorsing this (verification techniques draft) would likely result in the
eventual migration of such validation records out of the apex, i.e.
un-stuffing the apex (in multiple senses).
At a minimum it would "stop the bleeding" prior to actually stitching the
wound(s), figuratively speaking.


>
> The only somewhat plausible argument I see against stuffing the apex is
> that if people are sloppy, they might invent tokens that could be confused
> with each other.
>

The technical term would be "collision" rather than "confusion".
One harm of collision is the impact on automation. Whether at the apex or
in underscore prefixes, the collision "space" suffers from the "birthday
paradox" scaling problem.
It isn't whether a particular token collides, it is whether any two (or
more) tokens collide.
That situation won't occur everywhere, but if it occurs anywhere (possibly
well after the token authors have used it for a lot of issued tokens), it
becomes a real operational issue for the domain owners.
The first collision might not happen for a while, and after it does, the
fix would require one or more of the token issuers to change what they are
using.
That in turn, would not be a pleasant situation to sort out. Consider the
impact if the token issuers are similar in size, or if both are "large" for
some value of large.
(Moving the name of the token to part of the name rather than the
TXT content doesn't actually change the collision situation, but the other
recommendations on selection of token do improve it.)


>
> But people have been putting tokens at the apex for years and I have
> never, ever, heard of token confusion.
>

You are looking for anecdotes (or claim to not have any).
IMNSHO, what you should be looking for is statistics.
Or you could just ignore this whole thing. I don't think it impacts you at
all, either way, but does impact lots of other folks.

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

Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Brian Dickson]

On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott  wrote:

> Folks, we could really use feedback from people with DNS expertise to help
> document a set of best practices for managing existing DNS delegations at
> the
> TLD level when EPP domain and host objects are deleted. As described in
> this
> draft:
>
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> EPP includes recommendations to not blindly delete objects associated with
> existing delegations because, among other reasons, doing so can lead to
> DNS
> resolution failure. That's led some domain name registrars to implement
> creative practices that expose domains to risks of both lame delegation
> [1]
> and management hijacking. The draft includes descriptions of current known
> practices and suggests that some should be avoided, some are candidates
> for
> "best", and there are others that haven't been used that might also be
> candidates for "best". The authors would like to learn if others agree
> with
> our assessments and/or can suggest improvements.
>
> Please help. ICANN's SSAC is also looking at this issue and expert
> opinions
> will help us improve DNS resolution resilience. I plan to mention this
> quickly
> at IETF-117 given that the WG agenda is already full, but on-list
> discussion
> would be extremely valuable.
>
> Scott
>

I have a few more (random) thoughts/musings about the RRR architecture and
elements involved for EPP activity.

These are things that were probably minor when the number of gTLDs was
small, there were fewer Registrars, etc.

Also, I don't think it is necessary to address these in the short term.
Identifying them allows thinking about long term approaches, however.

The host objects that are referenced might be same-registry things (so glue
is provided with DNS responses), or different-registry things (no glue).
This leads to redundancy (same objects being defined in multiple places),
potential conflicts (first to register), inconsistencies, etc.

However, those host objects in multiple Registries *should* always be the
same real-world things that are referenced. Having a way to facilitate any
of the kinds of checks and balances being discussed for different-registry
as well as same-registry host object references is one potential issue.
E.g. deletion of host objects, requirement for consent on references,
owning Registrar, etc. are all things that might work better with some kind
of correlation to real-world hosts and their respective owners.

Similarly, it might be the case that Registrars could nominate some sort of
default server(s) as substitutes (or sacrificial servers) to replace
references to deleted host objects. This might scale better if there was
some way to share/coordinate/dereference the original host objects and
substitutes/sacrificials across Registries. This could avoid the NxM
scaling problem (N Registrars, M Registries). It might be the case that the
requirement for Registrars to supply their own substitute/sacrificial
servers could end up in e.g. ICANN accreditation agreements, for example.
This concept would not preclude outsourcing of such servers to third
parties, I don't think.

These ideas would seem to point in the direction of a model containing a
more centralized "host Registry", that might only be used for
inter-Registry EPP-related transactional activity, but not for storage of
any canonical Host information (Registrar, glue), except by reference to
the corresponding Registry (based on the name of the Host).
I'm not sure if that would be feasible, or how that would be
managed/controlled, etc. or whether that would work for non-gTLD cases
(such as CCTLDs).

Again, these are musings, not actual proposals or anything. Feedback on
these is definitely welcome.
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Brian Dickson]

On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott  wrote:

> Folks, we could really use feedback from people with DNS expertise to help
> document a set of best practices for managing existing DNS delegations at
> the
> TLD level when EPP domain and host objects are deleted. As described in
> this
> draft:
>
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> EPP includes recommendations to not blindly delete objects associated with
> existing delegations because, among other reasons, doing so can lead to
> DNS
> resolution failure. That's led some domain name registrars to implement
> creative practices that expose domains to risks of both lame delegation
> [1]
> and management hijacking. The draft includes descriptions of current known
> practices and suggests that some should be avoided, some are candidates
> for
> "best", and there are others that haven't been used that might also be
> candidates for "best". The authors would like to learn if others agree
> with
> our assessments and/or can suggest improvements.
>
> Please help. ICANN's SSAC is also looking at this issue and expert
> opinions
> will help us improve DNS resolution resilience. I plan to mention this
> quickly
> at IETF-117 given that the WG agenda is already full, but on-list
> discussion
> would be extremely valuable.
>
> Scott
>

I believe the fundamental root problem is the "security model" (for lack of
a better term) for EPP. I realize EPP long predates much of the efforts in
the DNS world, and the fact that it didn't anticipate these problems
shouldn't result in any blame. That should not excuse resistance to fixing
deficiencies in EPP, if that is what is needed to resolve these issues.

While there may be better or worse practices available within the current
model for EPP, sticking with what EPP currently does without including the
EPP model as being in scope, may be sub-optimal.

The canonical situation described in the linked draft encapsulates the
model problems: it is possible (and in fact unavoidable) for unrelated EPP
clients (registrants with different registrars) to interfere with what
should be straightforward operations (eg deleting a host record).

This issue also presents itself in permanently 100% lame delegations, where
the NS delegations for a domain are pointed to a DNS provider for which the
domain is unknown (not authoritative for the domain). That situation
exposes the DNS provider to arbitrary levels of abuse via open (aka
"public") resolvers.

I think a more appropriate model would be to require (or at least
facilitate) bilateral control on delegations (opt-in or opt-out,
basically). For example, the registrar for the domain that is the parent of
a host entry, should be able to "disavow" a particular reference
(delegation to said host). It would be the responsibility of the other
registrar (for the domain being disavowed) to clean up the broken
delegations. This is basically giving authority to the DNS operator as a
party to the situation, even if only indirectly.

Having the original host object owner provide the sacrificial target places
the burden on the wrong party, somewhat analogous to "blaming the victim".

Maybe having the otherwise dangling or otherwise blocking references
converted to their respective in-bailiwick names might be a solution. E.g.
if domain2.example had an NS record pointing to ns1.domain1.example, and
domain1.example were deleted (or ns1.domain1.example were deleted), having
the reference converted (by whom??) to ns1.domain2.example would suffice.
But, that would also require picking a new IP address to use for the glue
for that (new) host object. It's a thorny problem, a real can of worms.

Seperate "thread" on the name/control issue:
I think there is a corresponding "blind spot" that exists, that might also
need to be addressed: the concept of ownership of IP addresses used within
"glue" records.
The DNS "NS" record uses a name as the target, and necessitates
corresponding A/ records to resolve delegations.
However, the DNS protocol does not make use of names for DNS lookups by
resolvers. DNS queries use addresses only.
This means that unrelated glue records could point at the same IP address,
even if the host records are distinct with different owners.
First-to-register does not guarantee that the correct ownership could be
determined by creation time (i.e. it's a race condition without a stronger
mechanism.)

Basically, I don't think there are any easy answers, but it definitely is a
real-world problem.

Brian
P.S. I will admit to being the author of the concept of naming things under
"empty.as112.arpa", as the creative approach that is referenced in the
draft's references. It's somewhat sneaky, but in the absence of a better
approach, directs abusive delegations into a black hole of sorts. I will
gladly endorse any better approach that avoids the burden of third-party
delegations being maintained by the first party (who may no longer be being
paid 

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

[Brian Dickson]

On Sun, Jun 11, 2023 at 8:09 PM Paul Wouters  wrote:

>
> On Jun 10, 2023, at 15:42, Tim Wicinski  wrote:
> >
> > 
> > All
> >
> > The chairs have been looking at two different drafts discussing the use
> of using DNS NOTIFY to update DNSSEC information.
>
> Interesting, as the reason for using CDS et. all was because TLD operators
> didn’t want to receive and process NOTIFYs. Has this changed ?
>
> Related also the infamous “triggers vs timers”, where most TLDs didn’t
> want triggers. Has this changed?
>
> > We have some questions for the WG - if DNSOP adopted one of these, would
> DNS server vendors implement it down the road? (We think so)
>
> I don’t think that’s the right question. What to TLD operators want?
>

What has changed is the start of some Registrars taking on the role of
"agent" for Registrants doing DNSSEC.
This mostly applies to CDS/CDNSKEY but might eventually also encompass some
or all of CSYNC (modulo perhaps the update(s) being DNSSEC signed using an
existing KSK).

So, the NOTIFY target could be such an agent (Registrar) who then forwards
the appropriate update to the TLD via EPP.
I.e. the target would not be the TLD itself (directly).

(This is very early in the discussions among experimenters/implementers,
but certainly seems feasible, and might reduce latency on updates and load
on agents.)

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

[DNSOP] draft-klh-dnsop-rfc8109bis suggested text

[Brian Dickson]

I forgot to mention willingness to contribute text.

Here is one suggestion:
Add to section 3 (or under 3.1) text to the effect of:

The recursive resolver SHOULD ensure that the reassembly size advertised is
below the threshold in its immediate network vicinity.
Specifically, if a response with the DF bit set and packet size of the
reassembly size advertised exceeds any MTU, the packet will be dropped by
the network.
This could be the result of the resolver's LAN segment, or its upstream WAN
link(s) within the resolver's ASN, or even an upstream ISP's WAN link(s).

Repeated failures to multiple priming addresses MAY require the resolver to
use a smaller reassembly size in order to receive a response.


This is definitely a corner case (possibly to be included in the
avoid-fragmentation draft as well), but particularly for priming queries,
instances of this failure mode may not be resolved by any other means
beyond reducing the advertised size or retrying over TCP.

Brian

On Wed, May 24, 2023 at 7:04 AM Tim Wicinski  wrote:

>
> Please also indicate if you are willing to contribute text, review, etc.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis

[Brian Dickson]

On Wed, 31 May 2023, Tim Wicinski wrote:

>
> Subject: Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis

>
> This call for adoption ends: 7 June 2023

>
I too am in favour of adoption.

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

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Brian Dickson]

On Fri, May 5, 2023 at 11:46 AM Joe Abley  wrote:

> Hi Peter,
>
> On Fri, May 5, 2023 at 04:39, Peter Thomassen  > wrote:
>
> > Having the delegating party check for service for the requested zone
> > at time of delegation request and refuse to update / register if
> > this check fails
>
> It would be interesting to develop a consensus position on acceptance
> checks for delegations. (Obviously, that's out of scope for this draft, so
> renaming the subject.)
>
>
> Pre-delegation checks add friction to the domain registration process.
> They further complicate the commuications between different actors in the
> commercial graph (registrars, registries, resellers, DNS operators, hosting
> companies) and introduce delay and manual intervention into what might
> otherwise be a fairly automated or at least automatable process. That is
> to say, checks have a cost, and that cost might well be difficult to sell
> in a commercial environment, especially one where the policy depends on a
> membership that is often quite commercially motivated. (I appreciate not
> all TLDs are the same.)
>
> The ability to arrive at a consistent universal policy across many
> different policy regimes seems like a bit of a long shot. Some early
> adopters of increased friction will be at a commercial disadvantage to late
> or never-adopters of the same kinds of checks. This disadvantage will
> provide further disincentive to adopt this kind of check for those
> registries that are commercially-motivated. (I appreciate not all TLDs are
> commercially-motivated.)
>
> So even if a clear technical best current practice could be published, I
> think there would be considerable work to do in seeing it implemented. I
> presume implementation is desirable, otherwise we're just navel-gazing.
>
> On the technical side, I think arriving at a generalised approach will be
> difficult. For example,
>
> 1. Repeated checks
>
[snip]
There is also the notion of indirect checks vs direct checks, with
reporting/signaling/scaling elements.
I think the work on trust anchors (done for gathering information to inform
the root key rollover) would be one relevant example to consider.
Other work (recent or in progress) related to reporting to domain operators
(don't recall draft or rfc identifiers) would also be useful to examine.

3. Deliberately-incoherent namespaces
>
[snip]
This is definitely something that any proposal should accommodate. One
approach would be looking at opt-in vs opt-out mechanisms, possibly
anchored under the namespaces of NS names.
Scaling for all of these sorts of mechanisms is also very important, given
that the first priority of the DNS system is answering queries, and
anything that impacts performance needs to be tempered appropriately.


> To look at it another way, why would we give authority to a third party to
> break our domains just because they are not fully-informed about how we are
> using them?
>

This is an important consideration, for sure.

I think any proposals should start with a couple of things;

   1. Identifying what parties are interested parties and/or involved
   parties. Depending on specifics the number could be large, but in the
   general case there is a minimum number of parties that are necessarily
   involved. Enumerating those, and what their roles in would be a good place
   to start.
   2. Determining authority tied to those parties and their roles. The
   canonical example would be the operator of a name server, should be
   involved in decisions about whether or not a given delegation should be
   allowed when the domain is not served by the name server.



>
> And lastly, even if a delegation is genuinely broken and useless for all
> the world, and nobody cares enough to fix it, what harm does it do? What is
> the motivation to find a fix? A dribble of extra traffic relating to a
> mainly-unused domain to a nameserver that is already over-provisioned
> doesn't seem very compelling.
>

This is where I can add some useful data and context.
Operators of substantial numbers of zones where this traffic is received
are able to quantify the impact.
At the servers under domaincontrol dot com, the normal traffic is over 15%
queries for domains not served (i.e. lame zone delegations). That is a lot.
Additionally, lame delegations are abuse vectors. We see much abuse via
this vector.
And lastly, the current state of affairs is that we are unable to directly
affect this, since the RRR model does not include a role for DNS operators.
(We are also a Registrar, but when the domain has a different Registrar
than us, the RRR rules do not facilitate us removing lame delegations to
our name servers.)

I do have some ideas on mechanisms, but those probably belong in their own
thread.

I.e. the issue isn't specifically "pre-delegation checks", it is
"delegation correction".


> Even if I thought this was a problem that needed a solution, I don't think
> the solution is likely to be easy. The technical aspects are 

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

[Brian Dickson]

George is (of course) right.

I think the following set of definitions might be useful to consider.

Lame server: older language used to describe a "lame zone server".
Lame zone server: a server listed in the NS set for a zone, which is not
providing authoritative answers for said zone.
Partially lame domain (partially lame zone): a domain (zone) for which at
least one server is a lame zone server.
Completely lame domain (completely lame zone): a domain (zone) for which
all of the servers are lame zone servers.
Lame domain (or lame zone): a partially lame domain (partially lame zone)

(Feel free to augment or substitute as needed).

Brian
P.S. This might be a good time to suggest alternatives for "lame", at least
in this context. I.e. include "lame" but suggest the new term as a
substitute.


On Thu, May 4, 2023 at 5:34 PM George Michaelson  wrote:

> When people talk about "lame" they're in a sentence with a subject
> (the DNS), and an object(ive) -But there isn't a single parse. Sorry,
> but the declarative "this is what it means" seems to me to be failing,
> hard.
>
> The subject(s) are the zone(s) that are lame? thats one case. the
> other case, is the subject is the NS which is listed as authoritative
> but isn't serving. OK so you can qualify "lameness" to "the zone is
> lame" or "the zone has some lame NS" or "this NS is lame for the zone"
> -But they have different subjects and objects. what is "this" in each
> case? different.
>
> And not serving has (at least) two forms: you respond to 53 but reply
> incoherently if at all about the zone, and you aren't even responsive
> on 53. I can believe there are more.
>
> The objective is to fix it. You are either talking to the parent zone
> delegates to get something changed in the parent zone, or to the zone
> NS admin to get something changed at the NS, or to network technicians
> about why something along the path isn't working for you. So thats 3
> cases at least.
>
> Yet, we all seem to call this "lame" for some purposes. At least 2x
> who talked to, at least 2x forms, and at least 2x subjects but one
> Objective: -- fix it.
>
> I don't think we've cohered on a meaning. I respect Paul Vixies intent
> in giving clear origination of the term to Mark, but I do not agree
> the term means now what he said decades ago, its clear we don't (in
> this mail thread) really have a unitary meaning. If we did we wouldn't
> be here.
>
> I don't see how a single paragraph statement without OR ... alternates
> is going to cover what people patently have been saying "is lame" for
> some time, not aligning to a single meaning.
>
> I liked the proposed paragraph because it had the ".. or not at all"
> -And yet some people seem determined to say thats the "wrong" bit on
> the definition.
>
> ___
> 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] WGLC for draft-ietf-dnsop-zoneversion

[Brian Dickson]

Top-reply (to avoid adding to confusion by attempting to add in-line
commentary of uncertain value):
I also agree that this is very valuable and definitely helpful for
diagnostics.

I think there are a number of edge cases, for which disambiguation might be
helpful.
Apologies if this seems to add complexity, rather than the desired clarity
on responses.

The general edge case would be where a response includes multiple RRsets,
which could be from different zones on the same server.
Currently that would potentially occur if the response had CNAME, HTTPS, or
SVCB records in addition to the RRTYPE matching/corresponding to the QTYPE.

E.g. query: QNAME = foo.example.net, QTYPE = A;

response contains
foo.example.net CNAME bar.example.com

bar.example.com A {example IP address}

# server is authoritative for example.com and example.net, serves both zones
# ZONEVERSION for both zones is valuable for diagnostic purposes



Similarly, the Additional section could have records from multiple zones
(served by the same server), possibly (I think, maybe more likely
with HTTPS or SVCB responses).

The disambiguation I'm about to suggest would uniquely identify an RRSet in
the response by the location in the response message of the first record.

With the proposed (below) disambiguation, it would then be possible to
include multiple ZONEVERSIONs.

The simplest way would be one ZONEVERSION per RRset.
(There are other ways of having a single ZONEVERSION reference multiple
RRsets, but I think that would be needlessly complex at that point.)

If there are multiple RRsets from multiple zones, it would be necessary to
specify the zone that corresponds to the ZONEVERSION for each RRset.

Everything beyond this probably falls into the "bike shed" category.
(Which method to implement any element is much less important than the
existence of some method.)
E.g.

   - Identify the first RR of an RRset:
  - 2-bit section (0,1,2,3 for query, answer, auth, add) plus RR
  ordinal (e.g. 1st RR in the section)
  - compression pointer
  - something else ???
   - Identify the zone that the ZONEVERSION applies to (i.e. the RRset):
  - label count
  - compression pointer to domain name of zone
  - uncompressed domain name of zone (no pointers)
   - (plus the actual zoneversion, and any flag(s))

I think even in the single RR response this addresses Joe's issues, and
allows the recipient to distinguish parent/child side of zone cuts (for NS
records).

Brian


On Thu, May 4, 2023 at 1:58 PM Hugo Salgado  wrote:

> Hi Joe, thanks for your comments. Answers inline:
>
> On 14:16 27/04, Joe Abley wrote:
> > On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On
> Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote:
> >
> > > This email begins a Working Group Last Call for
> draft-ietf-dnsop-zoneversion-02 (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
> > >
> > > If you've reviewed this document and think it's ready for publication,
> please let us and the WG know, by responding on-list to this message. We
> particularly need to hear from implementers and operators whether this EDNS
> option is implementable and useful.
> > >
> > > If you don't think it's ready, and have specific concerns or
> suggestions, please let us know about those too.
> > >
> > > The Last Call will be two weeks, ending on Thursday 11 May.
> >
> > As I think I have said before, I like this idea and I think it is
> genuinely useful. The draft is well-written and mainly clear but I have
> some observations. I think some additional work would be beneficial before
> we raise the draft up the IESG flagpole.
> >
> > In section 1 I see "Resolver and forwarder behaviour is undefined".
> However, in section 3.2 the specification says that if various conditions
> (including "server that is authoritative for the zone") are not met, the
> answer "MUST NOT add an EDNS ZONEVERSION option to the response". This
> seems inconsistent; 3.2 in fact does in fact seem to define the required
> behaviour for at least some resolvers and forwarders (those that are not
> also authoritative servers).
> >
>
> You're right. That undefined behaviour for "not authoritatives" seems
> to be a source of concern. Maybe we can just drop that introductory
> phrase, wich otherwise talks about the transitive nature of EDNS
> options.
>
>
> > The draft refers to "the zone" in various places, as in one of the
> sentences quoted above. I think it's fairly obvious what this means, but I
> don't think it would hurt to be a little more specific about it. After all,
> if the whole point is to identify something specific about a zone, wouldn't
> it be good to be clear about which zone we are talking about? Should the
> option included in responses include the identity of the zone explicitly?
> >
>
> In the document, the first time we mention zone is "... with a
> token field representing the version of the zone which contains the
> answered Resource 

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

[Brian Dickson]

On Mon, May 1, 2023 at 12:55 PM libor.peltan  wrote:

> Hi Paul,
>
> if you really ask for opinions, here is mine.
>
> Considering the recent voluminous discussion about the meaning of Lame
> delegation, it seems to me that there are at least several people being
> more-or-less sure what the term means, with the issue that everyone
> thinks something slightly (or less slightly) different.
>
> A word that means something different according to each speaker is not a
> good communication tool. I'm afraid (but not sure) that we should rather
> avoid it to prevent present and future misunderstanding.
>
> In order to do so, I'd suggest treating it similalrly as the term
> Bailiwick: abandon the word and make up a new, precisely defined term
> that means the same for everyone. But I don't insist.
>
>
Libor has a good point (and similarly, I don't insist.)

I think, in fact, more than one term may be needed, since there are
distinct situations involved:

   - One situation is where at least one (but not all) parent-child NS
   targets do not respond authoritatively.
   - Another situation is where none of the parent-child NS targets respond
   authoritatively.


The latter is something I think that needs to be addressed, separately, by
the DNSOP WG.
(I have some ideas around that, but won't clutter this discussion with
those.)

Brian


> Dne 01. 05. 23 v 18:09 Paul Hoffman napsal(a):
> > It would be grand if a bunch more people would speak up on this thread.
> >
> > --Paul Hoffman, wearing my co-author hat
> >
> > On Apr 27, 2023, at 1:05 PM, Benno Overeinder 
> wrote:
> >> Dear WG,
> >>
> >> The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
> >> on lame delegation did not find consensus, but two specific suggestions
> >> were put forward.  We would like to include one of them in rfc8499bis if
> >> we can get consensus to do so.
> >>
> >> The chairs are seeking input on the following two suggestions:
> >>
> >> * Either we leave the definition of “lame delegation” as it is with the
> >>   comment that no consensus could be found, or
> >>
> >> * alternatively, we include a shorter definition without specific
> >>   examples.
> >>
> >> 1) Leaving the definition of lame delegation as in the current
> >>draft-ietf-dnsop-rfc8499bis, and including the addition by the
> >>authors that:
> >>
> >>"These early definitions do not match current use of the term "lame
> >>delegation", but there is also no consensus on what a lame delegation
> >>is."  (Maybe change to ... no consensus what *exactly* a lame
> >>delegation is.)
> >>
> >> 2) Update the definition as proposed by Duane and with the agreement of
> >>some others (see mailing list
> https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):
> >>
> >>"A lame delegation is said to exist when one or more authoritative
> >>servers designated by the delegating NS RRset or by the child's apex
> >>NS RRset answers non-authoritatively [or not at all] for a zone".
> >>
> >> The chairs ask the WG to discuss these two alternative definitions of
> >> the term "lame delegation".  We close the consultation period on
> >> Thursday 4 May.
> >>
> >> Regards,
> >>
> >> Benno
> > ___
> > 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, Apr 26, 2023 at 8:43 AM Shumon Huque  wrote:

> I support adoption too.
>
>
Me too. Support. Happy to review or contribute. (Not a lie.)

Brian


> 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.
>
> On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski  wrote:
>
>>
>> Happy Monday (UTC) All,
>>
>> The chairs heard some strong support to adopt and work on this.
>>
>> This starts a Call for Adoption for draft-huque-dnsop-compact-lies
>>
>> The authors did do some updates in the draft around the "lies" moniker.
>> Once adopted perhaps someone can suggest a better draft name.
>>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and send any comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: April 29, 2023
>>
>> Thanks,
>> tim wicinski
>> For DNSOP co-chairs
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Meaning of lame delegation

[Brian Dickson]

(Incorporating but not quoting various other responses in this thread,
implicitly, based on the dates they were sent.)

On Mon, Apr 3, 2023 at 1:02 PM Wessels, Duane  wrote:

> Dear DNSOP,
>
> I am participating in an SSAC work party where we are writing about DNS
> delegations where a delegated name server might be available for
> registration, allowing an attacker to participate in the resolution for the
> domain.  During report drafting we considered using the term "lame
> delegation" to describe this and a broader class of delegation problems.
>
> Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not
> particularly helpful since it simply quotes previous, imprecise uses of the
> term:
>
>Lame delegation:  "A lame delegations exists [sic] when a nameserver
>   is delegated responsibility for providing nameservice for a zone
>   (via NS records) but is not performing nameservice for that zone
>   (usually because it is not set up as a primary or secondary for
>   the zone)."  (Quoted from [RFC1912], Section 2.8) Another
>   definition is that a lame delegation "...happens when a name
>   server is listed in the NS records for some domain and in fact it
>   is not a server for that domain.  Queries are thus sent to the
>   wrong servers, who don't know nothing [sic] (at least not as
>   expected) about the queried domain.  Furthermore, sometimes these
>   hosts (if they exist!) don't even run name servers."  (Quoted from
>   [RFC1713], Section 2.3)
>
> The first appears to assume that the name server exists, while the latter
> parenthetically notes the name server might not exist, but without any
> specific meaning of existence.  We are wondering if the idea of a lame
> delegation should be interpreted broadly, or more narrowly to include only
> cases where a response is proof of lameness.  Consider a delegation of the
> domain EXAMPLE.NET to name server NS.EXAMPLE.ORG.  There are three
> possible situations in which this might be considered a lame delegation:
>
> (1) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP address
> result in a REFUSED, SERVFAIL, upward referral, or some other indication
> the name server is not configured to serve the zone.
>
> (2) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP address
> do not elicit a response (e.g., timeout).
>
> (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is nowhere
> to send a query.
>
> We welcome the working group's thoughts whether "lame delegation"
> encompasses these three possibilities.
>

There is one important situation which may or may not fit within any
current definition, or which might need its own term:

   - Totally Lame

This is the situation when all of the delegations from the parent are made
to servers which collectively are not authoritative for the domain.

This is something that unfortunately occurs more frequently than one would
hope. (An absurd fraction, 15%, of traffic we see falls into this category.)

The responses we send to these queries are "Refused", with EDE of "Not
Auth".

These are non-transient situations. All of the servers listed no longer
have a relationship with the domain owner, and none of the alternative
response codes are appropriate or legitimate.
(The server receiving the traffic does not and cannot know why it is
receiving the queries, so a partially lame set of delegations where some of
the delegated servers do answer, means NXDOMAIN is the wrong answer, for
example.)

The absence of DNS operators from the RRR model is one of the fundamental
problems. There is no feedback mechanism to the delegating servers
available directly from the DNS operators to get the broken delegation(s)
removed permanently.

So, when discussing this general subject matter, it is probably a good idea
to keep this common corner case in mind.

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

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[Brian Dickson]

On Fri, Feb 17, 2023 at 4:06 PM tjw ietf  wrote:

> John
>
> Paul is right. As an operator one thing I always obsess on in is the data
> in my zones.  Why is it there , should it be, etc. Another example you may
> understand is “who created this incorrect DMARC record?”
>
> I’ve given them much much feedback. I am eager for others to sound off.
>
> And Brian, I appreciate your comments but i do wish you read the drafts as
> well.
>
>
Sorry, busy day with DNS-OARC, and $day-job .

Have read the draft, and my comments are no different.

BTW, there is a related (dove-tailed) thing, which is a de-facto
"standard": Domain Connect (DC).
DC is something that was developed at my employer, but maintained by a
wider community.

DC provides an interoperable mechanism for providers of services which need
DNS entries, to supply the domain owner (registrant) specific parameters
and a reference to a template to a DNS operator. The domain owner
authorizes the update to their DNS (via authenticating to DNS provider),
and the DNS provider processes the resulting record set and adds it to the
zone.

DC templates generally are of the key/value pair structure, with the
"value" typically being specific to the customer, such as a validation
string.

So, not only do I agree with the proposed draft, I specifically note that
having this BCP will work with DC, and that the two things both make it a
lot easier for actual end users (who no longer need to copy and paste at
all).

BTW, one of the tasks I currently have at $day-job is to pick up the
expired draft for domain connect, find the correct home for it (possibly
here), and get it to a usable state that can be published (one way or
another... informational, experimental, or standards track; independent
stream or WG.)

As I said, it is in use with a fair number of DNS providers and a larger
number of providers of services (such as email, web hosting, etc.) More
info for those interested (including the expired draft specification) are
at domainconnect.org.

Brian


> Sent from my iPhone
>
> > On Feb 17, 2023, at 18:47, Paul Wouters  wrote:
> >
> > On Fri, 17 Feb 2023, John R Levine wrote:
> >
> >> Surely we know people who run services that use DNS validation.  How
> about talking to some of them and finding out what kind of user errors they
> run into?
> >
> > The insinuation here is that we didn't talk to them. One of the authors
> > is at salesforce, who is a big deployer of this. We talked at a number
> > of IETFs to various people and listened to them. One of the dnsop chairs
> > also has quite some experience in this field and read previous drafts
> > and gave us advise from their viewpoint.
> >
> > But also, the pain is not felt at the people who dictate how to use
> > their DNS validation scheme. It is with the DNS administrators finding
> > a bunch of unrecognisable DNS records and not knowing what the hell
> > they are for and whether they can or should be deleted. Or those admins
> > that now see their APEX going back to TCP (yes dig txt cnn.com gets TC
> > and falls back to TCP)
> >
> >>> (Caveat, I'm responding to this thread, not to the actual draft since I
> >>> haven't recently read it.)
> >>
> >> It's not very long, should take about 5 mins to read.
> >
> > Its a feature. We try to keep it simple and clear and easy to follow.
> >
> > And not present people with a number of mostly equivalent ways of
> > doing the same thing. In the end, it is a BCP. If you want to insist
> > on using randomized prefixes with CNAMEs, make your day.
> >
> > Paul
> >
> > ___
> > 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters  wrote:

> On Mon, 24 Oct 2022, Brian Dickson wrote:
>
> > Just to expand on this idea (which I quite like), the original AS112 was
> enhanced to handle new/arbitrary names, so
> > that AS112 operators don't need to do anything to support being a sink
> for new domains.
> >
> > This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
> target for use via DNAME.
> > (The DNAME bit is so there isn't a delegation for which the AS112
> operator would need to have a zone configured.)
> >
> > Using this via the root zone would be a new kind of entry for the root
> zone, but is otherwise non-controversial
> > (IMHO).
> > It would basically look like:
> >   alt. DNAME empty.as112.arpa
>
> this is dangerous. Anyone who runs an as112 node, or an attacker who
> compromises one, can then serve a "real" .alt to a percentage of
> queriers. Imagine millions being lost in some cryptocurrency .alt
> non-dns scheme.
>
>
This is accurate. It is dangerous to other namespaces if they don't take
appropriate safeguards.

What this points out is that ".alt" is intended to protect DNS (at the root
at least) from the effects of other namespaces.

It is not (or at least has not been explicitly established for) use by
other namespaces to protect themselves from errors like this.

In the jargon of mathematics, "alt" is necessary, but not sufficient.

Any namespace that would fall under the "please use .alt" umbrella, would
be wise to build into the protocol(s) or implementation(s) some guard-rails
against leakage.

So, another reason for "MUST NOT", but perhaps out of scope for dnsop
itself to say (other than to indicate,  "here be dragons".)

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

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

[Brian Dickson]

On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie  wrote:

>
>
> 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.
>
>
Just to expand on this idea (which I quite like), the original AS112 was
enhanced to handle new/arbitrary names, so that AS112 operators don't need
to do anything to support being a sink for new domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
target for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root
zone, but is otherwise non-controversial (IMHO).
It would basically look like:

alt. DNAME empty.as112.arpa

Any query for foo.alt would be rewritten by the resolver doing resolution
to foo.empty.as112.arpa, which would result in an NXDOMAIN from the
topologically closest AS112 instance.

(Separate conversation that might be time to raise: is it time to sign
empty.as112.arpa, so these NXDOMAIN results have full DNSSEC proofs, and to
enable aggressive NSEC support on resolvers?)

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

[DNSOP] URI (scheme or other) future work (was Re: [Ext] Possible alt-tld last call?)

[Brian Dickson]

On Mon, Oct 24, 2022 at 7:18 AM Ben Schwartz  wrote:

>
>
> On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear  wrote:
>
>> Hi Ben and Wes,
>> On 21.10.22 20:45, Ben Schwartz wrote:
>>
>>
>> Rather than placing "alt" in the TLD position, I think it might be better
>> as a scheme modifier: https+alt://...  This is a common pattern  for
>> modifications to URI schemes (c.f. git+ssh://), and informs the software
>> that this URI is special without overloading the DNS namespace.
>>
>> How would this work in practice?
>>
> Thinking about this more, I can imagine having both "+alt" and ".alt".  In
> this world, ".alt" would be for "the system's alternate DNS root",
> providing DNS-equivalent functionality but not in IANA-controlled space.
> "+alt" would be for "the system's alternative interpretations of URI
> schemes", with no further requirement that the authority be domain-shaped
> at all.
>
>>
>>- Would this require a re-registering of each and every URI scheme
>>with +alt, and monitoring the URI scheme registry for new ones?
>>
>>  I don't think so.  We could define it as a universal scheme modifier.
>
>>
>>-   (I'll note that git+ssh isn't registered.)
>>
>> Unfortunately, most URI schemes outside of the RFC process are not
> registered.  I think there's a general lack of awareness that registration
> is required or easy.
>
>>
>>- What is the value of +alt at this point?  Why not use +gns or
>>+onion or +eliotsfavoritenamespace?
>>
>> That sounds like a very intriguing idea, and might be better than +alt.
>
>>
>>- How might or should this be reflected in the browser bar?
>>
>> Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
>

 As noted by Timothy Mcsweeney in the original thread, sub-delim characters
are not permitted in the scheme.

However, my view on potential parsing and encoding is something that the
current URI specification already supports.

I think the namespace indicator definitely is something that should be
coupled with the "authority" portion of the URI. We're talking about how to
resolve the host portion of a URI, and while that might be expanded outside
of DNS, the URI spec already lists other non-DNS ways that a name might be
resolved. In Seciton 3.2.2 (Host) of RFC 3986) and specifically and
explicitly supports whatever is needed by resolution mechanisms in the
"reg-name" syntax, with the expectation that parsing and resolving a
"reg-name" is handled outside of the scope of URI parsing, so long as the
extraction of the "reg-name" works (i.e. that "reg-name" complies with the
URI specification).

And "reg-name" is essentially the normal characters from DNS, plus
"sub-delim" characters.
That list of characters includes the "!" character, which I think would
best enable encoding to indicate new name systems, e.g. using GNS as an
example:
gns!some.gns.name.gns.alt
(The suffix gns.alt is to ensure that if for any reason leakage to DNS does
happen by the GNS resolver, it won't get a real DNS answer. Yes, that is
redundant, but by design.)

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

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

[Brian Dickson]

On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie  wrote:

>
>
> 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?)


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.

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)

What I mean by the term "DNS-friendly" is: includes specification-defined
guardrails against collisions, squatting, land rush, abuse, etc., is opt-in
(delegation or namespace won't work unless hosts or software have
explicitly enabled functionality), and can't be used as a global free
end-user registry of domains that work from unmodified clients/resolvers.

Mostly the different anchor points are required due to different DNSSEC
policies (which are needed to prevent bad end-user experiences for leaked
queries with respect to "alt", or are need to enable experimentation
without getting blocked by validating resolvers).

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

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

[Brian Dickson]

On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie  wrote:

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

That would be an interesting use case, for a different "thing", IMNSHO.

What you describe would be different from the use cases of GNS or other
similar systems, which either have no need to directly coexist with the
ICANN-root DNS, or enable name conflicts by overloading DNS without
enforcing guard rails.

I think your suggested carve-out would need a different anchor point in the
DNS namespace, might need a registry, and if a registry were created, would
need very strict enforcement on the cooperative augmentation to DNS by
those things.

I don't think the suggested carve-out fit into the current proposed draft
(alt-tld), but would probably be a similar document, possibly simple in
nature and as long as alt-tld was published first or at the same time,
would avoid land-rush issues or abuse.

As to what place to put the carve-out, I think its requirements would be
quite similar to the homenet thing, which has 'home.arpa'.
So, maybe 'alt.arpa' with insecure delegation (which would facilitate both
adding trust anchors and/or having local namespaces that are intended to
sit underneath the alt.arpa namespace safely)?

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

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

[Brian Dickson]

On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear  wrote:

> Hi,
>
> First, I would like us to continue to consult on the registry matter at
> least through the London IETF, and would ask the chairs for some time in
> London for this purpose.  I would also be available for side meetings
> with any interested party, before or during the IETF.  If people would
> like, we can grab a room for this purpose, if we can do so in the
> morning so that Martin can participate remotely (he is far to the east
> of London).
>
> As a matter of practicality, a registry surely will be form.  It is
> simply a matter of whether the IANA will host it.  If the IANA does not
> host it, then by shifting it elsewhere this group is actually weakening
> the IANA function, and that would be sad.
>

I spent quite a bit of time in the last couple of days reading all the
threaded posts, as well as the two relevant drafts: the alt-tld one, and
the gns one.

The latter (quite a large document, with lots of important nuances
including additions related to dotALT conceptually) has some major
challenges for whether/how it would even fit in such a registry.

I fear those challenges mean that GNS simply won't be possible to properly
have registry entries, and without GNS, or possibly using GNS as an
alternative namespace example, the registry makes no sense.

Here's the problem that the GNS draft includes (and maybe doesn't highlight
well enough): GNS is not a namespace. There is no central administration of
namespace(s) under GNS, or even a central anything. GNS has no global
"anything", and no concept of global per se. At best, entities can publish
their own equivalent of "root zone"s that assert to a population of
consumers as to what namespace entities exist, without any authority over
any aspect of namespaces. It is anarchy embodied.

Everything in GNS relies on mappings, and "petnames". While those can
potentially be placed under some parent label, the existence of such a
parent label (either ".alt" or ".gns.alt") is neither necessary nor
sufficient to achieve any kind of global consistency.

There is also no ability to enforce any rules on using any parent label, or
to prevent conflicting intra-GNS "petnames", or to prevent conflicts
between GNS "petnames" and any other TLD namespaces (including DNS). GNS
allows anyone (with local context) to instantiate any namespace (tree
anchored anywhere), including instantiating new TLDs (contrary to ICANN's
current role as exclusive entity responsible for administering the DNS
namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs,
or anything beneath those.

The question that hasn't been addressed is, who SHOULD actually do
registrations in this proposed registry?
I don't believe the authors of the GNS draft have the actual authority to
do so, as they do not administer any name space per se.
If someone did want to instantiate a local namespace, or a kind-of, sort-of
bigger-than-local namespace (with delegations) as the GNS draft generally
describes, would they be the entities registering their namespace?
Those namespaces are not required to be unique within GNS, as well, so even
having an FCFS registry would not mirror the reality of GNS. There could
easily be 1000 different instances of "lotr.gns.alt" within GNS, each with
its own zone(s) with names like "frodo", "bilbo", "gandalf" etc.

And if the GNS draft isn't included in the registry (because it does not
administer ANY namespace), I don't see how the registry can function as
envisioned.

It may possibly be reduced to definitions: what is a namespace? If it is
not something that is global and consistent, I don't think it could
accurately be called a namespace.

It basically suffers from the "Woody Allen" problem ("I wouldn't want to be
a member of any club that would accept me as a member.")
Creating a registry as a place to put GNS would be self-contradicting if
GNS cannot be added to the registry.

Brian



>
> Two more points below.
>
> Paul wrote:
> >
> >> This proposes two significant changes to the draft: make the registry
> FCFS and make entrance to it be by RFC. Those are both pretty heavy-weight
> for things *that are not part of our naming system*.
>
> Heavy for who?  Those wanting to create an entire naming systems for the
> Internet?  Look, from my perspective I am comfortable with ANY registry
> policy.  I've already provided a number of options to put the brakes on,
> if people are worried about a sudden rash of people building entire new
> name systems for the Internet.  So let's discuss.
>
> Martin followed up to Paul:
>
> >>   I strongly prefer "drop the registry" and let the non-DNS folks
> figure out how to deal with their own issues. After you see the next draft,
> if you think the registry with your two changes is needed, you can propose
> to add it back in.
> >>
> > The consequence of this (and I am looking at ISE here) will be that our
> > document will not be able to clearly define how to "use" alt as 

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Brian Dickson]

On Wed, Oct 19, 2022 at 12:22 PM Tim Wicinski  wrote:

>
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
> The Current Intended Status of this document is: Informational
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  2
> November 2022
>
>
Here are some suggested additions to the document, both general, and where
appropriate, more specific in nature.

It may seem obvious to those familiar with operating DNS servers (resolvers
and authority servers), especially in the context of DNSSEC, but given
recent operation experience, I think the following need to be highlighted
explicitly, possibly in a new section (e.g. immediately after section 12 in
the document):

DNSSEC validation requires that the validator is able to reliably obtain
necessary records, especially DNSKEY records. This should be done at
initial configuration, and tested periodically.

This means the validator MUST ensure it is configured so that the UDP and
TCP transports, and DNS resolver components, are compatible with the
network paths that the majority of DNS queries traverse.

In other words, make sure that:

   - DNS UDP bufsize (EDNS parameter) is set to a value compatible with
   network MTUs the queries and responses will encounter.
  - If the validator advertises a bufsize >> MTU, responses with the DF
  bit set and response size R where MTU < R <= bufsize will be
dropped by any
  router with MTU < R.
   - The validator's OS TCP configuration has its advertised MSS set to a
   value compatible with network MTUs the queries and responses will encounter.
  - Having an advertised MSS set to a value < MTU ensures that Path MTU
  Discovery is not required
  - If PMTUD fails for any reason, or if the server responding does not
  maintain or use PMTUD, and advertised MSS > MTU at any point in the path,
  TCP may encounter problems caused by IP fragmentation and reassembly.
  - This is particularly relevant if there are any NAT type devices in
  the path, as those may not properly handle fragmentation and reassembly
  - If all TCP segments are smaller than the path MTU, TCP will work
  reliably.

We (GoDaddy) recently investigated a number of problems where the root
cause was one or more of the above situations.
While we have adjusted some of the server-side parameters, those can only
accommodate clients within an acceptable range of MTUs that we anticipate
will occur.
The avoidance of fragmentation in order to address known
fragmentation-related security issues with DNS (leading to cache poisoning,
for example) has resulted in the need to set the DF bit on UDP.
Validators will need to ensure their local environment can reliably get any
critical DNSSEC records (notably DNSKEY) over UDP, or reliably get
responses with TC=1 if overly large responses cannot be sent over UDP due
to answers not fitting within the advertised bufsize payload.
Validators also need to ensure TCP works if it is needed, for the same
situations.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Brian Dickson]

Quick meta-question:

If there is new information that would suggest additions to the document as
helpful (improves document), which would be the normal or best approach:

   - Ask for additions to the document during the WGLC itself
   - Offer comments on the addition alongside a request to delay the WGLC
   until the authors have had a chance to review/respond to the comments
   - State the opinion that the document is not ready for publication,
   based on the comments

Brian

On Wed, Oct 19, 2022 at 12:22 PM Tim Wicinski  wrote:

>
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
> The Current Intended Status of this document is: Informational
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  2
> November 2022
>
> thanks
> tim
> ___
> 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] Possible alt-tld last call?

[Brian Dickson]

On Sun, Oct 16, 2022 at 8:03 AM Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any effort to move the draft forward.
> (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>

Having re-read this draft, and having re-read 6761, I think that "alt"
should NOT be added to the SUDN.
The logic is that the SUDN is for DNS domain names only, and "alt" is
explicitly for non-DNS names.
(Even though it is tempting to include "alt" to give information to those
wanting to do non-DNS names, it's still probably best to not do that, IMHO.)


>
> First, this creates a process problem in that RFC 6761 is the
> standards-track document that specifies how the SUDN registry is to be
> administered, so a request that doesn’t meet the requirements in 6761 can’t
> (or at least shouldn’t) go into the registry.
>
> RFC 6761 section 4 asserts:
>
> The specification also MUST state, in each of the seven "Domain Name
> Reservation Considerations" categories
> below, what special treatment, if any, is to be applied.
>
>
> The alt-tld draft ignores this MUST, without explanation (unless I missed
> it).
>
> The substantive issue is that the questions in Section 5 are there to make
> sure there’s a full description of the expected handling of a proposed name
> by the assorted components that take part in DNS operations and protocol.
> The draft answers at least some of the Section 5 questions, but the answers
> are largely implied.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>

I think there should be some instructions to parties wanting to implement
non-DNS name systems on additional requirements or anti-requirements, to
further reduce the likelihood of queries reaching DNS servers.
Specifically, I think having words to the effect of, "Alternative
namespaces SHOULD NOT (or MUST NOT) use the port numbers reserved for DNS
(including but not limited to 53 and 853)."

If they are not DNS they need to not be DNS. Private DNS is still DNS,
which is semantically different from alternative namespaces.
DNS resolvers are expected to be able to handle public and private DNS
names. Alternative namespaces have the potential to collide with DNS names.
As such, resolvers should be DNS or not-DNS, but never both.


>
> So, the current draft isn’t meeting the requirements for the registry, and
> also doesn’t clearly answer substantive questions about what DNS operators
> are expected to do. This makes me uncomfortable doing a WGLC without a new
> rev. It would be Rob Wilton’s call of course (as AD for this draft,
> substituting for Warren) but I’m really uneasy with a WGLC without those
> changes— they seem rather too large to punt for a post-WGLC version.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> basis that having the IETF “recognize” (if only by recording) such
> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> supposed recognition of alternate (non-DNS) namespaces as reservations of
> the namespace from the shared, common DNS root. We’re still being denounced
> in certain corners for .onion. It might be good to have a paragraph calling
> out specifically why .alt is not a delegation of a TLD from the DNS root by
> the IETF, even though it looks like one. (We didn’t invent this problem,
> because we didn’t make the decision that top-level domain labels should be
> used by other protocols in a way that led to confusion. But let’s not
> propagate it.)
>

If each alternate namespace uses its own port numbers, there would not even
be a need for any SLD for any such namespace.
Using the "alt" RML (rightmost label) would still be a good thing to
recommend so DNS has some ability to recognize and reject lookups for other
namespaces.
(I.e. use a belt and suspenders philosophy)


>
> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” 

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

[Brian Dickson]

Speaking only for myself (and definitely not for my employer, GoDaddy)...

On Sun, Oct 16, 2022 at 11:45 PM Eliot Lear  wrote:

>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> > Basically, .alt is what IETF recommends you should not do, and we
> > should not keep
> > a registry of entries within it.
>
> We cannot assume that DNS will forever be the only Good approach and
> that all others will forever be Bad. Given that, we as a community are
> obligated to search for better, and to try new things.  As I wrote
> earlier, I do not know that GNS will succeed. I do hope and expect that
> the community will learn something from some deployment experience of
> that protocol so that the next one can be better.
>
>
I think that the concerns of namespace and root(s) is essentially this:

   - The Domain Name System has the ICANN Root as its source of legitimacy,
   and the IETF as its standards body.
   - Other namespaces need to be effectively "ships in the night" with
   respect to The Domain Name System
  - This means no interoperation between "not-DNS" and "DNS" at a name
  space layer.
  - Specifically, as long as any other name resolution scheme has no
  overlap with any portion of the DNS tree, what names that other system
  contains is a moot point (even if they superficially appear to collide)
   - The alternative (allowing non-DNS services to also directly
   incorporate the DNS tree) has a high likelihood of causing user confusion
   or worse.
  - Any alternative systems should stand entirely on their own, and
  their success or failure would be possible to objectively assess.
  - The only place where multiple systems (DNS and any non-DNS) should
  be combined is the same place they have always been,
/etc/nsswitch.conf (or
  equivalent)
   - Experimentation and development of standards can only happen safely
   when unrelated systems don't overlap or conflict.
   - This suggestion would be the antithesis of the "Good vs Bad"
   viewpoint, and IMNSHO consistent with what DNSOP does already.

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

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

[Brian Dickson]

On Mon, Oct 17, 2022 at 7:12 AM Joe Abley  wrote:

>
> My goal is certainly not to put any brakes on if the effect of that is to
> make things move more slowly. I apologise if that's what I have done in
> suggesting to Brian that semantic-free labels do not fit the problem space.
>
>
And I, in return, apologise for my idea. Clearly, not a good idea, although
maybe useful for discussing concepts, and reaching conclusions about such a
registry.

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

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

[Brian Dickson]

On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear  wrote:

> Hiya!
>
> Thanks to Suzanne and the chairs for moving things forward.  On this point:
> On 16.10.22 17:22, Warren Kumari wrote:
>
>
>
>> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
>> basis that having the IETF “recognize” (if only by recording) such
>> pseudo-delegations may serve to attract unwanted attention to the IETF’s
>> supposed recognition of alternate (non-DNS) namespaces as reservations of
>> the namespace from the shared, common DNS root. We’re still being denounced
>> in certain corners for .onion. It might be good to have a paragraph calling
>> out specifically why .alt is not a delegation of a TLD from the DNS root by
>> the IETF, even though it looks like one. (We didn’t invent this problem,
>> because we didn’t make the decision that top-level domain labels should be
>> used by other protocols in a way that led to confusion. But let’s not
>> propagate it.)
>>
>
>
> Yup. This is (IMO) the area of the draft where the consensus was the least
> clear. I still think that it would be useful to have a *purely*
> informational list saying "Group A says it is using string B and their
> documentation is at https://foo.example.com; and "Group X also says that
> it is using string B and their documentation is at https://bar.example.
> net". Enough people have pushed back on asking
> IANA to host this that I think that it should be removed (and I was the one
> most strongly arguing for it). Obviously it's the DNSOP WGs decision, but I
> won't argue for keeping it :-)
>
>
> A few points:
>
> First, absent at least an FCFS registry there will be no ability to
> programmatically switch against the label.  If multiple entries exist this
> is particularly painful.  If no registry exists, then perhaps multiple
> unofficial registries will pop up and we're in the same boat.  Let's not
> have that.  That programmatic switch is important.  It allows multiple
> naming systems to co-exist all the way to the level of the application
> (e.g., end-to-end) without any ambiguity being introduced.
>
> Second, people have been concerned about the possibility of vanity
> registries.  Requiring an RFC puts an end to that.  I don't think we want
> to *endorse* any particular approach, but IANA maintains many registries,
> and nobody has ever taken any of their entries as endorsements.
>
> I suspect most of the burden here will fall on the Independent Submissions
> Editor (currently me) with maybe a little falling on the IRTF, because I
> doubt we will see a lot of consensus in the IETF for alternate naming
> systems.  I think some are worried that this will change the nature of the
> IETF, but to me this confuses names with naming systems.  Creating a naming
> system is no mean fete.
>
> To address the possibility that we DO see a lot of requests, we can create
> different types of failsafe mechanisms.  They could be any or all of the
> following:
>
>1. If more than one assignment occurs within a year, no assignments
>may occur in the following year.
>2. After N assignments, the IAB MAY suspend this procedure if they see
>evidence of abuse, and refer the matter back to the IETF for further
>consideration.
>3. This group can always amend the document based on whatever
>experiences we see.
>
> I'm confident that there are other approaches as well.
>
The main problem that a registry is intended to solve, is the collisions
among apex labels of various alternative naming systems.

This problem is rooted in the "naming system group chosen" aspect.

I think there is a relatively simple technological solution to the naming
system label collision problem.

Consider what the registry would basically consist of:

   - semantic label (what would currently be used as the apex label, e.g.
   "foo.alt")
   - project URI

Note the following characteristics of these elements:

   - The apex label is a "switch", but is otherwise not actually used (or
   meaningful) within the naming system (i.e. it is an arbitrary element, and
   usage is basically limited to a binary "compare" to any input to the
   non-DNS resolution system of the project)
   - The URIs of different systems will, by definition, be distinct (i.e.
   unique to the system)

The obvious (to me at least) solution is to generate the apex label
programmatically, e.g. encode the URI as the label to be used as the
switch, rather than the name system's potentially ambiguous semantic name.
For example, using a hash function, such as sha2-256, with output encoded
as base32hex.
(This is just an example; any suitable function that takes URI as input and
produces an ASCII DNS-compatible label as output would suffice.)

It would still be reasonable to have a registry somewhere of a table of
"name, URI, hashed-URI-label".
The difference is that it would no longer matter what order entries are
added, and collisions cannot occur.

Having two projects that 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-05.txt

[Brian Dickson]

On Mon, Oct 10, 2022 at 9:19 AM Viktor Dukhovni 
wrote:

> On Mon, Oct 10, 2022 at 07:57:45AM -0700, internet-dra...@ietf.org wrote:
>
> > This draft is a work item of the Domain Name System Operations WG of the
> IETF.
> >
> > Filename: draft-ietf-dnsop-dnssec-bcp-05.txt
> > [...]
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bcp-05
>
> I support the latest tweak to first paragram of Section 2, which now
> reads:
>
>What we refer to as "DNSSEC" is the third iteration of the DNSSEC
>specification; [RFC2065] was the first, and [RFC2535] was the second.
>Earlier iterations have not been deployed on a significant scale.
>Throughout this document, "DNSSEC" means the protocol initially
>defined in [RFC4033], [RFC4034], and [RFC4035].
>
> That said, when reading it through, it was not quite clear what "earlier
> iterations" meant.  Are these some hypothetical iterations that precede
> the "first" and "second", or just the "first" and "second" (as
> intended), or all three?
>
> To that end, perhaps a small clarification:
>
> s/Earlier iterations have/The first two iterations had/
>

Alternative suggestion: s/Earlier/These earlier/
(Antecedents in English are one way to remove ambiguity.)

One question about the third iteration itself that I have: Is the mandatory
element "3" (the protocol field in DNSKEY record) related to this being the
third iteration?

It might be helpful to point that out somewhere in this document...

Brian


>
> (The change from "have" to "had" aims to suggest that at this time and
> hence any such deployments are strictly in the past).
>
> This is of course not a critical edit, adopt or ignore at your
> discretion.
>
> --
> Viktor.
>
> ___
> 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] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Brian Dickson]

On Thu, Sep 22, 2022 at 2:05 AM Kazunori Fujiwara 
wrote:

> > From: Petr Špaček 
> >> Then, do you agree the following requirements ? (as DNS software
> >> developpers)
> >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4,
> >> and SHOULD not use FRAGMENT header on IPv6.
> >
> > Theoretically yes, but it might not be achievable depending on OS
> > API. We tried many iterations in BIND, and discovered that APIs (at
> > least in Linux) are horrible and there are traps everywhere.
>
> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
> they often don't work as expected.
>
[...]

> On IPv4, I would like to write it in such a way that "setting the DF
> bit" is an goal, and that OS implementors and DNS server
> software developpers will do their best.
>

We (GoDaddy) have actually had some very recent experience with real-world
situations, and have some results to share.
The TL;DR: of those is: it may not be a good idea to set the DF bit on UDP
if the intention is to improve reliability while avoiding fragmentation,
and interface MTU may need to be set lower.

Here is what we have observed:

   - IF the client and server BOTH have settings (EDNS bufsize and
   server-side UDP max size configuration) that are larger than the real-world
   path MTU end-to-end
   - AND UDP responses have DF=1 set
   - AND UDP responses with TC=1 still exceed the minimum path MTU
   - THEN:
  - Packet-too-big ICMP messages are sent, that are useless/ignored or
  even blocked/dropped by ACLs
  - These over-MTU UDP packets are dropped (because DF=1)
  - The TC=1 response is never received
  - Result:
 - Depending on the DNS software implementation, fallback to
 smaller size UDP or to TCP may not occur
  - Additionally, TCP itself may need to be an in-scope issue for
   recommendations (not sure if it is), specifically because:
  - IF the CLIENT has its configured MSS larger than the smallest MTU
  on the path to the server
 - MSS normally defaults to interface MTU
  - AND the client, server, or path do not enable/support PTMUD (e.g.
  blocking of ICMP packet too big messages, or NAT issues)
  - AND the SERVER sets DF=1
  - AND the first data packet in the response exceeds the actual path
  MTU
  - THEN:
 - TCP will not work (the first packet will never reach the client)

The recommendations might end up being much simpler, as a result.

The only successful approach we have found is to address both the UDP and
TCP issues.
The easiest way to do both of these is to set the server MTU to a lower
value (i.e. whatever value makes sense, based on observed traffic).
And for clients, if the client is aware of a commonly-used network path
with lower MTU, set the client's interface MTU to that value, as well as
configure the EDNS bufsize to that same value (or lower).

It may be the case that DNS software cannot unilaterally achieve these
things, and it may be necessary to check whether those conditions are met.
How the DNS software behaves if the conditions are not met is likely a
question to answer:

   - Is it better to prevent the software from running (give a fatal
   error), or to give a warning (that might be ignored) and run anyway?
   - How can the condition itself be checked (interface MTU vs path MTU vs
   EDNS bufsize)?

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Sep 7, 2022 at 9:09 PM Martin Thomson  wrote:

>
>
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> > won't be legitimate A/ owner names (and shouldn't exist), and if a
> > client did that it would be harmful (to the client), at least a little
> > bit harmful (trying something that won't work.)
>
> (FWIW, I had trouble parsing this last bit.)
>
> Can the AliasMode record reference a name that includes attrleaf labels,
> such that this could be as non-functional as using the attrleaf-laden
> original $QNAME?
>

It can, but that's a different case than the original thing (which will
always have them). Changing the text to handle that would be more
words/sentences than what Warren wants.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman  wrote:

> On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni 
> wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the authority
> > endpoint's port number, and no SvcParams.  (This endpoint will be
> > attempted before falling back to non-SVCB connection modes.  This
> ensures that
> > SVCB-optional clients will make use of an AliasMode record whose
> TargetName has
> > A and/or  records but no SVCB records.)
>
> What happens under the current wording, before the addition above? That
> is, if no AliasMode record was processed, is the addition along the lines
> of "you can only add this if you have it, and if no AliasMode record was
> processed, you don't have it"? Or does the addition solve the problem "if
> no AliasMode record was processed, the thing you append will be harmful"?
>

Yes.

If no AliasMode record was processed, then $QNAME would be the origin name
PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be
legitimate A/ owner names (and shouldn't exist), and if a client did
that it would be harmful (to the client), at least a little bit harmful
(trying something that won't work.)

If instead of the initial $QNAME, the origin name (and port) are added to
the end of the list, that is literally the exact same thing as non-SVCB
connection mode, so adding that to the list would be moot.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

So, here is my suggestion, for "a sentence (or possibly two) which only
clarify what is already written?":

In section 3:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

becomes:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client MAY attempt to use non-SVCB
   connection modes, using the origin name (without prefixes),

   the authority endpoint's port number, and no SvcParams.

(The original didn't use RFC 2119 language, but the list of failure modes
in 3.1 leads to "MAY" being the most appropriate choice.)

Let me know if that is good enough.
(The rest can go into a -bis... how soon are we allowed to start a -bis
document? The day of RFC publication? I'd like to start that as soon as
possible, while everything is still fresh.)

Brian

On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:

>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> Here are some proposed text changes, per Warren's invitation to send text:
>>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
>> In section 1.2, change:
>>
>> 2.  TargetName: The domain name of either the alias target (for
>>AliasMode) or the alternative endpoint (for ServiceMode).
>>
>> to:
>>
>> 2.  TargetName: Either the domain name of the alias target (for
>>AliasMode) or the host name of the alternative endpoint (for
>> ServiceMode).
>>
>> In section 2.4.2, change:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records alongside this
>>SVCB record, although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>> to:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records at the service
>> name,
>>although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>>
>> In section 2.4.3, change:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters.
>>
>> to:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters. The TargetName MUST be a host name
>>(as defined in [DNSTerm].)
>>
>> In section 3, the following changes are proposed; they introduce a new
>> term LASTNAME to be used to disambiguate the $QNAME reference so as to
>> remove ATTRLEAF prefixes from the appended target:
>>
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3).
>>
>> becomes:
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3). Let $LASTNAME be the service name
>> without any prefixes.
>>
>>
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes) and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>> becomes:
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes), set $LASTNAME to this new $QNAME
>> and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>>
>>Once SVCB resolution has concluded, whether successful or not, SVCB-
>>optional clients SHALL append to the priority list an endpoi

Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Brian Dickson]

On Wed, Aug 31, 2022 at 10:43 AM Eric Orth  wrote:

> I'm not sure what exactly is being changed or clarified with this
> suggestion.  Section 9.5 already applies at SHOULD-level, whether
> cryptographically protected or not and whether the received records were
> AliasMode or ServiceMode.
>

The text in 9.5 has some language that is actually NOT at the SHOULD level:

   Because HTTPS RRs are received over an often-
   insecure channel (DNS), clients MUST NOT place any more trust in this
   signal than if they had received a 307 (Temporary Redirect) response
   over cleartext HTTP.


That's what the suggestion is making an effort to strengthen, under
specific conditions (e.g. cryptographically protected HTTPS records
received).

The current 9.5 text quoted above, is placing MUST NOT guidance,
independent of whether the records were cryptographically protected.

I'm thinking it would be better to fix the quoted language above, in a -bis
document, if the suggested text isn't acceptable as an update to the
about-to-be-published draft.

The logic used to reach that MUST NOT is suspect, IMHO.
The main non-requirements on DNSSEC (i.e. that HTTPS does not require it)
are then turned into an "assume all DNS responses are not cryptographically
protected" inferentially.

It would be better guidance to instruct clients to use appropriate levels
of trust, on signed vs unsigned DNS, and/or DNS received over encrypted
transports.

I also think the guidance would be more precise if the encrypted transport
were not lumped together with the signed content.
Also something for a potential -bis or best practice document.

Brian


> On Wed, Aug 31, 2022 at 5:43 AM Martin Thomson  wrote:
>
>> On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
>> > One additional suggested addition to the end of section 3.1 is:
>> >>If DNS responses are cryptographically protected, and at least
>> >>one HTTPS AliasMode record has been received successfully,
>> >>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>> >>even when reverting to non-SVCB connection modes. Clients
>> >>also MAY treat resolution or connection failures subsequent
>> >>to the initial cryptographically protected AliasMode record
>> >>as fatal.
>> > [Brian's note: this last would provide some guidance to implementers of
>> > clients: a signed HTTPS AliasMode record is a strong signal that the
>> > DNS operator is discouraging fallback, albeit at a "MAY" level.]
>> >
>> > NB: The 2.4.3 change could be removed as it is mostly independent, as
>> > could the last addition to 3.1.
>> > The 1.2 change is very minor, is not too important but presents a
>> > succinct clarification on the hostname vs domain name thing.
>> > The 2.4.2 change and section 3 changes together are fixes for the
>> > prefix/no-prefix issue (which was basically a scrivener's error, and
>> > does not change the semantics at all.) They should stay or go as one
>> > unit.
>>
>> I somewhat like this change, but I would generalize to receiving any
>> signed HTTPS record during resolution, rather than limiting it to AliasMode.
>>
>> That said, it is somewhat gratuitous.  I'd want it standardized if that
>> was what was expected, but I'd prefer to defer that to an
>> extension/follow-up.
>>
>> (In case you hadn't guessed, I tend to agree with those arguing for no
>> change to the spec.)
>>
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

efix issue (which was basically a scrivener's error, and does
not change the semantics at all.) They should stay or go as one unit.

Brian

On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

>
>
> On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz  wrote:
>
>>
>>
>> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>  Fail fast may not be appealing, but in some (probably the majority of)
>>> cases, it may be the most correct option.
>>>
>>> It may also be the case that the zone owner knows whether this is the
>>> case.
>>> I think it is much more likely that explicitly declaring the situation
>>> (if known) is more useful than having several billion clients independently
>>> attempting to infer whether the first option will even work, let alone
>>> provide a useful alternative to the second or third.
>>>
>>
>> In fact, there is one way for the zone owner to disable fallback: enable
>> ECH.  Fallback is not compatible with ECH, so ECH-aware clients will
>> disable fallback when the ServiceMode records contain ECH.
>>
>>
> Wait, what?
>
> This whole discussion was raised from the perspective of zone owners
> publishing AliasMode apex records.
> Those owners would not be operating the CDN, which is the whole point of
> using a CNAME or AliasMode.
> I.e., the zone owner would be the one wanting to disable fallback, but
> would not be in a position to do what you suggest.
>
> The domain's contents are served via a CDN, where the CDN requires
> delegation of control, most often with CNAME (or AliasMode at the apex).
> The ServiceMode records are placed on the CDN operated zone (in order to
> avoid the first connection to establish the AltSvc stuff).
>
> The AliasMode record cannot be combined with ECH, since no SvcParams are
> allowed. The zone owner is not using ServiceMode, that is the declared
> assumption.
>
> If that (ECH) is the only way to disable fallback, that's what the focused
> discussion needed to elicit, and I think some slight adjustments are needed
> to at least facilitate zone owners preventing fallback. The mechanism
> doesn't need to be added to the draft, but likely would get put into a
> separate draft or a -bis document. However, there needs to be some daylight
> between the fallback method and the mandatory SVCB/HTTPS components, in
> order to allow for that development.
>
> BTW, the concern is less about singleton zone owners than it is about
> large scale integrated DNS management of zones in order to accommodate CDN
> usage.
>
> Note also, this issue is not strictly limited to vertical integration
> among products/services of the DNS operator; there are large scale
> inter-provider (DNS and other services) open partnerships (controlled by
> their mutual customers) that have need for the programmatic ability to
> assign CDNs and enable/disable fallback (if fallback is part of the
> specification).
> (For those interested, the not-yet-an-IETF standard for interoperability
> between DNS and service providers is Domain Connect. The intent is to
> revive the draft for that, which previously lived in the REGEXT WG.)
>
> I think converting the fallback in the draft into MAY, and having active
> discussions, dev, test, and deployment on a voluntary basis outside of the
> scope of the current draft, is the fastest path to solving the "no
> fallback" signaling issue, and to getting the draft published (with a few
> minor tweaks).
>
> I'll review the other comments, as well as Warren and Viktor's recent
> messages, and see if I can come up with some proposed text to make very
> limited changes to the draft.
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz  wrote:

>
>
> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>  Fail fast may not be appealing, but in some (probably the majority of)
>> cases, it may be the most correct option.
>>
>> It may also be the case that the zone owner knows whether this is the
>> case.
>> I think it is much more likely that explicitly declaring the situation
>> (if known) is more useful than having several billion clients independently
>> attempting to infer whether the first option will even work, let alone
>> provide a useful alternative to the second or third.
>>
>
> In fact, there is one way for the zone owner to disable fallback: enable
> ECH.  Fallback is not compatible with ECH, so ECH-aware clients will
> disable fallback when the ServiceMode records contain ECH.
>
>
Wait, what?

This whole discussion was raised from the perspective of zone owners
publishing AliasMode apex records.
Those owners would not be operating the CDN, which is the whole point of
using a CNAME or AliasMode.
I.e., the zone owner would be the one wanting to disable fallback, but
would not be in a position to do what you suggest.

The domain's contents are served via a CDN, where the CDN requires
delegation of control, most often with CNAME (or AliasMode at the apex).
The ServiceMode records are placed on the CDN operated zone (in order to
avoid the first connection to establish the AltSvc stuff).

The AliasMode record cannot be combined with ECH, since no SvcParams are
allowed. The zone owner is not using ServiceMode, that is the declared
assumption.

If that (ECH) is the only way to disable fallback, that's what the focused
discussion needed to elicit, and I think some slight adjustments are needed
to at least facilitate zone owners preventing fallback. The mechanism
doesn't need to be added to the draft, but likely would get put into a
separate draft or a -bis document. However, there needs to be some daylight
between the fallback method and the mandatory SVCB/HTTPS components, in
order to allow for that development.

BTW, the concern is less about singleton zone owners than it is about large
scale integrated DNS management of zones in order to accommodate CDN usage.

Note also, this issue is not strictly limited to vertical integration among
products/services of the DNS operator; there are large scale inter-provider
(DNS and other services) open partnerships (controlled by their mutual
customers) that have need for the programmatic ability to assign CDNs and
enable/disable fallback (if fallback is part of the specification).
(For those interested, the not-yet-an-IETF standard for interoperability
between DNS and service providers is Domain Connect. The intent is to
revive the draft for that, which previously lived in the REGEXT WG.)

I think converting the fallback in the draft into MAY, and having active
discussions, dev, test, and deployment on a voluntary basis outside of the
scope of the current draft, is the fastest path to solving the "no
fallback" signaling issue, and to getting the draft published (with a few
minor tweaks).

I'll review the other comments, as well as Warren and Viktor's recent
messages, and see if I can come up with some proposed text to make very
limited changes to the draft.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Fri, Aug 26, 2022 at 11:54 AM Tommy Pauly  wrote:

>
>
> On Aug 26, 2022, at 4:29 AM, Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
> 
>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
>> > Relatedly, the results presented by EKR [1] at the most recent DNSOP
>> > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
>> > records through their local resolver.  To me, this implies that
>> functional
>> > origin endpoints are likely to be required even if client software gains
>> > SVCB/HTTPS support.
>>
>> This is why my suggested client behaviour was cognisant of this
>> impediment.
>>
>> - If the client's *initial* SVCB lookup succeeds, *then* fallback is
>>   no longer an option.
>>
>> - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
>>   then the client behaves as though the SVCB record does not exist.
>>
>> This results in more predictable behaviour, without optimising for
>> failure.
>
>
> I don't think "more predictable" is really a desirable or achievable
> outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP,
> iterative resolvers for DNS) tend to develop highly tuned heuristics and
> state machines in pursuit of performance and reliability within their
> particular constraints.  I think an instruction not to fall back in this
> case would likely be ignored.
>
>
> I definitely agree with all the points that Ben is making here and
> elsewhere. The practical realities of dealing with new record types, and
> the evolving heuristics on clients, will determine how the records are
> used.
>
> It makes sense for informational documents to talk about techniques and
> best practices—like an updated Happy Eyeballs algorithm to include SVCB
> logic, but that shouldn’t block anything in the base specification or add
> overly restrictive requirements today.
>
> Tommy
>
>
I don't disagree with your comment about "overly restrictive requirements"..

However,  if you can take a look at one of my responses, I go into
how/why *fallback
is itself an overly restrictive requirement.*

This draft, with fallback, asserts/requires that apex A/ records, if
they exist, MUST be used to serve the same service and content as the
corresponding HTTPS record.
This assertion/requirement is also exclusive of other potential
SVCB-compatible apex records' potential requirement for their own fallback
to A/ records.
Legacy support really needs to be stated as a "MAY", explicitly, and zone
owners MUST be able to publish A/ records used for other purposes (as
indeed they may already be doing.)

Legacy support is good, but cannot be a strict requirement for deployment
of HTTPS, IMNSHO. (The current draft, with fallback, makes it a strict
conditional requirement.)

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

> For now, I think it's better to keep the current guidance, in order to
> minimize the risk of disruptions as these new RR types begin to be deployed.
>

I have a small favor to ask.

Could you try to "sell" the guidance from the hypothetical perspective of
it not having been part of the draft?
I.e. if it was not already in the draft, and you were proposing the
fallback (after successful AliasMode response), is there a short pitch that
makes it compelling?

Consider also that there are roughly 3 million resolvers (with vastly
varying client bases), hundreds of millions of zones, and billions of
clients. The cross product is probably sparse, but definitely not super
sparse.
There is no sharing of information between clients, and they are all
implementing the logic from local knowledge only, correct?
How does this scale if a large proportion of fallback lookups don't/can't
result in success if the primary lookup fails?
On the client, on the resolver, on the authority server, on the apex web
server (at the fallback address), on the CDN?

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

>
> Brian proposes a use case of serving only a warning message on the origin
> endpoint, in order to minimize the load on IP addresses that are likely
> hardcoded into a customer's zone.
>

So, the major update to add to this is:

   - We (GoDaddy) have revisited this approach, and are now considering a
   much better design (summary follows below)


The design we are considering is deployment of Web redirect servers (via
apex A/ records) which do HTTP 301 permanent redirect responses.
These would respond to connections to the apex domain ("example.com") and
redirect the client to a non-apex name ("www.example.com").
The non-apex name would have a CNAME to redirect to the actual delegated
authority.
The RDATA on the CNAME would be identical to the RDATA on the apex HTTPS
record.

Note the following:

   - This will provide legacy clients the same eventual connectivity as the
   HTTPS record, including connecting to the correct (aka "best") target node
   at the CNAME/HTTPS target name, since both are resolved by the client's
   resolver
   - Legacy clients will have a one-time latency penalty for the HTTP 301
   connection and redirect. This penalty is once per domain only, per client.
   - The apex A/, HTTPS, and www CNAME records are all cacheable, and
   likely to have long TTLs
   - The target name is identical, and client-resolver caching provides
   benefits to both legacy and HTTPS-aware clients.

Note also, the following:

   - The target of both the HTTPS and CNAME records are the same
   - Resolution failures or connection failures will have a shared fate,
   between legacy and HTTPS-aware clients
   - An HTTPS-aware client, which attempts to do the fallback procedure,
   will experience the legacy-mode delay due to the HTTP 301 rewrite, but will
   still end up hitting the same issue that triggered the fallback
  - In other words, for this publication scheme, fallback will NEVER
  achieve its desired/expected goal
  - Individual instances of fallback working due to temporary issues,
  would have had the same success achieved by merely retrying the
connection
  or resolution (tautologically!)

If we do deploy this, we will do so on all our customer domains using HTTPS.
This means that for those domains (in the millions or tens of millions),
the fallback in the draft will only result in added overhead while never
actually achieving any successful connections (due to shared fate between
legacy and HTTPS).

We know this will be the case for these domains.
The logical approach would be to do one of the following things:

   - Allow the domain owner to signal that fallback will not work, e.g.:
  - An AliasMode SvcParam (e.g. example.com HTTPS 0 mycdn.example.net
  nofallback)
  - or a third HTTPS "mode" record, to signal no fallback (e.g.
  example.com HTTPS 65534 . where 65534 is the "no fallback" mode
  signal, and "." is simply a placeholder domain needed for RRDATA
structural
  consistency)
  - Both of these would require significant changes to the draft, to
  clients, and to authority servers..
  - Strongly not recommended
   - Allow the domain owner to only supply fallback addresses explicitly,
   and in the absence of those, not do the fallback (e.g. using an attrleaf
   prefix label)
  - This is the "presence/absence is the signal" (e.g. _
  https_fallback.example.com A 192.0.2.1 // chosen from one of the RFC
  5737 blocks )
  - This is also extensible, since the attrleaf prefix would be
  (presumably) SVCB-record specific
  - HTTPS would have its own attrleaf prefix, and each new
  SVCB-compatible record would have its own attrleaf prefix
  - Would require changes to the draft, to clients, and to authority
  server zone publication automation (but not to the authority server
  software)
  - Not recommended
   - Remove fallback from the draft
  - Signaling is only needed if fallback is included in the draft
  - Much less work; only clients would require changes, and only to
  remove code/logic
  - Fail fast
  - Deterministic and reliable behavior
  - Interoperable across client implementations and server
  implementations
  - Still requires changes to the draft
  - Least of three "evils"

Removing the language from the draft does not force implementers to not do
their own thing. Individual client implementations could still do the
fallback thing, but would not be required to do so.
It does, however, put more responsibility on the implementers to respond to
issues raised if adverse effects result. It might be advisable to be a
user-configurable option, possibly off-by-default.
Implementers would not be able to deflect blame for problems via the "it's
what the RFC says" response, if problems do occur.



> Instead, the draft attempts to ensure that deploying and implementing the
> HTTPS record "does 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Fri, Aug 26, 2022 at 4:29 AM Ben Schwartz  wrote:

>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
> Indeed it is a possible position to say that the Internet is not yet
>> ready for semantically distinct services seen by SVCB-aware and legacy
>> clients.
>
>
> In addition to the deployment concerns I've mentioned earlier, a
> deployment of this kind would be intrinsically insecure: a hostile
> intermediary could override the choice of which semantically distinct
> service is seen by the client.  That's another reason why this
> configuration is not permitted.
>

I don't think it is the case that it is not permitted.

Note that many/most of the cases in 3.1 do not account for one specific
permutation:

   - An apex AliasMode HTTPS record, with no prior or subsequent CNAMEs,
   and no subsequent AliasMode records, in a DNSSEC signed zone, which also
   has apex A/ records. All the records in the zone are signed.
   - It is literally impossible for a hostile intermediary to selectively
   block service, without the client having the ability to detect this (if the
   client is doing DNSSEC validation itself, or if the client is asking the
   upstream DNS resolver to do DNSSEC validation and return data with the AD
   bit set).
   - If the client detects any failure (including SERVFAIL), and the Chain
   length is 1, and the DNS lookups are cryptographically protected, the
   client MUST hard-fail (per the current spec).

This particular case appears to me (and I'd argue is also proveably)
intrinsically secure.

NB: When GoDaddy begins publishing HTTPS records in customer-managed DNS
zones, it will do so only with DNSSEC signed zones, using AliasMode records
with Chain length of 1, with or without apex A/ records (mostly likely
with).
(The intent of making DNSSEC widely available has previously been
discussed, so this isn't really news per se, except in the context of HTTPS
and section 3.1)

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:


> (Also, Brian's analysis indicates that the origin hostname's address
> record TTL would bias the endpoint selection, but this is not correct.)
>

This statement intrigues me, and I think is highly relevant to the
discussion.

Could you explain further?

Is this non-bias the result of logic embedded in the draft that I have
overlooked?

Or is what you are referring to an implementation artifact within Chrome?

For purposes of focusing on the draft, I would like to limit this to things
in the draft; if it isn't in the draft, but it addresses the concerns
raised, the obvious answer is: please add it to the draft

   - The goal is to standardize the behavior, by explicitly including
   everything authority servers, resolvers, and clients need to do to
   interoperate with the same characteristics
   - If only some of the clients have this good behavior, but others do
   not, that is not good for the usability of HTTPS records
   - If this is added to the draft, and addresses the concerns, I may
   withdraw my objection (which would clear the draft for publication).
   - If it is already in the draft, but not obvious, then cleaning up the
   text to make it obvious, is something I think would be in everyone's
   interest.

Thanks in advance,
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

> Thanks to Brian, Viktor, and others for the very close review, as always.
> While I disagree with many of the claims made here, it's clear that some of
> the text has proven confusing.  I'm not familiar with the process rules
> given the draft's current state, but perhaps we can improve clarity with
> some modest revisions.  I'll try to keep that discussion separate.
>
> The key text for this discussion is in Section 3:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> I believe most reviewers correctly understood this to mean that, if all
> else fails, you can connect to https://www.example.com/ using the  or
> A records on www.example.com, as usual.
>

One of the problems here is that the term "connection mode" is somewhat
ambiguous.
Does that refer to the HTTP mode, or DNS queries?

It could mean, "connect via HTTP using no SvcParameter" elements, i.e.
connects using vanilla HTTPS, using the last $QNAME.
It does not explicitly identify the connection target address.
(e.g. if there was not a DNS resolution failure, the connection failure
should be "hard" rather than "soft", and only the final $QNAME should be
used, vs explicitly stating "non-SVCB connection to addresses found by
resolving A/ records at ").



> The logic is simple: this draft does not make "HTTPS Record" support
> mandatory for HTTP clients.
>

What the current version of the draft does, is it asserts HTTP ownership of
any apex A/ records, something that was not the case prior to this
draft.

   - The fallback logic assumes that A/ address records MUST serve the
   same content as the HTTPS record
   - This effectively forces the owner to choose between "no A/
   record", or "have A/ records that require maintenance (if the are the
   result of doing DNS resolution on the HTTPS target)", or "do some other
   thing that serves the same HTTP content".
   - This means that for as long as the current draft is published as-is,
   and until it is given a -bis treatment or is deprecated, no other use of
   apex A/ records is possible (without impacting HTTPS-aware clients)
  - This also means no OTHER SVCB-compatible apex RRTYPE can be used
  that also requires fallback to A/ records, as those would
conflict with
  the HTTPS usage

The "www" name under any given domain, is by convention the owner name of
HTTP and HTTPS services, but is not strictly required. The expectation that
"www" is a web server is reasonable, and that CNAME and AliasMode records
would be interchangeable. Other (non-HTTPS) SVCB-compatible records would
not be expected to co-exist at the "www" name.
The same is not true for the apex name, recent trends to the contrary
notwithstanding.


> Thus, HTTP servers are still required to publish functional address
> records on the origin hostname, as usual.
>

This is *only* true if the HTTPS record is added to a pre-existing address
record's origin hostname.
There is no requirement for a pre-existing address; it is possible (indeed
likely) that a significant proportion of HTTPS records are published where
no pre-existing address records existed.
There might be a simultaneous deployment of A/ records for the purposes
of serving (some kind of content) to legacy clients, which is a distinct
use case from the pre-existing same-content A/ use case.


> (Similar logic applies to any other pre-existing protocol that may be used
> with SVCB.)
>

I don't follow this logic, could you explain, please?

Suppose (at some future point) there are half a dozen SVCB-compatible
RRTYPEs, all published at a zone apex.
Which service (corresponding to which RRTYPE) is the pre-existing protocol
served at the apex A/ address(es)?
There can be ONLY one protocol attached to an address, unless the address
is forced to serve many protocols simultaneously (not an ideal situation at
all).


> Since these records are required to be present and working, we can hardly
> forbid clients from using them.
>

Except, they aren't *required* to be present and working, at least not
within the scope of this draft.
What is true, is that IF they are present, they are *expected* (not
required) to be working.
(The logic is backwards; it is B->A, not A->B. Plus, the negation of X->Y
is (!Y)->(!X), rather than (!X)->(!Y).)

This pre-existence assumption omits an entirely different logic branch:
green-field deployments using HTTPS (where no current records of any type
existed, or existed for other services, including "parking" generic pages,
"cash parking", etc.).

GoDaddy provides managed DNS hosting (which in some cases involves add-on
services that are provisioned into the customer's zone), for tens of
millions of domains. A significant portion of those will be updated to use
HTTPS in the near future, presuming what gets published will work correctly.

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 7:58 AM Paul Hoffman  wrote:

> On Aug 24, 2022, at 7:14 PM, Brian Dickson 
> wrote:
>
> >> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
> >>
> > No, I'm saying that, as far as I can tell, the flow was never explicit,
> and that's a big part of the problem.
> >
> > And I'm saying that if it had been explicit, the concerns would have
> been raised at that time, rather than now.
>
> This WG has dealt with that exact issue many times with well-debated -bis
> documents.
>
> When Warren started this thread, he said "this is *not*  an opportunity to
> re-litigate existing  decisions, make non-required changes, etc." AliasMode
> was significantly discussed during the preparation of the document, and it
> appears that you don't like the conclusion. That's fine, but that's not a
> reason to change this document: it is a reason to create either a document
> that clarifies or updates it.
>
>
Warren also stated "I'd like to also thank the authors and WG in advance
for their time and for keeping this discussion focused".  I interpret that
as, "let's discuss the technical content of the draft."

To that end:
The issue I raised was with the process flow for the client, in section 3,
not the AliasMode section (2.4.2).
In the summary portion of my original email, I put it thusly:

   - Resurrecting ANAME behavior in corner cases is every bit as bad as
   choosing ANAME as the standard.

I.e. I am saying that, under certain conditions (either DNS resolution
problems, or HTTPS connection problems, after successfully resolving a
single AliasMode HTTPS record, and if there exists apex A/ records
[0]), that the prescribed behavior reverts to that of ANAME.
My assertion is that the ANAME behavior is "OMG! That clearly doesn't
work". [1]

My question to anyone responding who disagrees with this assessment is:
Which is it?

   - Is the behavior (in the corner cases) not ANAME-like (requiring that
   apex A/ records have the same values as would be resolved when
   following the HTTPS Alias)?
   - Or, "No, it always works" (even in those corner cases)?
   - Or, "The corner case ANAME behavior exists, but is not a big enough
   deal to make changes before publication."

*Having the opinion that "The corner case ANAME behavior exists, but is not
a big enough deal to make changes before publication", is a valid position.*
I would prefer that this *exact* language be used, if this is the position
being taken by anyone, please.
(E.g. Paul H, is this an accurate characterization of your position?)

BTW: the fall-back corner case is only indirectly related to AliasMode, and
is not related to any of the discussions on AliasMode that occurred, to the
best of my knowledge.
(I'd be happy to be corrected with any single pointer to an on-list thread,
if I'm wrong).

I am not proposing changes to AliasMode itself, nor do I have problems with
the current state of 2.4.2 (other than ambiguous language.)

The problematic bit from 2.4.2 was specifically:

   - The conflation is between "legacy clients", and "preferable for
   clients implementing the specification".
   - Legacy support is not "fallback", which is where the conflation is
   introduced.
   - If non-legacy fallback is a required element to advance the draft,
   let's update the draft accordingly
  - Including establishing a new owner label prefix for fallback
  records, distinct from legacy records, which by definition CANNOT have a
  different name than the origin (apex) name.
  - The conflation is IMHO browsers attempting to infer the intent of
  zone owners, rather than having zone owners explicitly publish
appropriate
  records to that effect (fallback target addresses).

Note also that 2.4.2 only defines AliasMode (what it is, how it is meant to
be used, rules about what the publisher should put in AliasMode records,
and the paragraph about "legacy clients" is not part of, nor is it
subsequently either incorporated by reference, restated, or directly
included in section 3 on Client behavior. (The only other place "legacy" is
referenced is in Appendix C, comparing the draft to the ANAME and HTTP
proposals that predate this draft.)

NB: Viktor Dukhovni had a laser-focused contribution to the discussion (on
Wed, Aug 24, 1:58 PM), which I believe does a much better job of
articulating the issue than my original message did. (Thanks, Viktor).
I would strongly suggest reading his message and replying/commenting there.

Brian

[0] Apex A/ records may exist for purposes other than publishing the
site whose delegation is performed via HTTPS record, including SMTP or
other non-web services, or for providing legacy clients with instructions
on obtaining HTT

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman  wrote:

> On Aug 24, 2022, at 5:14 PM, Brian Dickson 
> wrote:
> > "at this stage" is only the case due to the draft not being explicit in
> the flow.
>
> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
>

No, I'm saying that, as far as I can tell, the flow was never explicit, and
that's a big part of the problem.

And I'm saying that if it had been explicit, the concerns would have been
raised at that time, rather than now.

(This is, IMNSHO, the poster child for why being as clear as possible for
actual logic flows is really important, both to implementers, and to those
involved in the process of reviewing documents and advancing standards.)

I.e. I definitely apologise that this was not caught earlier. I also don't
think it would have been possible to catch prior to doing interoperability
tests and discussing with developers, which is exactly what the process was
that lead to the request to the chairs and AD.



>
> > Yes, this is a non-editorial change.
>
> Also called a technical change.
>

Or a technical correction of a defect. It's a change, but not an arbitrary
change.


>
> > If it were limited to an editorial change, it could be handled with an
> Errata or via a -bis document.
>
> Technical changes require going back at least to IETF Last Call, if not WG
> consideration again. Bis documents are for making technical changes.
>

 once the RFC is published. And yes, while this will require those
things, those are good things. Clarification and scrutiny are the
responsibility of the WG and the IETF.

This is an exceptional case, given that the issues are central to
interoperability and deployability (usability by zone administrators).

It is an unavoidable risk that developers take in attempting to track an
in-progress draft prior to publication as a standards-draft RFC.
Any change made up until the RFC is published, is something developers that
want to be RFC-compliant need to do.
Yes, doing development while the standard isn't complete gets software
deployed sooner.
The standard necessarily dictates the implementation, not vice versa. The
copyright assignment stuff when bringing things to the IETF basically says
that once adopted by the WG, it's a WG doc, not the original author's.

I believe that, for the most part, the needed changes are code deletions or
branching logic pruning, and as a result, de minimis.
I also believe that the resulting client performance will be faster, more
reliable, and less risky.
In particular, the speculative DNS queries made in parallel can benefit
from early abandonment. If a client receives an AliasMode response,
outstanding queries for A/ are no longer needed. This permits a client
to proceed faster than if the client waited until it received responses, or
worse waited until those queries timed out.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Aug 24, 2022 at 4:11 PM Eric Orth  wrote:

>
>
> On Wed, Aug 24, 2022 at 4:58 PM Viktor Dukhovni 
> wrote:
>
>> * When the initial SVCB (also HTTPS, ...) query returns an AliasMode
>>   result, lookup failures in all subsequent SVCB/HTTPS queries are
>> "fatal"
>>   even for SVCB-optional clients.
>>
>> This more closely approximates predictable client behaviour that doesn't
>> randomly ignore redirection records on unexpected transient "lookup
>> failures" (see above vs. "lookup success").
>>
>> Of course if even the initial lookup fails, the client may well be using
>> unsecured UDP behind a broken CPE (that mangles queries for unfamiliar
>> record types), and may have no ability to resolve any SVCB or HTTPS
>> records, and have no access to DoH or DoT.  In that case it seems
>> somewhat reasonable for SVCB-optional to fall back to status quo ante.
>>
>
> Regarless, once AliasMode records are found, these MUST be used and
>> partial lookup failure along a non-empty (so far) alias chain needs
>> to be fatal.
>
>
> This would be a big non-editorial change from the current draft, and I
> don't see any need for such a rule rising to the "exceptional
> circumstances" bar at this stage.
>

"at this stage" is only the case due to the draft not being explicit in the
flow. It would definitely have been addressed sooner if the draft had been
more explicit in specifying this behavior.

I.e. "at this stage" is not a show-stopper, as Warren has already
explained. If you want to discuss the timing, that is a separate
conversation to have with the AD.

Yes, this is a non-editorial change. If it were limited to an editorial
change, it could be handled with an Errata or via a -bis document.


> Why would such behavior be necessary beyond a vague desire to be more
> consistent with the behavior of CNAMEs?
>

(See below, as well as Viktor's response.)


>
> As a client implementor, I think the draft already has the correct
> behavior here, and I do not support making changes at this time.
>

The current discussion is about whether the draft's behavior is correct, as
well as whether the draft's language is unambiguous (i.e. all implementers
interpret it the same way):

   - If the determination is that the behavior is correct, then NBD, no
   changes needed (i.e. a moot point).
   - If the determination is that the behavior is incorrect, I don't
   understand why you would oppose making changes.



> I don't like when implementing new specs makes my client more susceptible
> to errors in cases where a non-implememnting client would have kept working
> fine (except for cases of obvious domain misconfiguration or where breaking
> is important for security).  If a client receives non-aliased A and 
> records that a non-HTTPS-implementing client would have been able to use
> successfully, why should an HTTPS-aware client be forced to ignore them and
> refuse to load a website?
>

Consider the following, non-hypothetical set-up (i.e. one that is actually
being planned to be used, modulo the issue under discussion here):

   - HTTPS record with Target of some CDN object
   - A/ records with addresses returning a web page that is NOT the
   same as the page served via the CDN
  - E.g. a web page that says "Your web browser is unsupported, please
  upgrade to one of the following browsers to access the page in
question." ,
  including provisioning of the web page with the correct TLS
certificate for
  the domain in question.
  - Legacy clients would be being given instructions on how do update
  their clients
 - The instructions MIGHT be links to knowledge base articles
 published and maintained by the client vendors
 - The instructions MIGHT be different on the basis of things like
 User-Agent strings and geographic profiles (including language and/or
 distinct URIs)
  - Both HTTPS and A/ records have extremely long TTLs, anywhere
   from 1 hour to 2 days. If the client ends up using these, they get the
   "Your web browser" message for that long
   - The HTTPS target may have a very short TTL on its records (60 seconds
   is one very common one).
   - Do the math: if you roll the dice every 60 seconds, and after the dice
   turning up a bad result, you then get the "Your web browser" for 2 days.
   What is the relationship between the error probability, and the resulting
   expected proportion of traffic going to the "Your web browser" page?
   - Also consider different browser implementations, where one
   implementation honored the AliasMode (without going back to the A/),
   and the other did the other thing (going back to the A/)
  - The former implementation would present clients with either
  temporary failures (and presumably re-attempted connections), or
permanent
  failures (because the authority configuration was broken). Clients would
  never see the "Your web browser" message.
  - The latter 

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

[Brian Dickson]

On Tue, Aug 23, 2022 at 9:15 AM Paul Hoffman  wrote:

> On Aug 23, 2022, at 8:50 AM, Warren Kumari  wrote:
> > I think that is helpful to communicate expectations,
>
> Is the suggestion that the non-DNS protocol follow the DNS wire format
> and/or presentation format now an expectation? This seems like a long jump.
>
> The purpose of .alt is to let anyone do what they want with non-DNS
> protocols. Expecting them to use the DNS wire format and/or presentation
> format limits the value of .alt and will cause developers who don't use
> them to continue to want to squat on TLDs. This doesn't help the DNS
> community.
>
>
I disagree.

I see the situation like this:

   - For anyone developing non-DNS protocols, which do not have
   DNS-compatible wire format (or presentation format), no advice or
   registration is necessary at all. Go nuts.
   - For anyone developing non-DNS protocols *where they have already
   chosen to use DNS-compatible wire format* (and/or presentation format),
   please use this "alt" registry and use YOURLABELHERE.alt as a suffix.

There is no expectation that they will use DNS format. However, if they
have self-selected to do so, the document is designed for them to be able
to easily understand and do the right thing.


> > and also help minimize people accidentally hurting themselves on sharp
> corners.
>
> If someone is reading this document before they develop their non-DNS
> protocol, we would be much better off telling them to use the DNS. THey are
> already in sharp corner land.
>
>

The issue isn't them hurting themselves on sharp corners; it is them
building apartment blocks with entrance halls that lead to rotating knives
and us accidentally stumbling into those.
(https://www.lyricsfreak.com/m/monty+python/the+architect_21031433.html)

:-)

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

[Brian Dickson]

On Tue, Aug 23, 2022 at 11:52 AM Paul Hoffman 
wrote:

> Thanks again for all the discussion; it is helping the document. You can
> see from the diff at <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-17> that we
> have tightened the language, particularly around what is display format and
> what is wire format. More comments are of course welcome.
>

One group of thoughts that might be helpful, is about the nature of any
"protocol" (for lack of a better term) that is added to the registry.

It may be helpful to add some things along the lines of:

   - Any registered "thing" needs to be completely independent of the DNS
   (at least for any namespace underneath .alt itself).
   - Any registered "thing" should ensure its identifier (e.g "foo.alt") is
   not the only method of confirming the namespace and protocol are what are
   intended.
  -  E.g. independent of the registered name "foo.alt", some shared
  information can be used to allow multiple users of the "thing"
to know that
  "foo" means what they think it means.
  - The example from DNS would be the set of pre-configured IP
  addresses of the ICANN Root Name Servers. All DNS systems assume they are
  in the same ICANN name space, but are also able to validate that by
  communicating with the Root Servers.
   - Any registered "thing" is encouraged to preserve its identifier as
   part of its domain names, but is also encouraged to not attach or associate
   any data with the topmost two labels of domain names (e.g. "foo.alt" would
   not have any sort of data associated with either "foo.alt" or "alt" wtihin
   the system of "thing" itself.) This ensures any leaks outside of "thing"
   can safely be identified and ignored by any other similar registered system
   which is aware of the "alt" registry and scheme.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Sat, Aug 20, 2022 at 10:07 AM Warren Kumari  wrote:

> Brian Dickson recently reached out to one of the DNSOP chairs to raise
> some technical concerns related to the AliasMode functionality in
> draft-ietf-dnsop-svcb-https.
>
> Although this document has already passed WGLC, IETF LC, IESG Eval, and
> was approved and sent to the RFC Editor, I want to make sure that the DNSOP
> working group has a chance to discuss any lingering concerns.  Accordingly,
> I have asked the RFC Editor to hold publication for now (note that the hold
> itself is not expected to delay publication of the document, which is
> blocked anyway due to missing references).
>
> As the document was already extensively discussed and approved, we should
> only make substantive changes if they are very clearly warranted (e.g
> something that would otherwise be an errata, or "OMG! That clearly doesn't
> work, 1+1 doesn't equal 17…") —  this is *not*  an opportunity to
> re-litigate existing  decisions, make non-required changes, etc.
>
> I believe that Brian is on vacation this week, and I wasn't really able to
> parse his issue with the document, so I ask him to clearly state the issue
> on-list when he returns. I would like to have whatever discussions wrapped
> up within 2 weeks from then so that I can release it back to the RFC
> Editor.
>
> Pausing publication is an unusual, but definitely not unprecedented, step.
> Although we are able to make changes until a document is published as an
> RFC, once it is approved and sent to the RFC Editor, we should only make
> (non-editorial) changes in exceptional circumstances…
>
> I'd like to also thank the authors and WG in advance for their time and
> for keeping this discussion focused,
> W
>
>
Thank you Warren.

I'll try to first raise the highest-level concern, which is that there are
some elements which appear to have some level of ambiguity, that result in
implementations doing different things.

The place where these ambiguities exist is on the client side of things,
meaning the procedures followed by clients, including how to interpret DNS
responses that originate from authoritative DNS servers (either directly,
or via resolvers, or via stub libraries).

To be clear: the wire format parts are fine, and what an zone administrator
should publish is not in any way impacted.

The differences in interpretation, and the client behavior under one of
those interpretations, are the problem.

The easiest way forward, I think, is to try to add enough clarification to
have a discussion about which interpretation has consensus. IMNSHO, the
draft needs to reach the point where only one interpretation is possible,
so that all implementations are in agreement, at least in the fundamental
aspect of the how clients should behave.

Once there is some clarification on the proposed text (e.g. with two
alternative approaches equally clearly described), then the conversation
can progress to "which of these is what DNSOP wants to be published"?

So, having prefaced things this way, here are the specific elements that
are apparently ambiguous.

I'll summarize as much as I can, but I will also include a couple of emails
from a thread between myself and the authors, chairs, one implementer,
included mostly to demonstrate that the interpretation in question is quite
specific and well articulated, i.e that I'm not possibly mis-interpreting
something someone said.

   - The problem is whether/when/how the DNS queries are considered
   failures, and whether/when/how some sort of fall-back procedure is followed
   in those cases.
   - This includes ambiguity over whether further DNS queries/responses are
   required, if HTTP connection failures occur with resolved TARGET values.
   - The ONLY concern is whether an AliasMode record (particularly at the
   zone apex) is treated EXACTLY the same as a constrained CNAME (i.e.
   unconditional QNAME rewrite if the RRTYPE is appropriate).
  - Unconditional would imply that an HTTPS-aware (or SVCB-aware, if
  you prefer) client never backtracks to the origin name to look up A/
  records for use, or more precisely, if the client does look up the A/
  records speculatively, if it gets an AliasMode record, it does not use
  those A/ records under any conditions.
  - Conditional would imply that there are conditions under which the
  client MIGHT use sibling A/ records instead of a valid AliasMode
  record, even if the AliasMode record was cryptographically protected and
  did not have a Chain-Length error. This situation, even if only "under
  certain circumstances", is the ANAME behavior.

Here is a longer description where the problems/ambiguities appear to
exist, which should be clarified first, and then discussed to decide what
to do about them.
There are some phrases or terms t

Re: [DNSOP] draft-schanzen-gns and namespace mechanisms

[Brian Dickson]

One tidbit that might have been overlooked, is that draft-schanzen-gns (and
the various documents it references, including stuff in github) has a
technical problem.

The TL;DR: is that nsswitch (and similar systems) depend on individual
resolution mechanisms (whatever those may be) returning NXDOMAIN (or the
equivalent) in order to fall through to the next mechanism.
GNS as currently specified will NEVER return NXDOMAIN. The draft says so
(about never returning NXDOMAIN) and explains why. The why doesn't matter,
the what matters.

What this means is, if nsswitch.conf has a line that looks like:
hosts: gns dns files
then the lookups will NEVER fall through to DNS or /etc/hosts. Changing the
order around to put "gns" at the end of the list will work, but would
result in DNS queries for GNS names always being done. This appears to not
do what the draft says it wants to do (i.e. allowing users to have both GNS
and DNS names in use, including allowing GNS to be preferred if a name
collision occurs.)

Here's the longer version:
If GNS never returns NXDOMAIN, then the only way GNS can interoperate with
the name resolution selectors such as nsswitch.conf is to use a namespace
identifier of some kind, and return NXDOMAIN for any names that are not
actual GNS names. (The identifier could be anything -- a suffix, a prefix,
a single character, etc.) This would allow GNS to be a first-class member
of the available resolution mechanisms, rather than being forced to always
be the last mechanism in a list.

Using some (any) mechanism that allows GNS names to be identifiable in such
a way as to either allow GNS to internally distinguish GNS from DNS (and
return NXDOMAIN for DNS names if the query sent to GNS is a DNS name), or
for GNS to handle both GNS and DNS names on a similar basis (do a GNS
resolve on GNS names, or do a DNS resolve on DNS names and return the
result from the DNS call).
Having DNS vs GNS ordering handled by the os-specific mechanism (such as
nsswitch.conf) might be better for linux/unix systems (and servers and
desktops generally), while mobile OS set-ups might use their own mechanisms.

The GNS specification might also want to change its design so that
applications make those decisions on resolution directly, and call
whichever mechanism is appropriate, ie. call either GNS or DNS for
resolution on the basis of the presence/absence of the GNS identifier.
Additionally, the applications (e.g. web browsers) might handle the
input/UI parts to default to either DNS or GNS, and "hide" the GNS
identifier (similar to how the "www" prefix and "https:" service identifier
are "hidden", but available for modification by users in the browser bar),
allowing advanced users to do "the other thing", as appropriate, or
whatever the GNS folks thing makes sense.

E.g. in the browser UI for the URI, what might appear to the user as
"foo.bar" might in fact be "https://www.foo.bar; (current DNS-as-default
browser), or could alternatively be "https://www.foo.bar.gns.alt; (modified
GNS-as-default browser). A user entering "foo.bar" would have that
transformation applied by default, but also be editable if the user desires.

Brian
P.S. To be clear, this is an observation on a deficiency, and suggested
possible fix, but it is not specifically advocating for the correction to
be done.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

Sent from my iPhone

> On Aug 17, 2022, at 3:12 PM, Timothy Mcsweeney  wrote:
> 
> 
>>> On 08/17/2022 2:14 PM EDT Paul Hoffman  wrote:
>>> 
>>> The Intro says" the rightmost label, to signify that the name is NOT rooted 
>>> in the DNS, and that it should NOT be resolved using the DNS protocol.
>>> Isn't that a new root called Alt?
>> 
>> It might or might not be, depending on what the non-DNS protocol chooses. 
>> This document doesn't tell those protocols what they should do with names 
>> that end in .alt.
> 
> Clear as mud.  
> 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.

(Dots between and after names are moot and meaningless, only relevant in the 
“presentation” format. The last label in a fully qualified domain name, whether 
it is a DNS name or any other sort of domain name, is immediately below the 
“root” of that name space. So ALT as the last label means what would have been 
a TLD if it was in the DNS, and no extra label(s) are needed or implied.)

The label to the left of ALT would be a great place to put a namespace 
identifier, with ALT itself being how DNS knows to ignore/exclude any such 
names (by way of the non-existence in the DNS root zone).
But once the ALT is present, what those domains look like is no longer in scope 
or of interest to the DNS community. (I don’t speak for them, of course, but 
that is my understanding and expectation.)

Brian

> Tim
> 
> ___
> 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] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Brian Dickson]

On Wed, Aug 3, 2022 at 11:40 PM Martin Schanzenbach 
wrote:

> Excerpts from Brian Dickson's message of 2022-08-03 18:09:32 -0700:
> > Top-reply (not apologizing for doing so, either):
> >
> > If I read the actual draft correctly, it is _not_ intended to be a DNS
> > drop-in replacement.
> > Instead, it is meant to be an _alternative_ to DNS.
> >
>
> It is intended to resolve RFC8499 "domain names".
> It could be used as an alternative to DNS to resolve DNS domain names.
> If you want, we can make that clearer in the draft.
> Actually, I have been pondering over that the last few days.
>

There is quite a lot in your draft that is missing, e.g. compared to the
[GNS] reference in the draft.
That [GNS] explicitly includes references to "pseudo-TLD" entities ".gnu"
and ".zkey".
I'd suggest omitting those makes the draft sufficiently incomplete as to be
impossible to evaluate in the current context.


>
> > So, why even use DNS-compatible label strings? That is an obviously
> > conflict-causing choice, which is entirely avoidable.
> >
>
> Any (most?) domain names are DNS-compatible label strings.
> How come that is no problem elsewhere?
>

This thread is concerning your draft, and your draft alone. "elsewhere" is
entirely irrelevant.


>
> > Most of the references in this thread to IETF documents or ICANN
> documents,
> > are within the context of DNS-compatible naming schemes, that themselves
> > lead to such conflicts.
> >
> > The obvious choice, to me, would be for GNS to use a DNS-incompatible
> > suffix, that is short and memorable in some way.
>
> Please. The obvious choice is RFC6761.
>

GNS is your project, your design, completely controlled by you.
The decision to make GNS allow users to create GNS names that are
indistinguishable from DNS names is yours.

That possibility is what leads to all of the problems you are complaining
about.

You have built yourself a "bear trap", and then walked into the bear trap,
and complained about being stuck in a bear trap.

Nothing in the Introduction of your draft establishes a strict requirement
for GNS names to be indistinguishable from DNS names.
It appears to an uninterested reader that you want this
indistinguishability rather than need it.

Am I missing something in the logic you use for reaching for
indistinguishable names?


> You are hand-wavingly proposing to cripple the usability of the names
> used in alternative name systems below which would also require us to
> define
> in the draft what we mean by "name" instead of being able to point to
> RFC8499.
> How is that better than an established process that was applied very
> recently. Twice.
>

8499 definitions for Label and Domain Name do not restrict themselves to
the syntax required by the Global DNS.
You can mean name and label and use those definitions, without restricting
yourself to letter-digit-hyphen syntax.

I'm not suggesting all the labels be distinguishable from DNS labels.
I'm suggesting GNS use Domain Names which are possible to distinguish from
DNS names at a strictly syntactic level.

E.g. "Is the last character of the Domain Name equal to $GNS_THING? If so,
resolve using GNS. If not, resolve using DNS."

This is a suggestion, which you can use or ignore as you prefer.

Using that suggestion removes any and all conflicts, and makes all of the
IETF stuff moot (specifically the 6761 etc stuff).

I offered a variety of single letter terminators (to the GNS Domain Name)
that might be adequate, but which is by no means comprehensive.


>
> >
> > (That rules out .alt  and something.arpa obviously, and probably anything
> > that starts with underscore or even contains the asterisk character).
> >
> > So, pretty much pick any other UTF-8 string that is not a potential DNS
> > label, and is easy to type, short, and unambiguously "NOT DNS".
> >
> > Choice is left as an exercise to those wanting to paint the bike shed.
> >
> > The mnemonic of "!" would be clear, meaning "not", or possibly "~",
> > which is a different kind of "not", or even "^" as another "not".
> > Other non-shift key candidates ",/=;" or any of "[]\`'" (but less
> favorable
> > due to interaction with the unix shell).
> > Similar one-character shift-key options have various
> > pros/cons: @#$%&():"{}|<>?"
> > Basically, pick any of the above, but not any of ".+@-_*", and you are
> good
> > to go.
> > If it makes a DNS resolver complain, it is a good choice.
> > (Even "**" would be okay, as it is not a legal DNS label.)
> >
>
> The reason is usability and the often in this discussion invoked "user
> expectation". A "." is just a lot easier to type, everything you propose
> not only looks awkward but is also difficult to type.
> Not to mention that a lot of applications that use domain names
> expect domain names.
>

You are conflating the term "domain names" here, to avoid clarity.
If you mean to say, "applications that use DNS domain names expect domain
names syntactically identical to DNS domain names", then say so.
I don't 

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

[Brian Dickson]

Top-reply (not apologizing for doing so, either):

If I read the actual draft correctly, it is _not_ intended to be a DNS
drop-in replacement.
Instead, it is meant to be an _alternative_ to DNS.

So, why even use DNS-compatible label strings? That is an obviously
conflict-causing choice, which is entirely avoidable.

Most of the references in this thread to IETF documents or ICANN documents,
are within the context of DNS-compatible naming schemes, that themselves
lead to such conflicts.

The obvious choice, to me, would be for GNS to use a DNS-incompatible
suffix, that is short and memorable in some way.

(That rules out .alt  and something.arpa obviously, and probably anything
that starts with underscore or even contains the asterisk character).

So, pretty much pick any other UTF-8 string that is not a potential DNS
label, and is easy to type, short, and unambiguously "NOT DNS".

Choice is left as an exercise to those wanting to paint the bike shed.

The mnemonic of "!" would be clear, meaning "not", or possibly "~",
which is a different kind of "not", or even "^" as another "not".
Other non-shift key candidates ",/=;" or any of "[]\`'" (but less favorable
due to interaction with the unix shell).
Similar one-character shift-key options have various
pros/cons: @#$%&():"{}|<>?"
Basically, pick any of the above, but not any of ".+@-_*", and you are good
to go.
If it makes a DNS resolver complain, it is a good choice.
(Even "**" would be okay, as it is not a legal DNS label.)

At which point, no conflict exists, ISE and DNSOP are all happy, your draft
can be published (with the proviso that this suffix MUST be used always)
and we can stop having this discussion, permanently.

Brian

On Mon, Aug 1, 2022 at 10:11 AM Martin Schanzenbach 
wrote:

> Excerpts from Stephane Bortzmeyer's message of 2022-08-01 17:29:38 +0200:
> > On Mon, Aug 01, 2022 at 02:31:48PM +0200,
> >  Independent Submissions Editor (Eliot Lear) 
> wrote
> >  a message of 89 lines which said:
> >
> > > Whether that means using TLD labels that begin with _ or whether
> > > that means suffixing them with ".ALT", I leave to you experts to
> > > sort.  I do agree with Martin that it would be helpful to have some
> > > registration of names so that conflicts between name spaces can be
> > > avoided.  This would also encourage formal documentation of those
> > > projects.
> >
> > I agree and I think publication of these drafts would be a good idea
> > (may be with status Experimental since, as Joe Abley said, there is
> > clearly no IETF consensus). Note that I am skeptical about their use:
> > most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
> > not read the RFC and, if they do, won't follow it. But at least we
> > will be able to say that we tried and we have a solution (and not a
> > ridiculous one such as "pay ICANN 185 000 US $").
> >
>
> tl;dr:
> I am a bit ambivalent towards the ".alt" approach.
> For alternative name systems that are specified with status
> "Informational"  the use of ".alt" seems highly unattractive as there is
> absolutely no benefit in using it but at the same time there are
> (obvious) disadvantages especially compared to other name systems which
> do not (try to) publish in the RFC series.
>
> ---
>
> Reasons:
>
> With our draft you would have one system which references
> this "solution", as opposed to specifying solution looking for a problem.
> That being said, since our current draft is Informational, I do not
> think the existence of an ".alt"-RFC would significantly alter our protocol
> implementation or deployment for now.
>
> There is just no benefit for a name system in using it. The benefit lies
> solely with DNS and the existing infrastructure.
> After all, a new "Standards Track" name system that could potentially be
> used as
> a DNS-drop-in would not be designed or specified using ".alt", right?
> That would be like requiring DoH servers to only process names under
> ".doh.alt".
> But they do not and never have, because even though the technical
> resolution process is different, it is still the same namespace.
> So what if (yes I know very theoretical) ICANN and TLD-registrars
> publish their zones in GNS? Is it still www.example.com.gns.alt or would
> it be the _same_ namespace managed by the _same_ authorities resolved
> through GNS and become www.example.com?
> If the latter is the case, what is the purpose of ".gns.alt"?
>
> Further, migration becomes more difficult with ".alt".
> For example, is it possible to get X.509 certificates issued for those
> domains?
> Not to mention that users have to deal with (significantly!) longer names
> as you need a
> second-level indicator on which name system is asked for.
> e.g.:
> www.example.com.gns.alt vs
> www.example.com
>
> So unless IESG actually finds a conflict and we have to put it in the
> specification as a requirement, I don't see why we (GNUnet) should use it
> at all in practice for our implementation.
> Since our draft is 

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Brian Dickson]

On Sun, Jul 31, 2022 at 11:54 AM Paul Vixie  wrote:

>
>
> Andrew McConachie wrote on 2022-07-28 03:24:
> >> Path MTU discovery remains widely undeployed due to
> >>security issues, and IP fragmentation has exposed weaknesses in
> >>application protocols.
> >
> > PMTUD doesn’t work through NAT and that’s probably the main reason why
> > it doesn’t work on the Internet. I think that’s less of a security issue
> > than just a general issue with PMTUD not working on the modern Internet.
> path mtu discovery has been significantly rethought in the modern internet:
>
> https://www.rfc-editor.org/rfc/rfc8899.html
>
> apparently, it sometimes works:
>
>
> https://developers.redhat.com/articles/2022/05/23/plpmtud-delivers-better-path-mtu-discovery-sctp-linux
>
> see also:
>
> < network (so it is not subject to the problems described in RFC2923).
> Instead it finds the proper MTU by starting with relatively small
> packets and searching upwards by probing with test packets.>>
>
> https://datatracker.ietf.org/wg/plpmtud/about/


(I would note that the above wg is "status: closed".)


>
>
> i suggest further reading and perhaps reconsideration. we've got to
> break out of the MTU 1500 jail some day or the internet will end in
> header processing related heat death. some work is being done and some
> results are already known. we should be open to the possibility of
> improvement.
>

If there is interest in pursuing DNS-specific methods for learning and
using path MTU values, where would the right venue for that be?

Concrete suggestions on the subject itself:

   - Could clients learn per-server PTMU from TCP, and (with some added
   active measurement/management of those results) use that in EDNS bufsize
   for UDP?
   - Maybe some additional explicit signaling for support for whatever
   PMTUD mechanisms to use?
   - Since TCP sessions might not be long lived, would a parallel (rather
   than sequential) packet size attempt mechanism be possible?
  - E.g. break the DNS message into a number of first-packet sizes that
  are common or viable MTU sizes, and send them all with the same sequence
  number but different lengths? Have the server ACK the largest
one received
  within some nominal window of time? (Might not work in standard
TCP stack,
  but perhaps a DNS-specific TCP implementation?)
   - I am interested in keeping as much DNS traffic on UDP and unencrypted
   as possible, at the authoritative side. Use DNSSEC to protect the content.
   I am not convinced of the necessity of ADoX generally.

Having said all that, I still am in favor of preventing UDP fragmentation,
regardless of the MTU used, and support this draft.

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

Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

[Brian Dickson]

On Tue, Jul 26, 2022 at 6:22 AM Petr Špaček  wrote:

> On 28. 06. 22 16:20, Bob Harold wrote:
>  > But the parent NS set is not covered by DNSSEC, and thus could be
> spoofed??
>  > (Wish we could fix that!)
>
> I share your wish.
>
> Does anyone else want to contribute?
>

I have an interest in fixing this, as it affects a number of issues beyond
the commonly referenced "privacy" issue.
E.g. Anything that relies on the name of the authoritative servers to
obtain e.g. TLSA records or generally establish a TLS connection.

I wrote up a draft a while back (just recently expired) on a suggestion to
improve the situation.

I'd be happy to revive this and/or work on something similar.

The main motivation for the technique I chose was to avoid placing any
requirements on Registry operators, including the out-of-band mechanism
(EPP) and publication mechanism (no new RRTYPEs, no new DS hash algorithms).
In other words, deployable unilaterally by DNS operators and Registrars,
and a modest set of changes for Resolvers (fully backward compatible).

Here is a link to the expired draft:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/

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

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

[Brian Dickson]

Honestly, since doing any sort of poll is "new", maybe the first poll
should have been, is doing this via a poll acceptable as a process/policy
thing for the WG?

Doing such a poll should include not only how folks feel about using polls
for this, but also could ask people to indicate the likelihood that they
would participate in future polls, as well as their opinions on how long
polls should run?

I have not answered the poll in question, FYI, and definitely prefer
discussing individual WG items, even if there happen to be a large number
of them.

I see this as a "vote with your feet" issue. Send many items to the list,
and the important ones will get responses (from the perspective of each
participant of what is important).

The result would basically have a figure-skating-judging element. What
matters is not the absolute numbers, what matters is the ordinality (sort
order) of participants, upon aggregation.

My $0.02.

Brian

On Thu, Jul 7, 2022 at 7:58 AM Paul Hoffman  wrote:

> On Jul 7, 2022, at 6:49 AM, Benno Overeinder  wrote:
> > Gentle reminder, the poll runs until July 9.
>
> Can you say how the poll will be used? There was pretty strong push-back
> after the original announcement, and it's thus unclear how the poll results
> will be acted on.
>
> --Paul Hoffman
>
> ___
> 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] CDS Bootstrapping for vanity DNS servers

[Brian Dickson]

On Tue, Jun 21, 2022 at 7:51 PM  wrote:

>
> Hi.
>
> During a meeting today of ROW (https://regiops.net), the I-D on CDS
> bootstrapping by using a DNSSEC-signed name at name server zone (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/)
> was discussed.
> In that discussion, it was mentioned that the current draft only supports
> out-of-bailiwick name servers; I replied that the same principle could be
> applied to in-bailiwick name server by usage of the reverse DNS zones for
> IPv4 and IPv6.
>
>
Even if that is true, why bother?

The whole point of the bootstrap mechanism is to onboard the *initial* DS
record for a particular domain securely.
Once the initial DS is present, there is no further need for bootstrap.
For a single domain, the only purpose of doing what you propose for a
"vanity" name server name, is to accomplish a one-shot action.

The use of some (any) third party DNS operator whose infrastructure zone(s)
is/are signed, for the purposes of doing the bootstrap, followed by
migrating the signed zone to another set of name servers securely (e.g. via
the multi-signer mechanisms, or via setting the zone up as a signed AXFR
from a hidden master), would achieve the same result without any new
proposals or implementations required. That would be two steps instead of
one, but only at the time of the initial DS. Once that DS is onboard at the
parent domain, the bootstrap operator is no longer involved.

Even if procuring the services from a DNS operator costs a small amount for
the time it takes to do the bootstrap and migration, knowing that it works
and is secure, and does not require any work on implementing something that
is never going to be reused, would seem to be a small price to pay.

You may even have friends operating their own signed zones, via which you
can bootstrap this way for free.

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

Re: [DNSOP] Wildcard junk vs NXDOMAIN junk

[Brian Dickson]

On Thu, Apr 7, 2022 at 9:51 AM John R. Levine  wrote:

> A friend of mine asserts that wildcard DNS records are a problem because
> hostile clients can use them to fill up DNS caches with junk answers to
> random queries that match a wildcard.  But it seems to me that you can do
> it just as well with random queries that match nothing and fill up the
> cache with NXDOMAIN junk answers.  Am I missing something here?
>
> If you add DNSSEC, with or without RFC 8198 response synthesis, the
> details change but I don't think answer does, it's about the same either
> way.
>

Yep, I agree.

However, that does provide motivation for (a) signing zones, and (b)
resolvers doing validation with synthesis.

Together, those reduce (a) load on auth servers, and (b) cache pollution.
Win/win.

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Thu, Apr 7, 2022 at 5:45 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> As I wrote:
>
> >> Such an individual would have to get access, create the records, give
> >> them to others, who then have to on-path attack you. At the TLD level
> >> and higher, this involves HSMs and physical access restrictions using
> >> a “four eyes minimum” approach.
>
> > Not surprisingly, diginotar was equally strongly secure.
>
> Are there anyone who still think DNSSEC were cryptographically secure
> or had protected TLDs more securely than diginotar?
>

I'm not sure why "thinks" enters into the conversation.

Nobody is entitled to their own facts, only their own opinions.

The facts are what matters here:

   - Each TLD has its own specific infrastructure, practices, etc.
  - Not all TLDs are equivalent for purposes of comparison of relative
  security (to each other or when compared to corresponding CA
infrastructure
  and practices)
   - Each TLD is a monopoly for the purposes of DNSSEC. The TLD operator
   has exclusive control over the delegations (including DNSSEC components) to
   registrants.
   - Registrants choose the TLD to use when they register a domain
   - Modulo the restrictions applicable to specific TLDs, the available
   choices of TLD are substantial
   - Each CA (including diginotar) is not a monopoly. Any CA can issue a
   certificate for any domain name.
   - Each CA has its own specific infrastructure, practices, etc.
  - Not all CAs are equivalent for purposes of comparison of relative
  security (to each other or when compared to corresponding TLD
  infrastructure and practices)

Taking these facts into consideration, the following assertions are clear
consequences:

   - Some CAs MAY have stronger infrastructure and practices than some TLDs
   - Some TLDs MAY have stronger infrastructure and practices than some CAs
   - It MAY be the case that some TLDs have infrastructure and practices
   that are not exceeded by those of any CA
  - Rephrased: some TLDs >= all CAs (which includes the boundary
  condition of "some TLDS == some CAs" without explicitly claiming that set
  is non-empty)
   - An attacker who wishes to compromise a domain via a WebPKI
   certificate, can choose which CA to use for this purpose
   - An attacker who wishes to compromise a domain via DNSSEC delegation,
   cannot choose which TLD to use for this purpose

Taken together, this means that as long as there exists any CA which is
weaker than some TLD, that automatically means that as a global system,
DNSSEC is more cryptographically secure than WebPKI.
And, given the facts regarding diginotar, this means that as a system,
DNSSEC is more cryptographically secure than diginotar.

QED

Registrants get to choose the TLD. Once that decision has been made, the
attacker has no alternatives to that TLD in terms of what would need to be
compromised to affect that specific domain.
The same is not true of CAs. Any CA being compromised places every domain
(regardless of TLD) in jeopardy, if the only protections on certificates
are those currently employed (e.g. CT, CRLs, OCSP).
If/when DANE (TLSA records) are used to improve certificate validation, the
choice of CA for the attacker to compromise is removed from the equation.

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

Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

[Brian Dickson]

On Fri, Mar 25, 2022 at 8:36 AM Benno Overeinder  wrote:

> As with the previous Call for Adoption today, at this week's DNSOP
> meeting at IETF 113, we announced that we are initiating a Call for
> Adoption for the draft-wisser-dnssec-automation.  With the survey we
> conducted for the last IETF 112, this draft was also a clear candidate.
>
> With this email we start a period of two weeks for the call for adoption
> of draft-wisser-dnssec-automation on the mailing list.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/.
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
>
I have read this draft.
I support adoption by the WG.
I am willing to review, contribute text, etc.

Brian


> This call for adoption ends: 8 April 2022
>
> Thanks,
>
> Suzanne, Tim and Benno
>
> ___
> 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] [Ext] More private algorithms for DNSSEC

[Brian Dickson]

On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews  wrote:

>
>
> > On 30 Mar 2022, at 00:28, Peter Thomassen  wrote:
> >
> >
> >
> > On 3/28/22 20:34, Mark Andrews wrote:
> >> About the only part not already specified is matching DS to DNSKEY
> using PRIVATEDNS but as you can see it is obvious to anyone with a little
> bit of cryptographic understanding.
> >
> > That creates problems plus complexity, which I find very undesirable.
> Orthogonality trumps complexity.
> >
> > For example, zones need to have a DNSKEY for each signing algorithm
> given in the DS record set. I would expect most implementations to
> currently only look at the algorithm number in this context, and not at the
> 253/254 algorithm identifier.
>
> And if they don’t implement any PRIVATEDNS or PRIVATEOID algorithm this is
> EXACTLY the correct behaviour.
>

You (Mark) are arguing that any experimentation would turn 253 in to a MUST
IMPLEMENT.
I think the other arguments (about having multiple algorithms allocated for
experimental usage) is more persuasive, including the nature of multiple
algorithms when experimentation is done.

This also keeps the 253 use case (actual private production use) distinct
from experimentation usage, thus preventing any negative interaction
between experiments and production zones.

(It's not about whether the behavior is correct, it's about whether there
is value added in selecting the 253 mechanism rather than reserving
experiment-only code points, IMHO.)


>
> > There will also be implementations which don't care to implement such
> "private algorithm peeking". For those, algorithm handling would not be
> ensured in the same way as it is for non-253/254 algorithms.
>
> Then they would be broken which by the way is why you run experiment.


This presupposes that only 253 is used, rather than what Paul H has
proposed in his very small draft. It's a moot point and not contradictory
to the proposal, to not want or need to do the peeking bit (i.e. not
supporting 253).


> > Last, I'm not convinced that running a PQ algorithm (or other)
> experiment to test (non-supporting) resolvers' behavior should require
> controlling a domain name or OID (as is required for 253/254).
>
> So rather than that you want to have to deal with potential colliding use
> of code points without identifiers.



>   You can’t
> reliably clean up experimental code points, especially if there are a lot
> of implementations.  DNS has a long tail.
>
> > These concerns bring us back to Nils' comment that 253/254 is not a good
> basis for performing research and doing real-life experiments.
> >
> >
> > The above headaches would be in addition to the effort of writing the
> clarification document, whereas Paul's proposal requires just the document.
>
> DNSSEC RFC say check the algorithm for a match.  They do not say check the
> number.  PRIVATEDNS and PRIVATEOID are sub typed
> and checking of those fields was always required once you implemented an
> algorithm in those spaces.
>

Everyone else is saying, we don't want this to be the way of doing
experiments (with lots of good reasoning behind that).
The "once you implemented" is a conditional that is not mandatory to
implement. There is also guidance now that sub-typing is not a good idea
for anything new in DNS.

I'd suggest that your argument is in fact suggesting the use of sub-typing
for something new (experiments rather than just private use) in DNS.


>
> > I therefore support the assignment of experimental algorithm numbers,
> and I think the text should mandate that they MUST be treated as unknown
> and have no special processing, unlike private ones.
>
> Stop calling for polluting of the commons.  We can’t properly cleanup
> after using experimental code points.
>

I think it is sufficient to reword Paul's proposal, so that the 7 new code
points are labeled "experimental" rather than "private use".

A few words about expected behavior of implementers ("Don't release
production code with these code points in use", along with "ship production
code to explicitly disallow use of these code points".)

DNS hasn't previously had explicitly allocated experimental code points for
algorithms, so how those do and do not get used probably needs some minimal
guidance.

I don't know if that belongs in this document, or as a separate document.
My instinct is "separate", and also that such a document doesn't need to be
a blocker on Paul H's document.

Maybe it is necessary to add some sort of explicit signaling about use of
experimental code points and that software involved in a particular
conversation (server or client) is in experimental mode.

The (potentially really bad) idea that occurred to me was, there's a
currently unused bit in the header, "Z", which is a vestigial remnant of
the larger Z field of "must be zero" from 103[345]. Perhaps that bit could
be re-labeled "X" (for experimental)?

Experimentation, including interoperability is a good thing. Leaving past
experiments' code 

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

[Brian Dickson]

On Fri, Mar 25, 2022 at 8:29 AM Benno Overeinder  wrote:

> As announced during the DNSOP meeting this week at the IETF 113, we are
> starting a Call for Adoption for the
> draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we
> conducted before the last IETF 112, this draft was a clear candidate.
>
> With this email we start a period of two weeks for the call for adoption
> of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>

I support adoption of this draft by the WG.

I am willing to contribute text, review, and may even have an
implementation available by the time it is ready for publication.

Brian Dickson


>
> This call for adoption ends: 8 April 2022
>
> Thanks,
>
> Suzanne, Tim and Benno
>
> ___
> 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] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

[Brian Dickson]

On Thu, Mar 24, 2022 at 4:08 PM Tim Wicinski  wrote:

>
> All
>
> If you attended the most recent DNSOP session, you've heard Warren speak
> about creating a BCP for DNSSEC, including  all of the DNSSEC related RFCs,
> in order to make life easier for implementers and DNS operators.
>
> We want to ask the working group if this is something DNSOP wants to work
> on. If so, we can work with Warren to prioritize getting through the
> approval process as efficiently as possible.
>
>
> This starts a Call for Adoption for: draft-hoffman-dnssec
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hoffman-dnssec/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
>
I support adoption of this by the WG.
I am willing to review, and to contribute text.

Brian Dickson


> This call for adoption ends: 7 April 2022
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
>
> ___
> 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] On removing a pargraph in RFC4035

[Brian Dickson]

On Thu, Mar 24, 2022 at 9:53 AM Ulrich Wisser  wrote:

> Hi Mark,
>
> Sorry for the late answer, IETF and some other stuff keeps me busy.
>
>
> Let’s start with this
>
> *We did not and do not propose to remove anything from RFC 4035. Currently
> we are asking for RFC 6840 to be amended *
>
> *RFC 6840 Se*ction 5.11
>
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They SHOULD NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work.
>
>
> PROPOSED CHANGE
>
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They *MUST* NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work.
>
>
>
> We absolutely do not want to enable lying. We want to enable transfer of
> domains between to signers using different algorithms.
>
> I share your analysis that this is possible today. It violates RFC 4035
> section 2.2. It should work given that you use two fairly well supported
> algorithms and your resolver follows the “SHOULD” in RFC 6840 section 5.11.
>
> So the first step is to change 6840 to “MUST”, so that resolvers use any
> validation path and do not insist on a specific or all algorithms being
> present.
>
> Secondly, problems arise if a resolver only supports one of the
> algorithms. In that case half of the answers would be considered bogus. We
> are looking for a way to make this work.
>
> I admit, the problem is not trivial, but I have faith in DNSOP! ( Please
> don’t prove me wrong. Pretty please!)
>

So, just to recap the problem(s) for which a solution is desired, and also
the implications/dependencies of various solutions to the problem(s):

   - Migrate a signed delegation from provider X using algorithm A only to
   provider Y using algorithm B only
   - Validators that support both A and B must always have validation
   result "secure" during the migration (before/during/after)
   - Validators that support only A or only B must always have validation
   result of "secure" or "insecure", never "bogus"
   - There may be (are?) validators deployed which, if they understand two
   algorithms (call them C and D, which may or may not be A and/or B
   respectively) require that if two DS exists (C and D), that the DNSKEY
   RRSET be signed by both C and D (signed == with SEP bit set)

Starting with the simplest corner case:

   - A validator that supports A but does not support B, will treat a DS
   RRSET which has both A and B, as if the B records do not exist, and thus
   the DS RRSET only contains A record(s). This means that if alg A DS record
   exists, the DNSKEY set MUST be signed with alg A.
   - Ditto for B
   - This results in a requirement that if two alg DS records exist (A and
   B), the DNSKEY set must be signed by both.
   - Changing the requirement on how a validator that supports both (A and
   B) does not remove this requirement, unfortunately.

This is a different corner case than the one for one algorithm, but two
provider's DS records, where each provider's version of the zone has one
KSK (their own) and two ZSKs (theirs and the other provider's). In that
situation, the DNSKEY set is validated by either KSK (which has a matching
DS), and enables both ZSKs (only one of which will actually sign each
provider's records), permitting validation of records of a mix/match
record+RRSIG in a cache.

I do have a solution which allows each provider to have exclusive control
of their respective private keys. It does not, however, involve both
providers both being "active" at any point in time.

I think this is the only viable mechanism, without having to go back to the
design phase of DNSSEC, unfortunately:

   - Start with provider X using algorithm A
   - Add provider Z also using algorithm A. The provider Z MUST support
   both A and B algorithms. (This might actually be the zone owner, or could
   be a third provider.)
   - Do the usual thing with each provider having their own KSK, and both
   ZSKs. Publish both DS records (one for each provider's KSK).
   - Remove provider X, unpublish X's DS, remove X's ZSKs (in the normal
   order of operations needed to not go insecure and not go bogus)
   - Have provider Z do an algorithm roll from A to B. Z can do this
   unilaterally, since Z would have private keys for both KSKs (one each of
   algorithm A and B)
   - Provider Z is now only publishing with algorithm B
   - Add provider Y using algorithm B (Y and Z both using algorithm B,
   normal single algorithm dual signer)
   - Remove provider Z
   - Profit

It should always be possible to find someone who can temporarily operate a
zone, who supports the two algorithms of the respective before and after
providers. At worst, this could involve self-hosting (possibly with use of
added providers 

Re: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org

[Brian Dickson]

On Wed, Mar 23, 2022 at 9:22 AM Petr Menšík  wrote:

> Because NSEC3 algorithm still does not have any alternative to SHA-1, hard
> crypto failure would be blocker for any our DNS products. I haven't heard
> about it even being considered this way.
>

I think this is a relatively common misconception. (I recently discovered
that I also misunderstood the situation.)

The first couple of algorithms specifically meant for NSEC3 use were
basically duplicates of algorithms that were NSEC-only, with new algorithm
numbers.
As I understand it, this was to ensure interoperability, in part due to
earlier implementations which would not be aware of NSEC3.
The new algorithms were a way of ensuring only updated software (which
could be guaranteed based on the algorithms being "new") would be expected
to understand (i.e. validate) NSEC3.

After that point, all new algorithms are both NSEC and NSEC3.

I believe that means you should be free to update to newer algorithms. I
would recommend both using Algorithm 13, and potentially moving away from
NSEC3 unless you have a strong reason for using it.

Or are you talking about what algorithms your software supports, in which
case this should be simple enough (to allow NSEC3 on newer algorithms).

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Paul Wouters wrote:
>
> >> Wrong. DNSSEC as PKI is not cryptographically secure subject to
> >> MitM attacks on CA chains, which is not more difficult than
> >> MitM attacks on ISP chains.
> >
> > I think at this point we have reached a point where your repeated
> > claims lack any merit
>
> So, you ignore diginotar to have demonstrated that PKI to
> blindly trust untrustworthy TTPs is cryptographically
> insecure.
>

This is where your error is introduced. DNSSEC does not involve blind
trust.

Previous statements by you (Ohta-san) in this thread, and observations or
counter-points:

If a resolver correctly knows an IP address of a nameserver of a
> parent zone and the resolver and the nameserver can communicate
> with long enough ID, the resolver can correctly know an IP
> address of a nameserver of a child zone, which is secure enough
> data origin security.
>

The difference between this model (client to server transport security
using IDs) and DNSSEC, is that DNSSEC is resistant to any MITM attacks, so
long as the resolver's root trust anchor is the same as the one published
by ICANN/IANA and used to sign the root zone.

It is correct that the single element is a necessary component of the trust
model for DNSSEC. It is not a dependency within DNSSEC that the endpoint's
connectivity must be transport-secured or impervious to hijack. DNSSEC does
not care where the data lives or how it is retrieved. It protects the data
cryptographically.

 The point is that DNSSEC, or PKI in general, is not cryptographically
> secure merely blindly trusting untrustworthy intermediate systems,
> which means it is against the end to end principle, improperly
> called TTPs (Trusted Third Parties).


I think this is where your argument fails. The trust in DNSSEC is not
blind. The validation which is done by a resolver can be confirmed by an
end-host, along the entire chain (tree) from root to leaf.

In order to achieve complete compromise, the adversary (e.g. state) would
need to compromise every software stack on every host and every resolver,
and block access to every external place that could provide contradictory
results.

Given that the root trust anchor is public, and published on the IANA's web
site with all the appropriate protections, this means anyone can publish
the same information on their own web site, e.g. protected by TLS.

The only way this would not be available to someone under the control of
that adversary, would be the compromise of every CA's cert, or publishing
competing certs for every TLS cert in existence, or to prevent any access
to external sites entirely.

The notion that a state exercising that level of control would also permit
the long-enough ID communication to enable your alternative to function,
does not seem credible.

This devolves down to two possibilities: your method is not viable if the
efforts needed to block use of the Root Trust Anchor are undertaken; or if
the efforts needed to block the Root Trust Anchor are not undertaken (in
their entirety), attempts to replace the Root Trust Anchor are detectable,
which also means the real Root Trust Anchor can be obtained and validated,
and once the latter is done, DNSSEC continues to be cryptographically
secure.

The actual real root trust anchor is not feasible to compromise, nor are
the signing mechanisms involved for signing the root zone. A secured root
zone and root trust anchor makes it impossible to compromise any zone
protected by its parent, with the root zone anchoring those protections.

DNSSEC is not blind trust. The ability to compromise via spoofing requires
compromise of a parent. The root zone cannot feasibly be compromised.
Therefore DNSSEC is secure.

 I concur with the rest of the folks on this thread, this subject thread is
effectively concluded.

This message is mostly for your (Ohta-san's) benefit to understand why
DNSSEC is not in the same category as WebPKI in terms of the trust model
and trust mechanisms.

There is an analogy in infinities:
The rational numbers and real numbers are both infinite, but the infinity
of the real numbers is "uncountable", a larger infinity than the infinity
of the rational numbers, which are "countable".

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Mon, Mar 21, 2022 at 5:28 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Paul Wouters wrote:
>
> >> If a resolver correctly knows an IP address of a nameserver of a
> >> parent zone
> >
> > This statement seems a recursion of the original problem statement?]
>
> What?
>
> The statement is not more demanding for resolvers to be configured
> with correct certificates.
>

I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a certificate per se.

I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS, either DNS over TLS to
Authority, or DNS over HTTPS to Authority, including root, TLD and all
authority servers for all zones).

I'll use that assumption in the remainder of this message...


>
> > This would not help for on-path attackers (without DoT, DoH)
>
> See below.
>
> > How would this be safe against the current BGP attacks we are seeing?
>
> Are you saying connecting to an IP address secured by DNSSEC
> is safe even under BGP attacks?
>

The complete model of using DNSSEC involves also using TLSA records (DANE).
In the DNSSEC-protected TLSA record model, BGP attacks have no direct
impact on DNSSEC-protected zones, including BOTH the address records
(A/) AND the TLS information (complete certificate, or public key, or
hash of either of those), and consequently no impact on the TLS connections
subsequent to the DNS lookups (i.e. no possible cert-level MITM or web site
spoofing).

The exclusive capability of a MITM would be to DOS the DNS lookups, or to
block the TLS set-up (if the attacker were on the data path to the
endpoint).

So, yes, a web site properly protected using all of the DNSSEC-based
capabilities, where the client software was doing the validation using the
corresponding methods, would be safe against any and all MITM attacks,
including BGP.

Note that this is already the case for SMTP (using SMTPS via TLSA records).
Those SMTP connections between parties publishing and validating TLSA
records are not subject to downgrade attacks, and only properly validated
endpoints can communicate (securely).


>
> >> As for MitM attacks, PKI, in general, is insecure against
> >> them as was demonstrated by diginotar. So, don't bother.
> >
> > DNSSEC is more hierarchical than the "bag of CAs", so a failure
> > like this would be more contained. Regardless, I do not understand
> > how PKI failures relate to DNS?
>
> Are you saying you don't understand DNSSEC is a form of PKI?
>

I'm reasonably sure that Paul W meant "WebPKI" when he said PKI.

WebPKI is effectively a "flat namespace" sort of PKI, meaning a bunch of
CAs all have the right to issue certificates, with no exclusivity (which is
part of what lead to the diginotar thing).

By comparison, DNSSEC is an exclusively hierarchical, singular control
point PKI system. At each level of the hierarchy, the public keys are under
the exclusive control of the zone owner/administrator/operator, and signed
by the parent zone.
(Any concerns on the out-of-band update aspects are potentially worthy of
work, but that is also the case for the OOB update aspects for WebPKI.)


>
> >> IETF can do nothing if some government legally force
> >> people to install some government provided certificates
> >> to some PKI, including DNSSEC, which is as easy as
> >> MitM attacks on ISP chain may be by government order.
> >
> > With DNSSEC, a government in country X cannot spoof data of
> > country Y, they can only block it.
>
> Country X legally forcing people to install government provided
> root certificates can freely spoof PKI, including DNSSEC, data
> of country Y.
>

This is another place where the "flat" WebPKI vs the "hierarchical" DNSSEC
models are not exactly the same.

In addition to resolvers, end hosts have the ability to do DNSSEC
validation (on data received from resolvers).

Any host (resolver or end host) is capable of installing trust anchors for
any level of the DNS hierarchy, which would preempt any spoofed delegation
information (DS records) and reduce unsigned delegation spoofery to the
aforementioned DOS level of interference. End hosts would never see the
spoofed answers.

End hosts may also have some ability to make use of other resolvers (very
much dependent on local conditions, of course).

The scope of what country X can do with respect to country Y, is limited by
any number of orthogonal elements.
Those include

   - geographical limits (e.g. the physical boundary of country X)
   - topological considerations (all the paths from every host/user to the
   outside world)
   - resolvers reachable by any/all hosts/users
   - host/application configuration on all of the resolvers and hosts
   - necessity of altering responses at every level of the DNS hierarchy by
   on-path changes for all of the above elements

Additionally, outside of the physical geographical boundary of country X,
nothing country X can do can accomplish 

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Brian Dickson]

On Wed, Dec 15, 2021 at 2:01 PM Paul Vixie  wrote:

>
>
> Wessels, Duane wrote on 2021-12-15 13:17:
> > ...
> >
> > On one hand I think it would be a lot simpler to just say that only
> address records can be glue.  But I’m not sure that is defendable given the
> directions things are going.  Here’s a definition of glue that I came up
> with:
> >
> > Glue is non-authoritative data in a zone that is transmitted in the
> additional section of a referral response on the basis that the data might
> be necessary for resolution to proceed at the referred name servers.
> >
> > ...
>
> if glue is non-authoritative data in a zone then it has to be below a
> zone cut; you might make that clear.
>

Overly-pedantic clarification on wording/semantics:

   - Glue is non-authoritative data in a zone, where the owner name of that
   glue data is below some zone cut (or otherwise out-of-zone, like
   different-TLD, if that is even permitted by the zone owner's policies.)



>
> if glue is in a zone it will be carried by zone transfers not just
> referrals; you might make that clear.
>
> otherwise, +1.
>
>
Also +1.

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-ds-hack-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-ds-hack
Revision:   02
Title:  DS Algorithms for Securing NS and Glue
Document date:  2021-09-19
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-02

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-glueless-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-glueless
Revision:   02
Title:  Operating a Glueless DNS Authority Server
Document date:  2021-09-22
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-02

Abstract:
   This Internet Draft proposes a method for protecting authority
   servers against MITM and poisoning attacks, using a domain naming
   strategy to not require glue A/ records and use of DNSSEC.

   This technique assumes the use of validating resolvers.

   MITM and poisoning attacks should only be effective/possible against
   unsigned domains.

   However, until all domains are signed, this guidance is relevant, in
   that it can limit the attack surface of unsigned domains.

   This guidance should be combined with [I-D.dickson-dnsop-ds-hack]




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-dnst-00.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-dnst-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-dnst
Revision:   00
Title:  Resource Record for Signaling Transport for DNS to
Authority Servers
Document date:  2021-10-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.txt
Status: https://datatracker.ietf.org/doc/draft-dickson-dprive-dnst/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-dnst


Abstract:
   This Internet Draft proposes an RRTYPE to signal explicit support for
   transport types for DNS service.  This new RRTYPE is "DNST".  The
   available transports to signal are TCP and UDP on port 53 (DNS), and
   DoT (DNS over TLS) transport using TCP port 853.




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-06.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-adot-auth-06.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-adot-auth
Revision:   06
Title:  Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-11-09
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-06

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of various techniques for
   efficiency and scalability, and new EDNS options to minimize round
   trips and for signaling between clients and resolvers.




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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Brian Dickson]

FYI, I too like it and believe it should progress.
(We will likely implement it once it is published, too.)

Brian

On Tue, Oct 19, 2021 at 6:20 PM Bill Woodcock  wrote:

>
>
> > On Oct 20, 2021, at 3:07 AM, Paul Hoffman 
> wrote:
> >
> > Just noting that no one has said anything about this draft since it was
> published almost 6 months ago, and it is the topic of next week's interim
> meeting.
>
> We like it, will implement it when it becomes a thing, and believe it
> should move forward.
>
> -Bill
>
> ___
> 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] Question on interpretation of DO and CD

[Brian Dickson]

Sent from my iPhone

> On Oct 7, 2021, at 12:55 AM, Joe Abley  wrote:
> 
> On Oct 7, 2021, at 09:49, Brian Dickson  
> wrote:
> 
>> Quick question in a top-reply, sorry:
>> Mark:
>> Is there any combination of flag bits or EDNS options that a stub can use to 
>> reliably determine if a resolver is validating?
> 
> Do you mean reliably determine if a resolver is claiming to validate, or 
> reliably determine whether a resolver is actually validating?
> 

Claiming… if the answer is that it is not claiming that, it might simplify some 
parts of the logic on use of CD.

If there isn’t any way to reliably determine that it is claiming to validate, 
that is unfortunate, and then begs the question on whether it is worth doing 
anything about it.

Brian 

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

Re: [DNSOP] Question on interpretation of DO and CD

[Brian Dickson]

Quick question in a top-reply, sorry:
Mark:
Is there any combination of flag bits or EDNS options that a stub can use
to reliably determine if a resolver is validating?

Obviously there are clever tricks possible, such as sending queries to a
small set of domains that identify whether resolvers validate (at all
and/or correctly), that have been used in some previous tests by George and
Geoff.

But, are there ways that give immediate confirmation (and can be used on
every query) of the DNSSEC-validating status of a resolver?

Brian

On Wed, Oct 6, 2021 at 11:53 PM Mark Andrews  wrote:

>
>
> > On 7 Oct 2021, at 15:49, George Michaelson  wrote:
> >
> >> First of all, it is apparent that if a resolver maintains a unified
> cache in which it has DNSSEC-aware and DNSSEC-oblivious data, things will
> definitely break.  The general wisdom appears to be that you need to
> maintain two caches, and only answer DO-set queries with DO-set cache (or
> go fetch); but if there's ever been explicit protocol requirement of this,
> I have forgotten it.
> >
> > Sorry, but I think this is just an over-reach. There is no necessary
> > reason for a single information model to break. It is about how you do
> > it. The problem of course is transitive links in the tree from one
> > state (signed) to the other (unsigned) and back again, and associated
> > meta data. Arguably, its one information model, one cache,  but the DO
> > bit flagging limits what answers you can tell people and you have to
> > reply with SERVFAIL for information you hold, even though you know the
> > next query might well be for the same info without DO force.
> >
> > It may well be logistically simpler to run two caches, but this
> > statement seems to me to be over-stating things.
>
> Very much so.
>
> Eric,
>   DNSSEC validation does not work *reliably* if the upstream resolvers
> are not *validating*.  Anyone that does a rigorous analysis of the protocol
> will tell you this.
>
> DNSSEC will work reasonably well if the upstream are just DNSSEC aware
> (keep the
> RRSIGs with the data they cover, pass through negative proofs required for
> the answers) if there is not spoofed traffic, a mix of DNSSEC aware and
> DNSSEC
> oblivious server for the zone, etc.  A validating upstream will block this
> badness and only pass through good responses. A non-validating upstream
> will
> cache this garbage.
>
> It will fail abysmally if the upstreams are not DNSSEC aware.  Don’t even
> attempt it.
>
> I know many on this list don’t like hearing this, that they would like it
> if DNSSEC aware was enough so that intermediate resolvers don’t need to
> validate.  They are fooling themselves.  This is where the "just send CD=1"
> came from.  The fear that the upstream will have a bad trust anchor or bad
> time are just that, fears. If a upstream has a bad clock or bad trust
> anchors
> then everything will be failing and it will get fixed.  Just send DO=1,CD=0
> and on the few cases where you get SERVFAIL return with DO=1,CD=1.
>
> Now there are some improvements that could be made to make the protocol
> even more robust when there are intermediate resolvers.  Passing the
> trust anchors (DS record form) the downstream is using to the upstream
> to improve the robustness of the process.  One could also pass the clients
> concept of time.
>
> Mark
>
> > G
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> 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] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Brian Dickson]

On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters  wrote:

> On Wed, 6 Oct 2021, Paul Hoffman wrote:
>
> > Greetings again. I think that all of the issues from the WG on
> draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant
> one. Almost a year ago, Tony Finch started a thread about 8499's
> definitions of bailiwick and sibling glue. The thread is
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/5bKXkqzCyGE1NuUko9M6wXLD5bI/>
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/fAopdUTnVS2mDF71eiGsRdu9zco/>
> >   <
> https://mailarchive.ietf.org/arch/msg/dnsop/PqH_WMhsP5zxRfjKD4gtmf6nw54/>
> >
> > The WG should come to agreement on this so that we can close out the
> document. Please read these messages and comment here about changes you do
> or don't want to be made to the current draft.
>
> The suggestion by Tony Finch:
>
>
>* Sibling zones: two zones whose delegations are in the same
>  parent zone.
>
>* Sibling glue: addresses of nameservers that are in a sibling zone.
>
> I agree with the above part. But the next part I do not agree with:
>
>  Sibling glue is usually the glue that the DNS would require for that
>  sibling zone, but in some cases the requirement lies elsewhere, for
>  example
>
> one.example.NS  nsa.two.example
> one.example.NS  nsb.two.example
> two.example.NS  ns0.two.example
> two.example.NS  ns1.two.example
>
> The DNS protocol does not require sibling glue for the one.example
> nameservers, though glue addresses might be required by .example
> registry policy.
>

It is perhaps worth referencing (informally?) the expired draft (version 05
from 2015):
https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05

I think it may be more appropriate to extract the important behavior
expectations needed for interoperability.
My understanding is as follows:

   - Whatever glue there is in the delegating zone is required (by RFCs?)
   to be served.
   - What glue is accepted or provided (or is required) may differ by
   parent policies or operator practices
   - The glue for sibling zones may or may not be needed for resolution.
   - Resolution may not be possible if glue that should have been present
   is not present
   - In-bailiwick for queries received by a server where the QNAME falls
   below a zone cut is any name at or beneath the parent zone, not the child
   zone. If the example TLD gets a query for foo.example, and the NS for
   foo.example falls under bar.example, both foo and bar are in-bailiwick
   names (at least that is my understanding, which was recently enlarged based
   on previous misunderstandings)

Brian


>
> I find the talk about "in the DNS protocol" and pulling in "registry
> policy" confusing and unneeded.
>
> As a seperate problem in the 2nd references email, I agree that the
> term "in-bailiwick" probably changed meaning from "within this
> delegation or below" to "the data related to this delegation". Eg
> when processing additional records, "in-bailiwick" is interpreted
> as "needed for completing DNS resolution for all NS entries in this
> delegation" and could be RRs from other TLDs and their dependencies.
>
> For example, in this updated meaning, the A record for ns0.nohats.ca
> is "in-bailiwick" to libreswan.org and a resolver could add the A
> record for ns0.nohats.ca (and/or DNSKEY etc) to an answer for NS
> of libreswan.org. This new use of "in-bailiwick" seems more common
> too when thinking of resolver to stub and DNSSEC validation, eg
> with chain-query and tls-dnssec-chain. Possible this dual use let
> to the new term "in-domain" ?
>
> As for the third message quoted, I do not agree that "in-bailiwick is
> a property of a nameserver". I believe it is a term related to the
> NS/A records of the QNAME, not of a nameserver.
>
> Paul
>
> ___
> 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] FYI: WG adoption of DNS binding in ADD

[Brian Dickson]

Sorry folks, I misread the draft that is in WG adopt request state.

The name on it, and the terminology used in it, mislead me to thinking it
was specifically for authoritative servers, rather than resolvers.
(It is about the latter, but worded and named as if it could apply to
authoritative servers. I'm not at all convinced it would be useful or a
good alignment of use cases.)

I think it SHOULD be limited in scope to recursives, in which case it would
belong in ADD. (But that is a hard IF and ONLY IF, IMNSHO).

Brian

On Mon, Sep 27, 2021 at 2:18 PM Brian Dickson 
wrote:

> In case anyone does not follow the ADD WG, or does not closely follow
> DPRIVE, there is a WG adoption call for an SVCB binding for DNS.
>
> There are two days left in that adoption call.
>
> I encourage folks to take a look and give feedback concerning where they
> think any such draft belongs (e.g. DNSOP in stead), plus on the draft's
> readiness and suitability.
>
> (My opinion is that there are use cases beyond those in ADD, and the right
> place to address the possibly conflicting requirements is DNSOP, and that
> the ADD WG should not adopt it.)
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] FYI: WG adoption of DNS binding in ADD

[Brian Dickson]

In case anyone does not follow the ADD WG, or does not closely follow
DPRIVE, there is a WG adoption call for an SVCB binding for DNS.

There are two days left in that adoption call.

I encourage folks to take a look and give feedback concerning where they
think any such draft belongs (e.g. DNSOP in stead), plus on the draft's
readiness and suitability.

(My opinion is that there are use cases beyond those in ADD, and the right
place to address the possibly conflicting requirements is DNSOP, and that
the ADD WG should not adopt it.)

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