Re: Comments surrounding draft-iab-dns-applications-01

On Apr 28, 2011, at 10:40 AM, Edward Lewis wrote:

> These comments were sent to the IAB already.  I was encouraged to send them 
> to the general IETF list.  This is mostly a re-posting of the comments, with 
> one added paragraph (there's marker there).
>
> The referenced document is:
> http://www.ietf.org/internet-drafts/draft-iab-anycast-arch-implications-01.txt
Ed et al., 
In collecting and attempting to accommodate reviews on the Anycast 
Architectural Implications ID to which the link just above references, it's 
clear to me (and quite possibly everyone that read your message) that you meant 
to reference draft-iab-dns-applications-01, to which the subject and feedback 
concerns, available here:

<http://tools.ietf.org/html/draft-iab-dns-applications-01>

That said, a new revision of the Anycast document will be available in very 
short order, and I welcome feedback on it as well :-)

Thanks, 

-danny


> It's hard to make comments on a document whose mission is not at all clear.  
> The problem I have is that the document has a faulty baseline and incorrectly 
> assesses extensions and variations.  Having spent 15 years with the DNS and 
> having to come to a deep architectural understanding of it in order to define 
> DNSSEC, my view of the DNS is vastly different than that documented by the 
> IAB.  With this it is hard to tell what the document is trying to guard 
> against.  Or push towards.
>
> Starting with what the DNS is and why it exists has to recognize that a lot 
> of work we think is native to it actually preceded it in the /etc/hosts.txt 
> file and in similarly built systems.  DNS is not principally there to 
> translate names to numbers as the draft opens with, although that is a 
> high-profile use case.  The DNS did not define a uniform naming scheme.  DNS 
> is there principally to build on the previous solution (a text file 
> distributed once a week from a central location).
>
> If I were asked to list the bullet points that describe the DNS core 
> competency, they would be
> - availability
> - resilience
> - speed in response
> - speed in propagating data
> - distributed management
> - neutral
> Where the DNS is weak is in the data plane and the management plane. The 
> basic lookup/search algorithm is stilted, inflexible, and hard for many to 
> understand.  The biggest dilemma that it faces is that in order to be strong 
> it uses an unreliable transport substrate as it's primary communication 
> mechanism, the same substrate that is the source of the protocol's chief 
> technical challenges.
>
> In a way, DNS is a balancing act, it is all about using UDP "right."
>
> To a lesser extent, the fact that the DNS is not a client-server protocol, as 
> it is usually treated in text, but a client-cache-server protocol complicates 
> understanding it's architecture.  This is the very reason DNSSEC exists, the 
> ingrained middle-man in the client-server exchange.  Attempts to empower the 
> middle-man are the chief obstacle to improving the overall health of the DNS 
> and it's cooperation with other protocol systems.
>
> Over time there really hasn't been progress in the way of making the DNS 
> support applications.  Despite what is in the IAB draft, there has been just 
> one application that is built into the DNS, done at the "dawn of time" and 
> not even in a significant way.  Mail is the only application with built in 
> support in DNS.  No other application has ever changed the DNS definition.  
> To understand this we should look a chronology of changes to the DNS concept 
> and specification.
>
> The original DNS specification is as defined in STD 13's documents. I won't 
> bore you with repeating what's there, except to point out that a few seminal 
> types are included in the original set.
>
> It is also important to quantify what's meant by DNS support for an 
> application.  The baseline for any type is, given a name, class, and type, 
> the returned value will have a set of data.  Any resource record type that 
> follows this baseline is considered to have "no special processing," the 
> label put on sensitive types.
>
> Types that have no special processing include the A, AAAA, and PTR records.  
> Some of these types do contain domain name that can be compressed and this is 
> confused as special processing - but that is not special to the protocol, 
> just special to the marshalling of the parameters.  Surprising to some folks, 
> SRV and NAPTR also have no special processing, in fact aren't even subject to 
> message compression.  This point is one I have to make because the draft uses 
> SRV and NAPTR as evidence of application scope creep into the DNS.
>
> Types that do have special processing include this list (not exclusively) 
> SOA, NS, MX, CNAME, DNAME, and the DNSSEC types.  These are the types that 
> are cause considerations for the DNS.  MX is the mail application dedicated 
> type.  It's impact is that it causes additional data (address records) to be 
> included in a response.  A very lightweight action, but special processing 
> nonetheless.
>
> One of the concerns that is conflated with NAPTR, TXT, DNSSEC and IPv6 
> records is the concern over protocol data unit size.  This issue is generic 
> to the DNS and stems from the UDP transport "dependency" and not on 
> application demands.  (Back to the balancing act involving UDP.)
>
> Back to the chronology, looking for application-intelligence creep.
>
> These are what I consider to be the turning points in DNS history:
>
> RFC 1995/1996 - event-driven and incremental updates of zone contents
> RFC 2136 - dynamic updating of a zone's contents
> RFC 2181 - reduction in gullibility of caches
> RFC 2308 - negative caching and the introduction of mnemonics
> RFC 2671 - extended DNS header/trailer
> RFC 2672 - DNAME (non-terminal query redirection)
> "Views" - BIND's feature supporting query-source tailored responses
> RFC 4033 - DNSSEC (cache poisoning defense)
>
> If one gains an understanding of those RFCs (and the BIND feature), they will 
> have a workable impression of the DNS.  Not complete and with some gaps, but 
> the architecture would be roughed in.
>
> Internationalized domain names have no impact on the architecture of the DNS, 
> the same as for the DDDS and SRV record.  IDNs and SRVs do rely on their own 
> naming conventions, but that isn't an issue for the DNS.  SRV's naming 
> convention obviates the use of wildcards, but that is not a concern for the 
> DNS protocol's architecture.
>
> The recent push to support tailored responses, that is, responses based on 
> QNAME, QTYPE, QCLASS plus information about or inside the query message, has 
> been happening for nearly a decade.  I don't recall the exact version of BIND 
> that introduced Views, but I do know I was using it in 2003 when I worked at 
> ARIN.  Views was in response to outside demands, unknown to me, and I was 
> aware of statefull firewalls that did something similar back into the late 
> 90's.  This effort is sustained by latent demand, not a provider's recent 
> desire.
>
> (Paragraph added for IETF list) In my opinion, merely adding a RR type to the 
> DNS does not represent an architectural change which is why I launched in to 
> this history.  Applications have added record types over time.  The addition 
> of a type is not a significant event, in fact, it is an event that has not 
> happened frequently enough.  To me, significant changes to the architecture 
> would include  updates to the algorithm in RFC 1034, section 4.3.2.  To date 
> though, that section has only been updated for DNAME and fixed for CNAME (in 
> RFC 2672 and 4592 respectively).  Architectural changes may not impact that 
> algorithm, but such changes signal architectural impacts more so than a newly 
> defined type.
>
> So far I've summed up the reasons why I disagree with the beginning of the 
> document.  After writing this I went back to the document again to see if I 
> better understood the point of the draft.
>
> In section 4 there are four guiding principles that center on enforcing the 
> idea that there is complete coherency across queries for QNAME, QTYPE, and 
> QCLASS.  In my opinion this is archaic. Although the IETF has ignored 
> in-coherency in DNS (the failure of 
> http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04 to 
> even become an WG item) in the "real world" this has been going on since the 
> late 90's.
>
> One reason why such in-coherency exists today, having stood the test of at 
> least a decade in operations (running code) is that in-coherency is not a 
> radical idea despite the perception.  In the original framing of the DNS data 
> was static, quickly a dynamic nature was added.  In a static world, coherency 
> is a measurable and achievable condition, with dynamic elements, it is not.  
> Seeing a zone change rapidly is isomorphic to a server responding differently 
> based on source IP address when examining the traffic crossing port 53.  From 
> this observation, combining the concept of tailored responses with the DNS is 
> fairly easy.
>
> Later in section 4 there are five other cautionary tales.  Most of these are 
> "not a problem" today.
>
> One of these describes a true concern - relying on knowledge of the DNS 
> management model to assist in authorization determination, that is, knowing 
> where zone cuts exist.  An application that relies on the management of data 
> in another application has abdicated it's authority and will suffer the 
> consequences at some point.  This is not unique to the DNS.
>
> Mapping real world objects or concepts to domain names can be as complicated 
> as anyone wants.  For example, naming routers with multiple interfaces, a 
> problem seen on NOG lists periodically.  The complexity in the mapping is 
> immaterial, so long as the application developers can do it consistently.  
> Perhaps the most complex mapping is hashing, as is done for DNSSEC's NSEC3.
>
> Sensitive data can be in the DNS if other protections are taken. E.g., most 
> companies consider their internal hardware topology to be sensitive but still 
> run DNS for the benefit of their employees.  They then keep this DNS 
> "private."  (Again, this practice is not documented by the IETF.)  Some ENUM 
> work has been done to make ENUM work in places where telephone number 
> information is considered sensitive.
>
> The remaining points are outmoded.  While it is true that synchronizing zone 
> contents with external sources of data take work, it can be made to work.  
> Maybe the misperception is that this is only about the DNS.  But sometimes 
> putting more work on the DNS alleviates other systems.  In this case, the DNS 
> can be operated as it should be, making use of the dynamic update features 
> the IETF approved and the zone data propagation approaches already defined 
> with the result of assisting in traffic management.  Not perfectly, but 
> helping.
>
> The recommendations in section 4 are arguable.  There are fairly solid 
> arguments why the recommendations (except perhaps one of them) are wrong.  I 
> am not saying the recommendations mentioned have merit, but they are not 
> worthy of being backed by the IAB.
>
> In section 3, well, in trying not to get into a blow-by-blow discussion, I'll 
> summarize my thoughts that the IAB appears to be saying "avoid these things 
> because they will be bad" even though some of them have been in play for more 
> than a decade.  It's like a parent telling their teenager not to smoke after 
> the teen has already developed the habit.
>
> I have to mention 3.3.1.  The red herring about the size of data in DNS has 
> been around for a long time.  There is no issue.  TCP is not a problem for 
> DNS, at least architecturally speaking.  Yes, some implementations don't have 
> this right, but the situation can be fixed.  Inside the DNS, size is just a 
> number.  All applications have size issues.  All that is needed is to keep in 
> mind what the strengths of the DNS are, and let applications try to live 
> within the constraints.
>
> If the IAB is going to make such a statement, they should remind applications 
> what the strengths and limitations of the DNS are and have recommendations on 
> who to solve generic problems.  As written the document sounds like a sad, 
> almost pathetic plea for folks to stop innovating with the DNS.  It's almost 
> as bad as the IAB statement on a unique root, which caused more problems than 
> it solved.  (I've never bothered to read the the "extend DNS" document after 
> the first few revisions of it.)
>
> Finally, as the document stands now, I'd rather not be listed as a 
> contributor.  It's not fair to me to be associated with the draft's 
> architectural view.  It is fair to say I've submitted comments, but don't 
> give the impression I endorse the document as it is.
>
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at +1-571-434-5468
>
> Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
> Son: "Waah!"
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf