Opened 10 years ago

Closed 10 years ago

#180 closed defect (fixed)


Reported by: sm+ietf@… Owned by: jon.peterson@…
Priority: major Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:


In Section 2.1:

'For HTTP, the SRV service name corresponds to the URL scheme of the

identifier invoked by the application (e.g., when ""
is the identifier, the SRV query is for ""); for
other applications, the SRV service that the application passes to the
resolver may be implicit in the identifier.'

HTTP does not use SRV RRs. It is unlikely that such a proposal would gain any traction in the near future. I suggest not using the above example as it is misleading.

In Section 2.3:

"While open policies surrounding the use of the TXT record have

resulted in a checkered past for standardizing application usage of
TXT, TXT has been used as a technical solution for DKIM"

I suggest referencing RFC 6376 for DKIM.

In Section 3.2.1:

"By generating a large response to a small query, the attacker can

magnify the bandwidth directed at the victim."

I suggest using amplify instead of magnify. As a quick suggestion:

The attacker relies on amplification where a small query generates a large
response directed at the victim.

"Since it is prohibitively difficult to complete a TCP three-way

handshake begun from a forged source address, DNS reflection attacks
utilize UDP queries."

DNS refelction attacks utilize UDP queries because it is "cheap" and it works. assuming it was easier to do that with a TCP three-way handshake, UDP queries would still be used because:

(i) It's the default for a DNS query

(ii) It's "fire and forget".

I suggest just saying that:

It is prohibitively difficult to complete a TCP three-way handshake begun
from a forged source address for DNS reflection attacks.

"This limits the maximum magnification achievable from a DNS query

that does not utilize EDNS0."

It seems to me that magnification does not convey increase in actual size.

Commenting about domain redirection (Section 3.4), the IAB once mentioned that: "it is recognized that the problem lies within the application layer". The questions I would ask is why is the redirection done in DNS instead of at the application layer. I would say:

(i) There is a presumption that most applications would be HTTP(s).

(ii) It's easy to do due to blind trust on DNS (that's already mentioned

in the draft)

I would describe (ii) as an assumption that the application can rely on the provider's DNS server to provide an answer.

Implementing domain redirection in DNS creates a threat for application security. Section 3.4 concludes with:

"In environments where DNSSEC is not available, the problems with

securing DNS-layer redirections would be avoided by performing
redirections in the application-layer."

The problem is that the redirection is not being done by the end the application expects to communicate with. As such the text quoted above does not seem to fit in.


  1. Moonesamy

Change History (1)

comment:1 Changed 10 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

Replied to these comments on October 18, 2012. These fixes were implemented in -06, including making the SRV example LDAP rather than HTTP, reference 6376 for DKIM, many wordsmithing changes. Some of the reflection attack/EDNS0 comments here were overcome by events due to later reviews. The document is hopefully clearer now overall on EDNS0 and DNSSEC.

Note: See TracTickets for help on using tickets.