Put record somewhere other than apex

[johnhtodd]

Put record somewhere other than apex

[stu-h]

I came here to make a similar comment.

Placing security records under _security.example.com just seems cleaner and was my first thought when I heard about this proposal.

I don't like how TXT records are "polluting" the apex to be honest. Look at the TXT records for bbc.co.uk for example, the security contact information might be lost in the noise.

Most TXT records (apart from SPF) are usually just ephemeral verification codes that can be deleted after they have been used, they also leak some interesting information about what you services you use. Given this I'd prefer to keep the apex records "clean"

Back before EDNS there may have been some DNS fragmentation issues or perhaps an argument for not making DNS amplification attacks easier. I'm not sure those arguments hold much weight now.

[yosignals]

Thank you @johnhtodd, @stu-h, I'm getting a theme here that I don't think is something to ignore, I'm going to have a look at the Alexa top one million records this weekend and have a ponder on these question

• Do we accept DNS admin's untidiness and work around it
• Is it a polarised opinion or is it a dump out there
• Am I a little biased to plan A

...and to weigh up thinking on the two trains of thought, one being a TXT record right from the apex that can be seen by all, or to cut a specific _security. to be seen by those looking for it

one of the main considerations @caseyjohnellis is looking for is machine readability, I think generally it could parse from an apex TXT, I want to say there may be fewer parsing issues by design if there is a dedicated _security. - not that there are any parsing issues, but you know.

Thanks for your time chaps!

[yosignals]

Over the weekend I've run some things against the Alexa top 1 million domains and managed to process results from around 798884 of them, here's what the results are saying

Approximatly:

• 14 % had zero TXT records
• 66% had one TXT record on APEX,
• 14.6% had 2 Records,
• 7.5% had 3

A chart minus the zero TXT entries here - it's a chunky one, give it a moment:
https://docs.google.com/spreadsheets/d/1OdtshNCMQ1mV4BQnzgcwZ4zd8cGkR-SdWLrT8Hns4U0/edit#gid=1487775872

on the other end, a betting site was seen with 187 Entries!, PaloAlto in the top 10 offenders with 57 entries... and PWC not far off

I'm running the same process against a top 10 million domains list (not from Alexa but from here https://www.domcop.com/files/top/top10milliondomains.csv.zip , I wont be making any pie charts with that chunk of data

But, to the point of noise, it's looking like there is less noise en mass than anticipated, so it's not that big of a deal for me

I think that _security.domain.com is cleaner and I think that having a note on the apex is more a broadcast message than one that requires a direct query for it.

so yeah, Both is good.

I'll come back with results from the 10million if it's doable

This has spun off some other interesting things that will be worth writing up, in regards to the content in the seen TXT records, but that's a bit of a scope creep for here

If anyone is interested in doing their own research:

time parallel -j 40 host -t txt < domains10million.txt > top10milliondomainstxtrecords.txt

How I calculated was to cut out the domains from the first line in the results, then count the number of each domain entry that existed, this would show that if bbc.co.uk had been seen 15 times, that it had 15 TXT entries

`cat txtout.txt | cut -f 1 -d " " | grep 'bbc.co.uk' | wc -l '
15

such as:
`root@ubuntu-s-1vcpu-2gb-lon1-01:~/txt/1Million# cat txtout.txt | grep 'bbc.co.uk'

• bbc.co.uk descriptive text "_globalsign-domain-verification=WgTu2FOy64Yx8z8cOweOeyZ_YpUaQOmSTD9uyMwKbd"
• bbc.co.uk descriptive text "J0kgGm0XqA3/6pLD4DHeC5x/dAduzT809P1Iwx/PRCYvVS32rv75RIHKC2aVz47dJxKhPlxGf3h3KXiL6+dyXw=="
• bbc.co.uk descriptive text "google-site-verification=ITX3CwHXxGVfkCmhF4eSwdfo8h2ZGLAZ3zRpYvZi5XA"
• bbc.co.uk descriptive text "miro-verification=1a94b0fef7a6d5136a272d5cb425e8dc034e8cfc"
• bbc.co.uk descriptive text "dropbox-domain-verification=l5djk65wpy3z"
• bbc.co.uk descriptive text "google-site-verification=RaiMXJBIiFvqXHd43kv_ekzmXT2l8ibq5Xy0mulndvU"
• bbc.co.uk descriptive text "Huddle"
• bbc.co.uk descriptive text "adobe-idp-site-verification=9b850a4a56e3fac19aea1e0ac5db302e5cefab444cd73519dce1c72ccd4db058"
• bbc.co.uk descriptive text "apple-domain-verification=jFFO0rdS9IrxgWUR"
• bbc.co.uk descriptive text "docusign=a10ad7b6-cf7e-472d-8157-23061f5b5116"
• bbc.co.uk descriptive text "2RLXso9TrRPyhWOEhYggL0U/r1D+g8H7z9RqDBOmcJjSbj88TobGKimtkCrXZNBkDXQDj89lS4mDskNOJyWLdg=="
• bbc.co.uk descriptive text "MS=ms10378910"
• bbc.co.uk descriptive text "v=spf1 ip4:212.58.224.0/19 ip4:132.185.0.0/16 ip4:78.136.53.80/28 ip4:78.136.14.192/27 ip4:78.136.19.8/29 ip4:89.234.10.72/29 ip4:89.234.53.236 ip4:212.111.33.181 ip4:78.137.117.8 ip4:46.37.176.74 ip4:185.184.237.181" " ip4:185.119.233.144/30 ip4:185.119.232.158 +include:sf.sis.bbc.co.uk +include:spf.messagelabs.com ?all"
• bbc.co.uk descriptive text "atlassian-domain-verification=SQsgJ5h/FqwMTXuSG/G4Nd1Gx6uX2keREOsZSa22D5XT46EsEuyaic8Aej4cR4Tr"
• bbc.co.uk descriptive text "docusign=50f10407-e3e4-4f6a-aae4-712d4eb31329"`

Versus:
`~/txt/1Million# host -t txt bbc.co.uk

• bbc.co.uk descriptive text "_globalsign-domain-verification=WgTu2FOy64Yx8z8cOweOeyZ_YpUaQOmSTD9uyMwKbd"
• bbc.co.uk descriptive text "docusign=a10ad7b6-cf7e-472d-8157-23061f5b5116"
• bbc.co.uk descriptive text "2RLXso9TrRPyhWOEhYggL0U/r1D+g8H7z9RqDBOmcJjSbj88TobGKimtkCrXZNBkDXQDj89lS4mDskNOJyWLdg=="
• bbc.co.uk descriptive text "Huddle"
• bbc.co.uk descriptive text "atlassian-domain-verification=SQsgJ5h/FqwMTXuSG/G4Nd1Gx6uX2keREOsZSa22D5XT46EsEuyaic8Aej4cR4Tr"
• bbc.co.uk descriptive text "dropbox-domain-verification=l5djk65wpy3z"
• bbc.co.uk descriptive text "google-site-verification=ITX3CwHXxGVfkCmhF4eSwdfo8h2ZGLAZ3zRpYvZi5XA"
• bbc.co.uk descriptive text "MS=ms10378910"
• bbc.co.uk descriptive text "miro-verification=1a94b0fef7a6d5136a272d5cb425e8dc034e8cfc"
• bbc.co.uk descriptive text "google-site-verification=RaiMXJBIiFvqXHd43kv_ekzmXT2l8ibq5Xy0mulndvU"
• bbc.co.uk descriptive text "v=spf1 ip4:212.58.224.0/19 ip4:132.185.0.0/16 ip4:78.136.53.80/28 ip4:78.136.14.192/27 ip4:78.136.19.8/29 ip4:89.234.10.72/29 ip4:89.234.53.236 ip4:212.111.33.181 ip4:78.137.117.8 ip4:46.37.176.74 ip4:185.184.237.181" " ip4:185.119.233.144/30 ip4:185.119.232.158 +include:sf.sis.bbc.co.uk +include:spf.messagelabs.com ?all"
• bbc.co.uk descriptive text "docusign=50f10407-e3e4-4f6a-aae4-712d4eb31329"
• bbc.co.uk descriptive text "J0kgGm0XqA3/6pLD4DHeC5x/dAduzT809P1Iwx/PRCYvVS32rv75RIHKC2aVz47dJxKhPlxGf3h3KXiL6+dyXw=="
• bbc.co.uk descriptive text "apple-domain-verification=jFFO0rdS9IrxgWUR"
• bbc.co.uk descriptive text "adobe-idp-site-verification=9b850a4a56e3fac19aea1e0ac5db302e5cefab444cd73519dce1c72ccd4db058"`

15 for 15

[yosignals]

Hey @johnhtodd it sounds like your concern is highlighting a processing fault residual of poor design or old kit, can you give a current known example of where records might jam?

I like the _security. idea too, I'm just trying to qualify the legitimacy en masse of why adding extra txt records is a problem (and less specifically a design fault in our proposal)

Ultimately _security. or TXT will achieve the same outcome on our principle that is Domain based security contact point, but we have chosen the TXT path as a for Draft 0

[yesnet0]

@yosignals nailed it here - Ideally, this should be machine-readable and human-readable - A goal here is obviousness for folks who might not be aware of this standard, which gets challenged by burying the records under a subdomain.

That said, could a viable approach be to allow/recommend both (with the pro/con of each laid out) and let the user decide, based on what is most important to them? The security.txt file-based project had a similar consideration in deciding between file placement in the root of a web server (a la robots.txt... more obvious, but also messier) vs putting it under /.well-known/ (clearly, but less socialized as a "place to look for stuff like this) - It's a different set of considerations re impact/consequence here, but the root problem (pardon the pun) is the same.

Thoughts on that?

[yesnet0]

Apex approach

Pros:

• Obvious and familiar to users
• Easy to find
• Resilient and greater authority

Cons:

• Additional TXT records in domain apex
• Unsuitable for expanding available options

Description	Domain	Type	Content
Direct email reporting contact	_security.domain.com	TXT	"security_contact=mailto:[email protected]"
Direct web form reporting contact	_security.domain.com	TXT	"security_contact=https://domain.com/report-security-issue"
3rd party web form reporting contact	_security.domain.com	TXT	"security_contact=https://bugcrowd.com/domain/report"
Direct policy URL	_security.domain.com	TXT	"security_policy=https://domain.com/security-policy"
3rd party web form reporting URL	_security.domain.com	TXT	"security_policy=https://bugcrowd.com/domain"

_security.domain.com approach

Pros:

• Maintains apex zone hygiene
• Better support for additional future options

Cons:

• Not obvious in the apex
• Users probably require knowledge of dnssecuritytxt to identify the domain

Description	Domain	Type	Content
Direct email reporting contact	_security.domain.com	TXT	"security_contact=mailto:[email protected]"
Direct web form reporting contact	_security.domain.com	TXT	"security_contact=https://domain.com/report-security-issue"
3rd party web form reporting contact	_security.domain.com	TXT	"security_contact=https://bugcrowd.com/domain/report"
Direct policy URL	_security.domain.com	TXT	"security_policy=https://domain.com/security-policy"
3rd party web form reporting URL	_security.domain.com	TXT	"security_policy=https://bugcrowd.com/domain"

[yosignals]

I'm going to close this ticket, I think that the TXT space can be noisy and there isn't a great deal of clarity around what is and isn't ephemeral, but from an organisational perspective it's self-explanatory to those maintaining the records, altho the TXT records lack a list format and are generally 'top down' I can't see any meaningful risk in introducing our TXT record to the Apex, @yesnet0 has actioned the _security. as an alternative option.

I think the nuances here are an apex record is front of house and a _security. record is a requested department if that metaphor makes sense.

I will continue to analyse as many large domain datasets as I can get my hands on, the feedback here has certainly opened up more interesting questions around what may cause poor performance but that analysis will have to wait, to conclude, I think there are more reasons to do this than to not.

If we look at the bulkiest TXT record set from Alexa top 1 million, we know that whatever the highest number of records supported is, it's very accommodating. - thanks for the feedback prompting exploration chaps.