[NCAP-Discuss] Additional comments on the comments to the Scarfone Draft

[Rubens Kuhl]

Matt,

Thanks for the examples; while the examples are only .corp I see no reason for them to not include other TLDs and imagine that the .corp dataset was easily available.

Rubens




> On 7 May 2020, at 13:02, Thomas, Matthew <mthomas at verisign.com> wrote:
> 
> Rubens,
> 
> If you look at the RFC for DNS-SD, you’ll see that the fully qualified name is constructed by the following formula:
> 
> Service Instance Name = <Instance> . <Service> . <Domain>.
> 
> Here is an example: _ipp._tcp.example.com
> 
> Just because the underscore is a non-registerable character at the second level domain, does not mean that domains are not prone to DNS-SD exploitation in the ICANN-governed ecosystem.
> 
> Here are three examples I just pulled from A/J root .corp traffic:
> 
> 1.)	_kerberos._tcp.corp-usw4._sites.dc._msdcs.info.corp
> 2.)	_ldap._tcp.de001._sites.dc._msdcs.vi.corp
> 3.)	dr._dns-sd._udp.itar.sanm.corp
> 
> The threat of DNS-SD exploitation in these cases are at info.corp, vi.corp, and sanm.corp. If the TLD was delegated, those second levels registered, there is nothing preventing their DNS servers to be configured to respond to “_” requests.  So, the statement of “they can’t be exploited through domain names” is not technically accurate. The positioning of the DNS-SD underscore labels relative to the domain determines the SLD.TLD attack surface.
> 
> Matt Thomas
> 
> On 5/6/20, 9:40 PM, "NCAP-Discuss on behalf of Rubens Kuhl" <ncap-discuss-bounces at icann.org on behalf of rubensk at nic.br> wrote:
> 
> 
>> 
>> It all stands on technical merit and I appreciate technical arguments - yours are not and comments like the above as well as your unwillingness to read any citations and lack of willingness and/or ability to grasp fundamentals remind me you’re just here to troll and I’m not going to feed it anymore.
>> 
> 
>    The argument I made is a technical one, about share of discovery protocols relying on _ and thus not prone to be exploited in the ICANN-governed ecosystem. By trying ad-hominem tactics of detracting technical knowledge just because someone disagrees with your positions, this makes the person I responding to the troll in all this.
> 
> 
>    Rubens
> 
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200507/9a26fac5/signature.asc>