Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

[Edward Lewis <[e-mail]>]

At 9:50 +0200 6/16/11, OndÞej Sur˜ wrote:
>Hi,
>
>since I didn't receive any comments I guess:
>
>a) it's not exciting
>b) it's so good that it doesn't need any improvement [which I doubt]
  c) was unaware of the document's existence despite thinking "it would be
     about time to tackle this"

;)

I began reading the draft and started listing a 
lot of comments.  It would take me a long time to 
complete, so I thought I'd raise two things here.

1. The document talks a lot about the context of 
an IXFR exchange.  Can this be removed and stick 
to just the actions of an IXFR client and server? 
I mean, it doesn't matter why the IXFR is being 
kicked off.  (BTW, the statement that IXFRs are 
mostly kicked off by NOTIFY isn't really true, we 
oversee a lot of zones that do not change thus do 
not cause NOTIFY's to fly.  This factoid applies 
to different places but in the end, doesn't 
really matter when you are describing the 
protocol.)

2. For the first time I have thought abotu 
IXFR-only and I don't get it at all.  The reason 
is I don't accept that "If this is not possible, 
in the case of bare IXFR, the server falls back 
to AXFR, i.e. it provides the full zone content." 
Yes, there's a AXFR-style IXFR (all in one UDP 
message) but I don't think that is what is meant.

When a server indicates that IXFR can't be used, 
the server can not switch to AXFR.  The switch 
that is observed in operations comes from the 
client deciding to switch.  If the reason for 
IXFR-only is that a client, having failed to IXFR 
from IP address #1 will try AXFR instead of 
trying IXFR from IP address #2, then my response 
is that this is an implementation issue, not a 
protocol issue.

RFC 1995 never specifies that a failed IXFR will 
cause an AXFR to happen.  Maybe that's an 
accident of history, because implementations do 
this that we think that is what is supposed to 
happen.  It's not in the specification that way, 
as far as I can find.

The closest passage is in section 2 of RFC 1995:

    Thus, a client should first make an IXFR query using UDP.  If the
    query type is not recognized by the server, an AXFR (preceded by a
    UDP SOA query) should be tried, ensuring backward compatibility.

Note that this is if the IXFR QTYPE is not 
recognized, not a refusal to use IXFR.  And note 
that this is for backward compatibility.

Thinking in another vein, if a client chooses not 
to ever use AXFR, then what happens when IXFR 
requests can't be satisfied?  Let the zone 
EXPIRE?  Is a dead server better than a server 
that is taking time to sync up?  (This calls out 
the motivation for IXFR-only.)

---

As I mentioned, there is a need to refresh this 
RFC - well, maybe.  I want to suggest specifying 
that a IXFR client will verify the RRSIG of the 
first SOA returned.  This will close one more 
place a forger might be able to insert into or 
remove records from a DNSSEC signed zone without 
detection (assuming there's no VPN, TSIG, TKEY or 
similar protection).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at [phone]

I'm overly entertained.