Opened 12 years ago

Closed 12 years ago

#17 closed defect (fixed)

ENUM-Ops

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

Description (last modified by bernard_aboba@…)


From: Lawrence Conroy lconroy@…
Sent: Sunday, October 24, 2010 7:43 AM
To: Peterson, Jon
Cc: Richard Shockey; Ray Bellis; draft-iab-dns-applications@tools.ietf.org; ietf@…
Subject: Re: draft-iab-dns-applications - clarification re: Send-N

Hi Jon, Richard, Ray, folks,

I've been looking though the DNS-applications draft, and I'm unsure on its underlying aim.

We've already discussed the potential for "ENUM-Ops" style work to put clarifications
on how ENUM and ENUM-like systems should be used. The fact that there has been little
on the appropriate mailing lists on that topic doesn't mean that task has been overlooked
(there have been other distractions :).

There is certainly a good reason to issue DNS application guidance now,

and some of the features of DNS may not be what applications expect.

... BUT ...

Q: Are you arguing that some applications will make cacheing less effective and that this will be a problem?

Q: Are you arguing that over-use of DNS is generally a problem (e.g. due to lack of prioritisation of query processing)?

Q: Are you arguing that volume and size of data will unbalance intermediary cacheing servers and undermine their effectiveness/"hit rate"?

Q: Are you arguing that the size of RRSets will cause upstream servers to face difficult decisions in populating the answer and authority section of DNS responses?

Q: Are you arguing that the size of RRSets will force difficult decisions on upstream servers populating the additional section of DNS responses?

Q: Are you concerned that answers may vary depending on who's asking, and that this may damage the effectiveness of cacheing and/or the DNS infrastructure?

-- consider the Yahoo/Google? (edns-client-subnet) proposals for Internet-answering resolvers to support CDNs better (dwarfing use in private/internal telecommunications data networks)
-- consider the Google opt-in scheme for IPv6 networks, giving different answers depending on whether or not the network is "known to work with" IPv6 answers "correctly"+?

+: see <http://www.google.com/intl/en/ipv6/> for requirements


I believe that there ARE underlying issues with application use of DNS, and so guidance is definitely needed.
I'm however not convinced that the current draft chooses the best exemplars of these issues.

  • Frankly, the dynamism of the telecommunications data set is low (as you all know). The queries are susceptible to cacheing (or the systems WILL be designed to cope, where that is not a valid assumption).

(ASSUMING OF COURSE THAT "in-use" STATUS IS NOT TO BE REFLECTED IN DNS. No-one has ever suggested to me that fine grained presence data should be in DNS, yet that seems to be the only valid coherency concern).

  • Telecommunications data is under the control of those provisioning the data into DNS; For Telecommunication data provisioning, synchronisation seems to be an issue only of appropriate TTLs. Dynamic update DNS services already face this issue and deal with it.
    • "Applications should consider data dynamism and DNS synchronisation" is an eminently valid guideline, but ISPs' dynamic address assignment and third party Dynamic DNS services would seem a more appropriate example.
  • The size of ENUM answers is subject to the same restrictions as other users of DNS. Performance may will be helped by support for EDNS, but this is needed for all users of DNSSEC.

The approach used already (for example) for gmail.com's MX records has NOT been proposed for public ENUM use.
It's unclear if the concern over size raised in the DNS-applications draft will be misinterpreted as advice for people to apply such "techniques" to ENUM answers provided on the Internet.

  • The number of queries in a valid chain is limited; there simply aren't that many queries that need to be made for communications-related data. "Communications" may involve more than just application server addresses, but it IS limited. The new version of the ENUM standard has recommended "loop control" (see draft-ietf-enum-3761bis-09.txt, ends of sections 5.1 and 5.2), and has a recommended mechanism for "leakage control" (ibid, 3.4.3.1). Thus the concerns over long chains and leakage raised in the IAB-applications draft seem outdated, at least as far as ENUM is concerned.

Maybe it's just me, but I want a good guidelines document (so we don't HAVE to work so hard for an ENUM-specific set :),
but I'd like the guidance to spell out answers to the six questions above, or cover them more clearly.
At present I'm just guessing.

all the best,

Lawrence

Change History (2)

comment:1 Changed 12 years ago by bernard_aboba@…

  • Component changed from dns-applications to draft-iab-dns-applications
  • Description modified (diff)

comment:2 Changed 12 years ago by jon.peterson@…

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

Argues for a scope change for the document, refocusing on different questions. Was answered on the ietf main list, got no response to the answer. May tighten up some of the text regarding question 6, which is closest to the scope of the dns-applications document.

Note: See TracTickets for help on using tickets.