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

[Paul Vixie]

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



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



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

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


+1.

--
P Vixie

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

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

[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] [Ext] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Mark Andrews]

Well anyone using RedHat Enterprise Linux 9 / Oracle Linux 9 already has 
RSASHA1 / NSEC3RSASHA1 disabled.

BIND will automatically disable these algorithms as of the September releases 
if they are not supported by the crypto provider.  So it will no longer require 
named.conf changes. 

-- 
Mark Andrews

> On 18 Aug 2022, at 08:45, Viktor Dukhovni  wrote:
> 
> On Tue, Aug 16, 2022 at 02:55:35PM +, Paul Hoffman wrote:
> 
>> Another way to look at this is not from all signed delegations
>> anywhere, but for web sites that are most popular. Using the Tranco
>> list, choosing from the top 100,000 names, 6,389 are signed; of those,
>> 349 sign with algorithm 5 or 7. Thus, for the popular sites, the
>> percentage is closer to 5%, not 1%.
> 
> While I'm not impressed by the significance of the last ~900k of the
> Tranco list, indeed there is some concentration of deprecated DNSSEC
> algorithms closer to the top of the list, among the top 10k we see
> the domains below my sig.
> 
> How realistic is it to prod these to migrate?  The DHS folks had
> recently put out an RFP for managed DNS service, not only for the .GOV
> registry, but also for operation of the delegated domains, and
> presumably at some point many of the .GOV slowpokes might move to a
> managed service with more modern keys, ...  This will likely take
> a couple of years (if not delayed or cancelled).
> 
> As for the rest, not clear what would cause them to switch, and how hard
> we should try.  There hasn't been much downward momentum in algorithm 5
> and 7 use after the initial 93% decline at major hosting providers.
> 
> [ Even transip.nl, who've migrated all their customers, haven't yet
> migrated their own domain.  Cobbler's children and all that... ]
> 
> -- 
>Viktor.
> 
> paypal.com 77
> comcast.net 145
> cdc.gov 179
> ietf.org 473
> yandex.com 548
> paloaltonetworks.com 633
> xfinity.com 646
> va.gov 650
> nist.gov 664
> service-now.com 842
> comcast.com 901
> cmu.edu 939
> uchicago.edu 991
> ed.gov 999
> uk.com 1065
> census.gov 1108
> sec.gov 1148
> senate.gov 1176
> icann.org 1333
> accenture.com 1369
> centralnic.net 1433
> archives.gov 1489
> tamu.edu 1542
> uspto.gov 1565
> treasury.gov 1584
> fcc.gov 1638
> us.com 1671
> paypal.me 1918
> pitt.edu 1998
> eu.com 2648
> hud.gov 2668
> defense.gov 2806
> mass.gov 2923
> eia.gov 2946
> federalregister.gov 2996
> cms.gov 3030
> filezilla-project.org 3168
> lsu.edu 3204
> nsf.gov 3292
> imperial.ac.uk 3434
> maryland.gov 3537
> tn.gov 3667
> transip.nl 3962
> supremecourt.gov 4113
> us.org 4305
> ky.gov 4382
> gao.gov 4583
> lbl.gov 4598
> medicare.gov 4633
> handle.net 4699
> ustc.edu.cn 4706
> paypalobjects.com 5051
> d-net.pro 5119
> healthcare.gov 5123
> consumerfinance.gov 5458
> tznic.or.tz 6065
> ru.com 6243
> planalto.gov.br 6366
> kh.edu.tw 6652
> ga.gov 6658
> uib.no 6738
> umbc.edu 6869
> hrsa.gov 7076
> k8.com.br 7217
> paypalinc.com 7314
> nrel.gov 7599
> uniregistry.info 7608
> llnl.gov 7663
> export.gov 7833
> ic.ac.uk 7890
> treas.gov 8072
> upf.edu 8217
> concordia.ca 8258
> nga.gov 8366
> in.net 8431
> nau.edu 8480
> ulisboa.pt 8650
> comcastbusiness.net 8769
> bea.gov 9250
> uscg.mil 9579
> szu.edu.cn 9745
> nsa.gov 9862
> uniregistry.net 9974
> 
> ___
> 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] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Viktor Dukhovni]

On Tue, Aug 16, 2022 at 02:55:35PM +, Paul Hoffman wrote:

> Another way to look at this is not from all signed delegations
> anywhere, but for web sites that are most popular. Using the Tranco
> list, choosing from the top 100,000 names, 6,389 are signed; of those,
> 349 sign with algorithm 5 or 7. Thus, for the popular sites, the
> percentage is closer to 5%, not 1%.

While I'm not impressed by the significance of the last ~900k of the
Tranco list, indeed there is some concentration of deprecated DNSSEC
algorithms closer to the top of the list, among the top 10k we see
the domains below my sig.

How realistic is it to prod these to migrate?  The DHS folks had
recently put out an RFP for managed DNS service, not only for the .GOV
registry, but also for operation of the delegated domains, and
presumably at some point many of the .GOV slowpokes might move to a
managed service with more modern keys, ...  This will likely take
a couple of years (if not delayed or cancelled).

As for the rest, not clear what would cause them to switch, and how hard
we should try.  There hasn't been much downward momentum in algorithm 5
and 7 use after the initial 93% decline at major hosting providers.

[ Even transip.nl, who've migrated all their customers, haven't yet
migrated their own domain.  Cobbler's children and all that... ]

-- 
Viktor.

paypal.com 77
comcast.net 145
cdc.gov 179
ietf.org 473
yandex.com 548
paloaltonetworks.com 633
xfinity.com 646
va.gov 650
nist.gov 664
service-now.com 842
comcast.com 901
cmu.edu 939
uchicago.edu 991
ed.gov 999
uk.com 1065
census.gov 1108
sec.gov 1148
senate.gov 1176
icann.org 1333
accenture.com 1369
centralnic.net 1433
archives.gov 1489
tamu.edu 1542
uspto.gov 1565
treasury.gov 1584
fcc.gov 1638
us.com 1671
paypal.me 1918
pitt.edu 1998
eu.com 2648
hud.gov 2668
defense.gov 2806
mass.gov 2923
eia.gov 2946
federalregister.gov 2996
cms.gov 3030
filezilla-project.org 3168
lsu.edu 3204
nsf.gov 3292
imperial.ac.uk 3434
maryland.gov 3537
tn.gov 3667
transip.nl 3962
supremecourt.gov 4113
us.org 4305
ky.gov 4382
gao.gov 4583
lbl.gov 4598
medicare.gov 4633
handle.net 4699
ustc.edu.cn 4706
paypalobjects.com 5051
d-net.pro 5119
healthcare.gov 5123
consumerfinance.gov 5458
tznic.or.tz 6065
ru.com 6243
planalto.gov.br 6366
kh.edu.tw 6652
ga.gov 6658
uib.no 6738
umbc.edu 6869
hrsa.gov 7076
k8.com.br 7217
paypalinc.com 7314
nrel.gov 7599
uniregistry.info 7608
llnl.gov 7663
export.gov 7833
ic.ac.uk 7890
treas.gov 8072
upf.edu 8217
concordia.ca 8258
nga.gov 8366
in.net 8431
nau.edu 8480
ulisboa.pt 8650
comcastbusiness.net 8769
bea.gov 9250
uscg.mil 9579
szu.edu.cn 9745
nsa.gov 9862
uniregistry.net 9974

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

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

[Paul Vixie]

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


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


...


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


+1.

--
P Vixie

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

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

[Timothy Mcsweeney]

> On 08/17/2022 3:24 PM EDT Paul Hoffman  wrote:
> 
>
> The last bullet in  feels like 
> this draft is part of the DNSOP charter. That's why the WG adopted the draft 
> and it made it to WG Last Call.


I read that as the second sentence of #6 is only referring to 'work' within the 
scope of the 4 items within first sentence.

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

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

[Paul Hoffman]

> On Aug 17, 2022, at 12:11 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.

Are you asking that this document tell the non-DNS protocols how to handle 
names that end in .alt? If so, please suggest text. Personally, I think it is 
better to let all protocols that we don't control to make their own rules.

> More importantly this proposal now sounds like an non-DNS un-restricted 
> naming scope which puts it out the DNSOP charter right? 

The last bullet in  feels like 
this draft is part of the DNSOP charter. That's why the WG adopted the draft 
and it made it to WG Last Call.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Timothy Mcsweeney]

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

Tim

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-02.txt

[Peter Thomassen]

Dear DNSOP,

Thank you for the review of -01! We have addressed the feedback and sorted out 
the remaining editorial issues. For a summary, see below.

We are not aware of any outstanding questions or issues. The protocol is now in 
production at Cloudflare and SWITCH, amongst others.

Given this state of things, we would like to propose advancing the draft to the 
next stage once the WG feels that the time has come.


Most significant changes since -01:

| Clarified that RFC 8078 Section 3 is not replaced, but its methods
| are deprecated. (Libor's suggestion -- thanks!)
|
| Included NSEC walk / AXFR as possible triggers for DS
| bootstrapping. (John's suggestion -- thanks!)

Other changes since -01:

| Added new deployments to Implementation section.
|
| Editorial changes.


Thanks,
Peter


On 8/17/22 14:47, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

 Title   : Automatic DNSSEC Bootstrapping using Authenticated 
Signals from the Zone's Operator
 Authors : Peter Thomassen
   Nils Wisiol
   Filename: draft-ietf-dnsop-dnssec-bootstrapping-02.txt
   Pages   : 15
   Date: 2022-08-17

Abstract:
This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis.  The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex.  The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay" ([RFC8078]).

This document deprecates the DS enrollment methods described in
Section 3 of [RFC8078] in favor of Section 3 of this document.

[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Automatic DNSSEC Bootstrapping using Authenticated 
Signals from the Zone's Operator
Authors : Peter Thomassen
  Nils Wisiol
  Filename: draft-ietf-dnsop-dnssec-bootstrapping-02.txt
  Pages   : 15
  Date: 2022-08-17

Abstract:
   This document introduces an in-band method for DNS operators to
   publish arbitrary information about the zones they are authoritative
   for, in an authenticated fashion and on a per-zone basis.  The
   mechanism allows managed DNS operators to securely announce DNSSEC
   key parameters for zones under their management, including for zones
   that are not currently securely delegated.

   Whenever DS records are absent for a zone's delegation, this signal
   enables the parent's registry or registrar to cryptographically
   validate the CDS/CDNSKEY records found at the child's apex.  The
   parent can then provision DS records for the delegation without
   resorting to out-of-band validation or weaker types of cross-checks
   such as "Accept after Delay" ([RFC8078]).

   This document deprecates the DS enrollment methods described in
   Section 3 of [RFC8078] in favor of Section 3 of this document.

   [ Ed note: This document is being collaborated on at
   https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
   (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
   The authors gratefully accept pull requests. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[Paul Hoffman]

On Aug 17, 2022, at 7:56 AM, Timothy Mcsweeney  wrote:
> The Abstract says "a TLD label in non-DNS contexts".
> Non-dns is outside the root right?

Pedantic use of terminology is kinda important here. In this case, a name that 
ends in ".alt" is never part of the global DNS because .alt will not be 
delegated in the global DNS's root zone.

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

> Maybe it was the part in 4.1 that threw me off.  where it says "(and names 
> ending with the string .alt)"
> Or could be 4.1(7) where is says 'to register ".alt" names'

Yep, 4.1 is somewhat confusing.

> 
> But this part is super-genius "These
>   ".alt" names are defined by protocol specification to be
>   nonexistent"
> I had no idea you could specify non-existance.  I'm going to have to try that!

As Ray points out, if a TLD is not in the root zone, and the root zone is 
signed with DNSSEC, all names that would end in that (pseudo-) TLD are 
inherently non-existent to any validating resolver.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

On 17. 08. 22 17:09, Daisuke HIGASHI wrote:
Peter van Dijk >:



Thank you for reviewing my implementation.

Note that the function called "probe_pmtu" does not really probe. At
best, it finds some data the kernel cached recently. At worst (i.e.
usually), it tells you the MTU of your local networking interface.


That's correct.


 > - A first response (to requester with small PMTU) can be lost because
 > nobody knows PMTU for destination that a large packet was never sent.
 > It slows down name resolution - Fortunately this is not a big problem
 > because 1) will be recovered by retransmission by the requestor

(a) why would a requestor retransmit? (b) why would the retransmit help?


1) Responder receives first request and makes response (DF=1) that size 
is exceeding PMTU and it was not received by requester.

2) Responder should receive ICMP NEEDFRAG and knows PMTU.


And at this step we opened the attack window to ICMP-based fragmentation 
attacks again.


3) Requester (resolvers) _would_ retransmit same request after timeouts 
if none of response is received.


Possibly. Or it can retransmit to another address, or possibly routed to 
another node in anycast cloud. Or via another path. Or just fallback to 
TCP and don't bother with UDP anymore.


4) Responder composes DNS message fitting in PMTU or TC=1 (if does not 
fits in).



I admit that my current implementation (responder's behavior which the 
I-D describes, in my understanding) relies on requester's timeout / 
retransmission strategy and when PMTU cache information expires same 
timeout event would occurs again.


This is completely unreliable, I'm afraid.

--
Petr Špaček

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

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

[Peter Thomassen]

On 8/17/22 10:20, Paul Hoffman wrote:

On Aug 17, 2022, at 6:19 AM, Timothy Mcsweeney  wrote:


Are you proposing dot Alt, or are you proposing dot Alt dot.?


Please see , the 
draft in question. It has already gone through WG Last Call, but has been held there 
for possible revision.


Indeed the document is unclear about whether the ALT namespace has a final 
empty label or not. As Tim points out:


Introduction:
   This document reserves the label "ALT" (short
   for "Alternative") as a Special Use Domain ([RFC6761]).  This label
   is intended to be used as the final (rightmost) label to signify that
   the name is not rooted in the DNS, and that it should not be resolved
   using the DNS protocol.

That sounds like no empty label. And it sounds very consistent with a non-DNS 
approach. Perhaps the empty label is a DNS specialty that other namespaces 
don't share.


Section 4.1:
   This section is to satisfy the requirement in Section 5 of RFC6761.

   The string ".alt." (and names ending with the string .alt) are
   special in the following ways:

That sounds like there is an empty label. The ALT namespace would then be a 
carve-out of the DNS namespace.


Which way is it?

I think it's important to clarify that (here and in the document). (The answer may be 
implicit in other documents that define "domain names", but regardless, we 
should make sure there are no misunderstandings about what exactly the draft specifies.)


Best,
Peter

--
https://desec.io/

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

[DNSOP] ALT root

[Timothy Mcsweeney]

Hey Ray!  long time no talk to!
 
Remeber this clip [1] from the movie Contact with the billionaire in the plane? 
[1] https://youtu.be/Et4sMJP9FmM?t=119

I think thats what's happening here.  Personally I'm all for the ALT root.  If 
you guys don't want to do it maybe I will.

 
 

> On 08/17/2022 11:01 AM EDT Ray Bellis  wrote:
> 
>  
> On 17/08/2022 15:56, Timothy Mcsweeney wrote:
> 
> > But this part is super-genius "These ".alt" names are defined by
> > protocol specification to be nonexistent" I had no idea you could
> > specify non-existance.  I'm going to have to try that!
> 
> I believe the intention was that the DNSSEC nsec records in the root
> zone would deny that .alt exists, helping to enforce separation from the 
> "DNS protocol namespace" and anything under .alt.
> 
> Ray
> 
> ___
> 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

[Daisuke HIGASHI]

Peter van Dijk :

>
Thank you for reviewing my implementation.

Note that the function called "probe_pmtu" does not really probe. At
> best, it finds some data the kernel cached recently. At worst (i.e.
> usually), it tells you the MTU of your local networking interface.


That's correct.

>
> > - A first response (to requester with small PMTU) can be lost because
> > nobody knows PMTU for destination that a large packet was never sent.
> > It slows down name resolution - Fortunately this is not a big problem
> > because 1) will be recovered by retransmission by the requestor
>
> (a) why would a requestor retransmit? (b) why would the retransmit help?


1) Responder receives first request and makes response (DF=1) that size is
exceeding PMTU and it was not received by requester.
2) Responder should receive ICMP NEEDFRAG and knows PMTU.
3) Requester (resolvers) _would_ retransmit same request after timeouts if
none of response is received.
4) Responder composes DNS message fitting in PMTU or TC=1 (if does not fits
in).

I admit that my current implementation (responder's behavior which the I-D
describes, in my understanding) relies on requester's timeout /
retransmission strategy and when PMTU cache information expires same
timeout event would occurs again.

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

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

[Ray Bellis]

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


But this part is super-genius "These ".alt" names are defined by
protocol specification to be nonexistent" I had no idea you could
specify non-existance.  I'm going to have to try that!


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


Ray

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

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

[Timothy Mcsweeney]

Paul, 

The Abstract says "a TLD label in non-DNS contexts".
Non-dns is outside the root right?

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?

Maybe it was the part in 4.1 that threw me off.  where it says "(and names 
ending with the string .alt)"
Or could be 4.1(7) where is says 'to register ".alt" names'

But this part is super-genius "These
   ".alt" names are defined by protocol specification to be
   nonexistent"
I had no idea you could specify non-existance.  I'm going to have to try that!

Tim



> On 08/17/2022 10:20 AM EDT Paul Hoffman  wrote:
>

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

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

[Independent Submissions Editor (Eliot Lear)]

On 17.08.22 16:20, Paul Hoffman wrote:

The discussion with the Independent Submissions Editor appears to be about 
whether they are interested in using a TLD that would different TLD or 
pseudo-TLD in order to make their naming system more stable.


The authors of draft-schanzen-gns have shown some willingness in working 
with draft-ietf-dnsop-alt-tld for their "pet names" in order to address 
concerns around conflicts and ambiguities.


Eliot

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

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

[Paul Hoffman]

On Aug 17, 2022, at 6:19 AM, Timothy Mcsweeney  wrote:

> Are you proposing dot Alt, or are you proposing dot Alt dot.?  

Please see , the 
draft in question. It has already gone through WG Last Call, but has been held 
there for possible revision.

> It would seem to me that a new naming system like the GNS that wants to be 
> outside the DNS would want its own root too, like just Alt for example.  

The discussion with the Independent Submissions Editor appears to be about 
whether they are interested in using a TLD that would different TLD or 
pseudo-TLD in order to make their naming system more stable.

> You could always reel it back in later right?  

No.

> You know, interoperability and all.

This is a place where interoperability fights with deployment realities.

--Paul Hoffman




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Timothy Mcsweeney]

Hi Warren,

Are you proposing dot Alt, or are you proposing dot Alt dot.? It would seem to 
me that a new naming system like the GNS that wants to be outside the DNS would 
want its own root too, like just Alt for example. You could always reel it back 
in later right? You know, interoperability and all.

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

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

[Timothy Mcsweeney]

Hi Warren, 
 
Are you proposing dot Alt, or are you proposing dot Alt dot.?  It would seem to 
me that a new naming system like the GNS that wants to be outside the DNS would 
want its own root too, like just Alt for example.  You could always reel it 
back in later right?  You know, interoperability and all.
 
Tim___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop