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

[John Levine <[e-mail]>]

It appears that Paul Wouters  <[e-mail]> said:
>> _a1b2c3.example.com IN ... "whatever"
>> _crudco.example.com IN ... "a1b2c3"
>
>Adding cryptogrpahically strong/long strings in the prefix seems
>unwieldly and prone to problems - especially if the user has to put
>these in via a webgui of mediocre quality. 

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.

>Also it makes manual
>checking harder (eg to use the dig command). 

Same question, it's still copy and paste.

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

>and mucking up random strings there just seems the wrong thing to recommend
>as BCP.

It doesn't seem wrong to me.  I would hope a BCP would be based on something
more than "this seems ugly to me."

>> 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 realize that RFC1034 says
>> not to chain CNAMEs, but we all know that people chain CNAMEs and it
>> works, e.g. www.microsoft.com goes through three CNAMEs and it works
>> fine.
>
>I was not allowed this line or argumentation with you when talking
>about the LHS of an email address :) 

There is so much wrong in that statement I don't know where to start.

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

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.

R's,
John