On Fri, 17 Feb 2023, John Levine wrote:
That makes no sense. Why is it harder to copy a string to the name field
in a cruddy web GUI than to the data field? It's copy and paste either way.
For one, if the zone data presented to you is like a sorted zone file.
Second, because LHS entries usually are one liners, but things that take
TXT a form area?
Also it makes manual
checking harder (eg to use the dig command).
Same question, it's still copy and paste.
I think in general people prefer not copy pasting large blobs into their
shell and rather use dig _service._vendor.example.com
But most importantly, you
already need a good prefix to identify the vendor and service
No you don't. If you need a prefix to keep your 26 character randomly
generated tag from colliding with my 26 character randomly generated
tag,
No people need to be able to see the QNAMEs and recognise what these
records were for. Staring at english words within random blobs isn't
very user friendly.
at least one of us needs a new random number generator. If you want
to identify the vendor and service, that should be evident from the target
of the CNAME.
As explained, you are adding levels of complexity by insisting on
CNAMEs, adding RFC violating features, and making things more fragile.
CNAMEs are best avoided.
It doesn't seem wrong to me. I would hope a BCP would be based on something
more than "this seems ugly to me."
I hope a BCP draft review is also more than "I like CNAMEs"
If you use a fixed prefix, _crudco in this case, you should register it
in the RFC8552 attrleaf registry.
Since we are recommending these are easilly recognised to vendor and
service, these would be different for each vendoer. Sure, we can add
another prefix in between and put that in the attrleaf registry, but
that doesn't add any real value.
No, that's not what I said. Each vendor should register its prefix
with attrleaf, not an extra noise word. It's not like it's hard to
register or there is a shortage of ASCII strings.
I don't see what is gained by vendors adding their own vendor names in
the attrlead registry. Vendor names already depend on a system that
prevents collisions. It's called a Trade Mark.
As not registering anything in the attrleaf registry won't affect
anything at all for people creating and using DNS challanges, why
would anyone bother to take that extra step? You'd just be writing
up something that people will ignore anyway.
People make mistakes with CNAMEs, let's not recommend CNAMEs so chances
that people get affected my mistakes is reduced.
I have bad news. People make mistakes with TXT records too.
Whataboutism. Read the draft on why CNAMEs are not recommended. We
believe it is pretty clearly stated why these are not the right
choice.
In any event, this doesn't look like a BCP, it looks to me like
someone's personal preferences, not well supported by much else. I
would not publish it in anything like its current form.
The authors represent at least a browser vendor, a fortune500 that
generates and validates massive amounts of these records, and a
typical security architect dropped into a company with a bunch of
unknown DNS records to figure out who are sat down and said, "how
can we make this mess better".
We tried to keep it simple enough that people will still follow it, yet
useful enough for DNS admins who have never read this RFC to be able to
recognise whether the surprising DNS records in their zone are still in
use or not. Ideas and text to improve this is always welcome. We
specifically would like to know of challange/service providers if they
think the current proposals are something they would be willing to
migrate too (assuming they are right now using a random string TXT
in the APEX, or a fairly obscure word prefix like "_pardot").
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
