Before you go down the mDNS-over-constrained-networks rabbit hole, you
might want to look at existing practice. E.g. Thread uses SRP
(draft-ietf-dnssd-srp, in last call) for service registration, and then
uses regular DNS and DNS Push for lookups. mDNS is used on the
infrastructure link (e.g.
.NA feels prodded as well :-0-O
el
On 18/08/2022 10:23, Rob Evans wrote:
>> How realistic is it to prod these to migrate?
>
> One of them is a customer of mine, I'll prod them. :-)
>
> Cheers,
> Rob[...]
--
Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
e...@lisse.na
Brian,
> On 08/17/2022 7:56 PM EDT Brian Dickson wrote:
>
> (Dots between and after names are moot and meaningless, only relevant in the
> “presentation” format.
The specification _is_ in the presentation format so those dots and their
location are relevant here. Thank you for
On Thu, Aug 18, 2022 at 09:12:33AM +1000, Mark Andrews wrote:
> 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
Hi George,
I could see the value in reserving dns.alt, and the potential mischief
that could ensue by not doing so.
Eliot
OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
Eliot Lear wrote on 2022-08-18 13:11:
...
I could see the value in reserving dns.alt, and the potential mischief
that could ensue by not doing so.
that way lies madness. let the FCFS process and technical review include
space for objecting to the requested 2LD label.
--
P Vixie
You appear to be taking the concept to a place where alt is the label
which defines the start of non-DNS switching, and the 2LD is the
specification of the namespace/service you work in. So its a domain
model, driving to software and namespace path, before it begins
resolution of the name proper.
It appears that Eliot Lear said:
> 1. Conflicts can be avoided between deployments of cooperating name
>systems; and
It seems to me that the key word here is "cooperating." Considering
how many projects squat on various bits of the DNS name space, we have
seen only one show any interest in
“we have seen only one” is not true. What is true is that we pretty much told
everyone who asked to go away, with the exception of .onion. E.g., .home was
told to go away, and we wound up using home.arpa instead, which is perfectly
fine for our use case.
Your observation about implementation
Ben Schwartz wrote on 2022-08-18 12:11:
On Tue, Aug 16, 2022 at 10:15 PM Schanzenbach, Martin wrote:
> ...
That is exactly why IMO the namespaces under .alt must have a
technical merit and this merit gives the protocol a shot at a (or a
few based on the technical design)
On Tue, Aug 16, 2022 at 10:15 PM Schanzenbach, Martin <
mschanzenb...@posteo.de> wrote:
> Hi,
>
> > On 16. Aug 2022, at 16:32, David Conrad wrote:
> >
> > Signed PGP part
> > On Aug 15, 2022, at 7:07 PM, Stephen Farrell
> wrote:On 16/08/2022 03:01, John Levine wrote:
> >>> Right. If it's FCFS,
Hi Ben,
On 18.08.22 21:11, Ben Schwartz wrote:
What you are describing does not resemble draft-ietf-dnsop-alt-tld,
which would define the "alt" SUDN. That document says:
There is no IANA
registry for names under the ALT TLD - it is an unmanaged namespace,
and developers are
Stephen Farrell wrote on 2022-08-18 12:43:
Hiya,
On 18/08/2022 20:26, Paul Vixie wrote:
i don't think the .ALT draft is going to move forward without such
change, so the distinction will be between .ALT as proposed and .ALT
as evolved, not between .ALT and some other SUDN.
I think I
On 18/08/2022 21:11, Eliot Lear wrote:
I could see the value in reserving dns.alt, and the potential mischief
that could ensue by not doing so.
Ugh. Were that done I'd be worried abut the effect
on the web PKI of creating sorta-synonyms like that.
S.
OpenPGP_0x5AB2FAF17B172BEA.asc
On Thu, 18 Aug 2022, Paul Wouters wrote:
On Aug 18, 2022, at 18:30, John Levine wrote:
It appears that Eliot Lear
It seems to me that the key word here is "cooperating." Considering
how many projects squat on various bits of the DNS name space, we have
seen only one show any interest in
I pose human factor and UX questions:
Do you think people expect to have to do things at url Point and Click time
to select which namespace is resolved?
If I specified my.domain.gns.alt do I expect the entity behind my.domain to
be the same in gns and in dns?
If I am writing gns resolution code
On Aug 18, 2022, at 18:30, John Levine wrote:
>
> It appears that Eliot Lear
> It seems to me that the key word here is "cooperating." Considering
> how many projects squat on various bits of the DNS name space, we have
> seen only one show any interest in the RFC route
This is incorrect. A
> On Aug 18, 2022, at 22:14, John R Levine wrote:
>
> I could have been clearer. The names can be duplicates, not the rest of the
> entry. So someone comes along and registers web.alt with a pointer to her
> thing, then someone else comes along with a different thing but also calls it
>
Hiya,
On 18/08/2022 20:26, Paul Vixie wrote:
i don't think the .ALT draft is going to move forward without such
change, so the distinction will be between .ALT as proposed and .ALT as
evolved, not between .ALT and some other SUDN.
I think I agree. But to check: are we saying that the .alt
Hi!
Martine Lenders, here, one of the co-authors of the draft.
Indeed, as Carsten already stated: Using OSCORE is one of our main use
cases, using a compressed format for DNS messages is another.
We implemented both DNS over DTLS and DNS over CoAP (DoC), including the
variants DNS over
> How realistic is it to prod these to migrate?
One of them is a customer of mine, I'll prod them. :-)
Cheers,
Rob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
21 matches
Mail list logo
