I don't quite understand what the controversial part with this is, but
why not just copy RFC7686 (onion special use domain name) for .ALT?
It's an established precedence and also doesn't look like a bad idea to
just register the TLD with NXDOMAIN on the "normal" root dns servers?
> Authoritat
exactly with these points ruled out
may be good for cases like this (or for I2P, GnuNet, ...) to use as a
template in the future...
Sincerely,
Klaus Frank
On 26.10.2022 19:28, libor.peltan wrote:
Dne 26. 10. 22 v 19:02 Klaus Frank napsal(a):
I don't quite understand what the controversi
s (IPv4 VXLAN), 70-bytes
(IPv6 VXLAN), 60-bytes (IPv4 WireGuard) and 80 bytes (IPv6 WireGuard).
Sincerely,
Klaus Frank
smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
s both the behave as well as the
spfbis WG are closed.
GitHub:
https://github.com/agowa338/IETF-RFC-drafts/blob/main/draft-frank-dns64-spf-extension-03.xml
Sincerely,
Klaus Frank
Name: draft-frank-dns64-spf-extension
Revision: 03
Title: An Extension to DNS64 for Sender
alone.
Sincerely,
Klaus Frank
On 2022-02-14 12:53, Vladimír Čunát wrote:
Hello.
To me, the proposed "MUST rewrite [the SPF record]" certainly feels
too strong. I also wonder if there are some other problematic cases,
as SPF certainly isn't the only common DNS record that can em
e updated to align with that
assumption I'm open to replace this I-D with another one that updates
the SPF RFC to include the lookup of the NAT64 prefix. But until now I
just have the feeling that some people are just against DNS64 itself and
therefore try to avoid the discussion.
On 2022-02
On 2022-02-15 03:03, Mark Andrews wrote:
On 15 Feb 2022, at 10:47, Mark Andrews wrote:
On 15 Feb 2022, at 06:50, Klaus Frank wrote:
Hi,
yes there was discussion on the mailing list already. It wasn't however that
clear on what side should implement it. Also DNS64 already does t
