Re: [dnsext] Zones suitable for AXFR
Florian Weimer
> I can see the difficulty in handling this case, but doesn't this statemen=
t=20
> almost make it a requirement that AXFR must not handle such zones? RFC=20
> 1035 (section 6.3) suggests that the decision is down to the=20
> implementation:
>
>> If a master is sending a zone out via AXFR, and a new version is created
>> during the transfer, the master should continue to send the old version
>> if possible. In any case, it should never send part of one version and
>> part of another. If completion is not possible, the master should reset
>> the connection on which the zone transfer is taking place.
I think it's fine to send a mix of multiple versions, with two
caveats: For each name, one version is chose that applies to all
RRsets for that name, and the served data is not less consistent than
any of the zone versions involved (for example, regarding restrictions
on names imposed by NS/CNAME/DNAME records in the zone).
The rationale is that for a client, it's not observable if a
flip-flopping view of the zone is due to this transfer behavior or
other factors (anycast, AXFR delays etc.).
I understand that for audit purposes, having two distinct copies with
the same serial could be a significant headache. But I suppose
preventing this should be a SHOULD, not a MUST.
--=20
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Edward Lewis
up on some reading. I had missed this thread=20
until now.
At 11:17 -0500 11/11/08, Andrew Sullivan wrote:
>On Wed, Nov 05, 2008 at 06:04:03PM +0100, Florian Weimer wrote:
>
>> I think it's fine to send a mix of multiple versions
>
>I don't think that's fine, and I think it would be a very bad idea to
>weaken at all the language in RFC 1035 sec 6.3.
I agree with Andrew.
What prompted me to mention zones "not suitable=20
for transfer" was a situation in which the data=20
being used in a response was cobbled from a few=20
non-DNS sources on demand in response to the=20
query. (The data was then subsequently "cached"=20
for some number of minutes related to the nature=20
of the data.) This is an example of a lookup=20
system that uses the data formats sent on the=20
wire into and out of port 53 (and the protocol=20
semantics) but does not conform to our=20
conventional wisdom of what constitutes an=20
authoritative name server.
It isn't the situation that there are multiple=20
versions of a zone live at anytime. Just as each=20
dynamic update unit (for what ever a unit means)=20
increments the serial number, each modification=20
of the cache of authoritative data changes the=20
serial number of the "zone." In such a=20
situation, an AXFR reply is pretty much=20
meaningless - I mean - you could create one but=20
due to the dynamic nature of the zone, it has no=20
value.
(Imagine NSEC or NSEC3'ing this zone!)
So, what was written in -09 wasn't meant to issue=20
a challenge to what was in RFC1035/6.3 but a=20
reflection of a use of the DNS not anticipated at=20
the time of that document.
>The problem I have with this is that there is currently one actor that
>can introduce inconsistency, and that's the zone administrator (maybe
There really can't be any inconsistency because=20
there's no notion of consistency. It's just that=20
you can't put your arms around the collection.=20
It's like trying to identify every person in a=20
country at any one point - births, deaths,=20
immigration, emigration, etc. Or like that thing=20
in physics class where the instant you try to=20
measure a system you change it.
(Trying to seem educated, I'll thrown in this reference:
http://en.wikipedia.org/wiki/Schr=F6dinger's_cat
I think it relates to what I'm trying to say.=20
Exercise to the bored and otherwise unoccupied=20
reader. If anyone tells me I'm wrong, I'll not be=20
insulted and actually heartened to know someone=20
read this far.)
>due to automated tools that update the zone data without updating the
>SOA serial number). The proposal to allow continued flow of AXFR when
>the underlying data changes introduces a completely new actor into the
>mix: the transferring server itself. In such a case, it is
>indeterminite even from the point of view of the administrator when an
>inconsistent version of the zone could show up.
By "not suitable for transfer" I mean there is no=20
flow of AXFR, none at all, therefore no chance=20
for any inconsistency.
E.g., what's wrong with this?:
Time 0: Q: www.example.tld/IN/A =3D=3D> R: www.example.tld/IN/A/127.0.0.1
Time 1: Q: example.tld/IN/AXFR =3D=3D> R: example.tld/IN/SOA, NS set, and=
SOA again
Time 2: Q: www.example.tld/IN/A =3D=3D> R: www.example.tld/IN/A/127.0.0.1
It could be the result of this:
1) Query/Response for the address
2) Dynamic delete of the address
3) Query/Response for the AXFR (showing an empty/minimal zone)
4) Dynamic addition of the address (back as it was before)
5) Query/Response for the address
>If we approach the DNS as a distributed database, then introducing new
>vectors for consistency failure seems to me like a bad idea --
>especially ones where nobody can say with certainty when the
>consistency failure could happen.
"...introducing new vectors for ... failure" is "a bad idea". ;)
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.