On 05/16/2014 02:18 PM, Andrew Sullivan wrote:
>
> First, if resolvers have expectations about consistency of zones and
> so on, then they're broken. The DNS has only ever been loosely
> coherent. You're simply _not allowed_ to make that assumption from
> any point in the network except inside the authoritative server and,
> maybe for certain kinds of consistency, in the slaves of the same
> zone.
>
There are always assumptions; For every little bit that doesn't happen
to be specified (of which there were an awful lot back in 103X), you
assume an interpretation (or one of a select set). We try to minimize
them by exhaustive specification, but that doesn't always work.
Furthermore, sometimes there are views and models derived from the
actual rules, which can be seen as rules because they are not
contradicted in the current set of specifications. Changing something so
that those are no longer valid can be done, but the implications need to
be considered. This to me is also why there are Considerations chapters
in RFCs.
Some assumptions are considered broken ("DNS packets always < 512 bytes,
and firewalls should drop larger ones"), some are not ("any order of A
records in an rrset is equally valid so always just pick the first
one"). On yet others the verdict isn't always clear ("SERVFAIL means a
server isn't authoritative for the queried zone").
In this case, an assumption that changes is what 'loosely coherent'
actually means, and whether or not you can, in fact, cache answers, and
hand the same out to whomever sends them the same question. They may not
make any assumptions about the content they pass on, but they certainly
do make a few about its validity and timeframe (namely, that it doesn't
change until the TTL expires, and that it is the same for everyone).
To implement client-subnet means to implement a form of views within
your resolver in the form of split caches. If you don't implement it at
all there is no problem, but it certainly does change the model of the
world that resolvers have for those that do.
I don't think this is necessarily a problem, and as far as CDN's go, I
think the proposed draft is quite nice, and actually addresses this
problem. But things like that should certainly be considered. To name
something, what is the effect on forwarders? (what are forwarders in the
first place? what are their assumptions, do we consider those wrong? are
there any in deployment? is it a problem?)
Jelte
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
