Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

[Edward Lewis <[e-mail]>]

At 22:54 +1000 6/20/11, Mark Andrews wrote:

>They differ by the QTYPE is the question section of the response otherwise
>they are identical.

>The following is legal with IXFR and results in a AXFR style IXFR response.

My assumption is that IXFR is a single query, single response message 
mechanism, so I would disagree with the example shown.  But I can see 
why there's a disagreement here, based on this passage from RFC 1995.

    Transport of a query may be by either UDP or TCP.  If an IXFR query
    is via UDP, the IXFR server may attempt to reply using UDP if the
    entire response can be contained in a single DNS packet.  If the UDP
    reply does not fit, the query is responded to with a single SOA
    record of the server's current version to inform the client that a
    TCP query should be initiated.

    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.  If
    the query response is a single packet with the entire new zone, or if
    the server does not have a newer version than the client, everything
    is done.  Otherwise, a TCP IXFR query should be tried.

When reading the first paragraph I get that IXFR is one message 
query, one message response ("single DNS packet").  However, the "may 
attempt to reply" is not correct, the RFC should read "and will reply 
with one of three kinds of responses."  One being the "no IXFR 
possible", the other being the ordinary IXFR, and then the AXFR-style 
IXFR.  BTW, the latter is not a term used in the RFC.

 From that I have always assumed that the IXFR response is one DNS 
message.  Even on TCP.

The second paragraph adds to the confusion over fallback.  It talks 
about trying AXFR, but only if the IXFR is not understood.  And the 
has one line tacked on to the end of the paragraph of TCP IXFR being 
tried.

What needs to be fixed is how IXFR behaves on TCP.  It should be 
limited in its resource consumption.  That's what I'd go after.

I suppose I never assumed an implementation try IXFR over TCP. 
That's why I've never seen this issue in code or operations.

I think that the change here is not to cut off AXFR-stype IXFRs but 
to limit what a IXFR server considers an acceptable IXFR response. 
On TCP though you don't have a forced limit (512, EDNS0).

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

I'm overly entertained.