Re: [dnsext] Use case for IXFR-only, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

[Mark Andrews <[e-mail]>]

In message <a06240800ca24eb6c9887@[192.168.1.104]>, Edward Lewis writes:
> At 14:11 +0200 6/20/11, Shane Kerr wrote:
> 
> >The reason this came up is that two operators (Ondrej and me) both
> >encountered the problem in the real world and it adversely affected our
> >operations.
> 
> I get what you are saying.  But was this caused by the way the tools 
> available worked or was there something wrong with the protocol that 
> forced the tools to react this way?  That's my central question.

It's a mixture of a known limitation of a optional extension of the
protocol, configuration and how the tools work (i.e. always doing the
extension).
 
> >IXFR-only specifies that you do not want the behavior to fall back to an
> >AXFR-style transfer, to avoid this issue. That's all.
> 
> What I'm contending is that the fall back is done by an impementation 
> and not part of the protocol.

Fallback is part of the protocol.  There are 4 possible responses to a IXFR
request.
1. "up to date" or "switch to TCP".
2. a delta response over UDP/TCP with optional compression.
3. a "up to date" response over TCP (response serial  <= query serial).
4. a "AXFR style" response over TCP.
 
> >In my mind, it turns IXFR into "Do What I Said" instead of "Do What You
> >Think Might Be Helpful". :)
> 
> What I began to think about, because of this thread, is that there's 
> no reason why server B - acting as a NOTIFY server - has to request 
> an IXFR from server A - acting as a NOTIFY client - but collectively 
> we have thought of it this way.  Not that NOTIFY is the only lead 
> into an IXFR or AXFR, it's just one of the ways to illustrate this.

The problem still exists even if the client only talks to the server
that has sent the notify.

> If server A tells server B "I have a new zone", the protocol does not 
> tell B it has to go to A for an update.  It's conceivable that server 
> B will try to get the update from C.  B can send AXFR/IXFR requests 
> to C without a NOTIFY (timer expiration would be one reason now).
> 
> It sounds to me that IXFR-only is more like 
> try-all-possible-sources-for-IXFR-first.  And that can be done in 
> code.

Every thing is done in code.  If you meant by the client, then no
it can't be done by the client cleanly as the client doesn't have
access to the data to do so.  The server needs to make the decision
on the clients behalf.

> NOTIFY/IXFR/AXFR are all distinct and independent mechanisms within 
> the DNS architecture.  They aren't necessarily linked but 
> implementers have linked them.  It's natural to do so - I'm not 
> saying implementers are the cause of all evil here (although they 
> generally are) - but again this is is maybe just a mass adoption of a 
> bad assumption.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at [phone]
> 
> I'm overly entertained.
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]