Why using multiple TXT records for the public key

[HexoNerd]

Why using multiple TXT records for the public key

[pawel-kow]

@arnoldblinn, can you take a look? This is the part you drafted this way.

[arnoldblinn]

I have seen some UX for TXT records limit you to 255, and may have lept to the assumption that this was a limitation in the protocol. Given this, there is no reason to put it into one record. But should it need to be split, it can be. I'll add that we should test this with more providers and see the behavior.

I'll see about getting the key for exampleservice.domainconnect.org put into one record so we can try it out....

[alinconstantin]

Arnold, you are correct. There is no limitation of the DNS protocol, and for those that can set the value in one record there should be no requirement to set p=1, part. However, there are UI limitations in setting the value - when I set the value for office.com I tried setting in one value, and the scripts used to set values in MSFT DNS didn't like it, so I had to set it in two TXT records p=1 and p=2. Please keep that part in spec if you relax the requirement for those who can store in one record. Thanks, Alin

…

________________________________ From: arnoldblinn <[email protected]> Sent: Saturday, November 17, 2018 3:14 AM To: Domain-Connect/spec Cc: Subscribed Subject: Re: [Domain-Connect/spec] Why using multiple TXT records for the public key (#23) I have seen some UX for TXT records limit you to 255, and may have lept to assumption that this was a limitation in the protocol. As such, there is no reason to put it into one record. But should it need to be split, it can be. I'll add that we should test this with more providers and see the behavior. I'll see about getting the key for exampleservice.domainconnect.org put into one record so we can try it out.... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDomain-Connect%2Fspec%2Fissues%2F23%23issuecomment-439608968&data=02%7C01%7C%7C526b6aea991e43cf1c8008d64c7de5f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636780500939018047&sdata=%2BNTzl9VwmqSb1OPa5pQW15bZ9JVqVUpkjcKheO1CLoE%3D&reserved=0>, or mute the thread<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FASp3uwMeLoIFhwqt8bRIqtT4FNL7bsCsks5uv--sgaJpZM4YgmUO&data=02%7C01%7C%7C526b6aea991e43cf1c8008d64c7de5f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636780500939018047&sdata=eBA%2FyoX7ULGUL6G7VwAzSULQvV5xM40obU4tc0nieow%3D&reserved=0>.

[arnoldblinn]

Whle I would like to claim I anticipated this, I'm more lucky than smart here.

There are two sides of the public key fetch. One is the producer of the data. The other the consumer.

You've verified for me there are some producers that can't deal with longer strings. I've gone in and verified that at least for my consumer (the example service) that I can in fact deal with longer strings.

I've modified the specification to read appropriately with my latest pull request.