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

Thomas, Matthew mthomas at verisign.com
Thu May 7 16:02:10 UTC 2020


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
    
    
    
    



More information about the NCAP-Discuss mailing list