Re: DNSEXT WGLC AXFR-02 SHORT last call

[[e-mail] (Andreas Gustafsson)]

D. J. Bernstein writes:
> AXFR client security issues
> 
>    Suppose I'm an AXFR client transferring the princeton.edu zone. I will
>    discard aol.com information from the princeton.edu servers. This is
>    required for security: the princeton.edu servers aren't authorized to
>    provide aol.com information.
>    
>    Gustafsson* claims that aol.com glue from the princeton.edu AXFR
>    servers may safely be used in referrals below princeton.edu. This
>    claim is false. Suppose, for example, I also happen to be a .com
>    server, and I receive the records
>      blah.princeton.edu NS dns-01.ns.aol.com
>      dns-01.ns.aol.com A 128.112.136.10
> 
>    from the princeton.edu AXFR servers. It is essential for me to discard
>    the glue A record; otherwise I will poison caches, because caches
>    trust dns-01.ns.aol.com information from .com servers.

No.  What is essential is that the server does not send the
dns-01.ns.aol.com glue as part of referrals out of any zone other 
than princeton.edu.

> Parent-child discrepancies
> 
>    Suppose I'm an AXFR client transferring both princeton.edu and
>    cs.princeton.edu. I will discard all princeton.edu AXFR results below
>    cs.princeton.edu, in favor of the cs.princeton.edu results.
>    
>    To the extent that there's a difference, the princeton.edu servers are
>    wrong. For example, the princeton.edu servers say
>      cs.princeton.edu NS cs.princeton.edu
>      cs.princeton.edu NS engram.cs.princeton.edu
> 
>    while the cs.princeton.edu servers say
>      cs.princeton.edu NS dns1.cs.princeton.edu
>      cs.princeton.edu NS dns2.cs.princeton.edu
> 
>    If someone asks me for the cs.princeton.edu NS records, I'm going to
>    report dns1 and dns2, not engram.
>    
>    Note that, when I transfer princeton.edu, I have not yet decided to
>    discard the cs.princeton.edu records from the princeton.edu servers; I
>    don't know at that point whether I'm also transferring
>    cs.princeton.edu. Records are discarded when the transfers are
>    combined.
>    
>    Gustafsson* and Ohta claim that records are zone-specific: in
>    particular, that the cs.princeton.edu NS engram.cs.princeton.edu
>    record is a valid part of the princeton.edu zone. This is not
>    consistent with the DNS specifications. Here's what RFC 1034 actually
>    says:
>      * DNS is divided into zones. Names are partitioned among zones. Each
>        zone is authoritative for all records under its names. See RFC
>        1034, section 4.1.
>      * Zones may, and sometimes must, contain records for which they
>        aren't authoritative, i.e., records from other zones. These
>        records are supposed to be exact copies of the authoritative
>        records. See RFC 1034, section 4.2.1, last paragraph on page 20.
>        
>    When an administrator fails to correctly copy records, such as the
>    cs.princeton.edu NS records, he is violating the protocol. He has no
>    right to expect clients to preserve both sets of records. Clients can
>    and do assume the accuracy of any record set received from any server
>    authorized to provide that set.

RFC1034 says the records in the parent "should" (not "must") be
exactly the same as those in the child.  This is an operational
recommendation, not a protocol requirement, and in practice,
discrepancies are extremely common and must be dealt with by the
protocol.

>    axfr-clarify-02 says that an AXFR client ``MUST associate the RRs
>    received in a zone transfer with the specific zone being transferred,
>    and maintain that association for purposes of acting as a master in
>    outgoing transfers.'' I object to this requirement, because (1) it is
>    not necessary for interoperability and (2) it prohibits the behavior
>    of my AXFR client, which discards records as described above when it
>    is scripted in the usual way. This requirement violates RFC 2119,
>    section 6.

The requirement is necessary for interoperability of downstream IXFR
servers.

>    The IETF-50 DNSEXT meeting minutes said that there was ``more
>    support'' for BIND 9's ``preservation of zone content'' than for the
>    BIND 8 AXFR behavior. The minutes didn't say exactly how much support
>    there was, or how many people attended, or how packed the room was
>    with people having financial interests in BIND.
>    
>    Gustafsson* says that the IXFR protocol breaks if AXFR clients discard
>    bad records. Well, that's too bad for the IXFR protocol. IXFR has an
>    official status of Elective, and my users have a better protocol
>    (rsync), so I am not going to support IXFR, and I object to the notion
>    of IXFR-induced complications in the AXFR protocol.
>    
> What is allowed in a zone?
> 
>    My DNS server reads all records from a single file; the system
>    administrator doesn't have to worry about zones. My AXFR server
>    defines the princeton.edu zone as the SOA record at princeton.edu and
>    all available non-SOA records within princeton.edu.
>    
>    In particular, if the file includes an address for
>    www.cs.princeton.edu, my AXFR server includes that address in the
>    princeton.edu zone.

If your server is the primary master for princeton.edu, it can of
course define the princeton.edu zone any way it likes, including the
way you described.  However, if it is a slave, it should respect the
intent of the master administrator and not insert records that were
not present on the primary master.

>    This works just fine with my AXFR client and with the BIND 8 AXFR
>    client. The client discards undesired records, as explained above; so
>    the server doesn't have to.
>    
>    Unfortunately, the BIND 9 AXFR client rejects the entire zone transfer
>    if it doesn't see www.cs.princeton.edu in an authoritative NS record
>    inside the princeton.edu zone. This is a current interoperability
>    problem.

I have no idea what you are talking about here.  The draft does not
specify that such a transfer should be rejected, and as far as I know,
BIND 9 will accept it with no problem.  If you have evidence to the
contrary, please submit it in a bug report to [e-mail].

>    axfr-clarify-01 prohibits records ``from the authoritative data of
>    zones other than the one being transferred.'' This is nonsense: every
>    record is part of the authoritative data of some zone. See RFC 1034,
>    section 4.2.
>    
>    axfr-clarify-02 prohibits records ``associated with zones other than
>    the one being transferred.'' A record ``is associated with a zone by
>    being loaded from the master file of that zone at the primary master
>    server, or by some other, equivalent method for configuring zone
>    data.''
>    
>    This is horribly unclear. Is Gustafsson trying to prohibit the whole
>    concept of a single DNS configuration file?

Of course not - that's why it says "or by some other, equivalent
method for configuring zone data".  Any configuration method that
unambiguously maps a zone name into a collection of RRs is acceptable.
All that section is saying is that once this collection of RRs has
been defined, transporting it by means of zone transfers must not
cause it to be altered.

>    I object to the use of
>    BIND-specific notions here; all requirements should be defined in
>    terms of on-the-wire behavior.

The use of master files to define zone data is not a BIND-specific
notion, it is an RFC1035 notion, and as I said, the draft specifically
allows alternative configuration mechanisms.

> Records outside the answer section
> 
>    axfr-clarify-02 says ``Slaves MUST ignore any authority section
>    contents [and] any unexpected RRs in the additional section.''
>    
>    I object to this requirement, because (1) it is not necessary for
>    interoperability and (2) it prohibits the behavior of my AXFR client,
>    which takes records from all sections. This requirement violates RFC
>    2119, section 6.

Alan Barrett already responded to this, and I concur with his response.

> Unauthorized clients
> 
>    axfr-clarify-02 says ``If the master server is unable or unwilling to
>    provide a zone transfer, it MUST respond with a single DNS message
>    containing an appropriate RCODE other than NOERROR.''
>    
>    I object to this requirement, because (1) it is not necessary for
>    interoperability and (2) it prohibits the behavior of my AXFR server,
>    which simply closes the connection. This requirement violates RFC
>    2119, section 6.

The requirement to send a response is already implicit in the nature
of the DNS protocol as a query-response protocol.  The fact that the
quoted paragraph reiterates this requirement is incidental; its main
point is to specify the format of the response, which is not clear in
RFC1034.

In my opinion, a server which closes the connection is not violating
the AXFR protocol, it is refusing to speak it and therefore outside
the scope of the draft.

>    AXFR is a local matter between a master and its authorized slaves.
>
>    Clients without authorization have no business asking for AXFR.
>    
>    Andrews* claims that clients cannot pipeline AXFRs on a single
>    connection if servers are allowed to close connections. This claim is
>    false. It is easy to construct a pipelining client that will handle
>    errors properly. (In the real world, client implementors open separate
>    TCP connections for separate transfers.)
>    
> Clients checking RCODE
> 
>    axfr-clarify-02 says that an AXFR client ``MUST check the RCODE in
>    each message and abort the transfer if it is not NOERROR.''
>    
>    I object to this requirement, because (1) it is not necessary for
>    interoperability and (2) it prohibits the behavior of my AXFR client,
>    which uses a different method to check for errors. This requirement
>    violates RFC 2119, section 6.
>    
> Clients checking IDs
> 
>    axfr-clarify-02 says that an AXFR client ``SHOULD check the ID of the
>    first message received and abort the transfer if it does not match the
>    ID of the request.''
>    
>    I object to this recommendation, because (1) it is not necessary for
>    interoperability and (2) it discourages the behavior of my AXFR
>    client, which doesn't bother checking the IDs. This recommendation
>    violates RFC 2119, section 6.

IDs and RCODEs are checked in all other contexts of the DNS protocol,
and I don't think it was the intent of RFC1034/1035 to make AXFR an
exception.  The draft is attempting to capture this presumed intent to
the extent possible, making specific exceptions only where required
for interoperability with existing implementations.

>    ``Failing to check the ID opens a server to spoofing,'' Wellington*
>    claims. That's not true. TCP connections already have sequence
>    numbers, and anyone who wants serious security for AXFR can run AXFR
>    over IPSEC or ssh. IPSEC-protected AXFR shouldn't bother with TSIG, so
>    why should it bother checking IDs?
>    
>    Andrews* points out that AXFR requests can, in theory, be multiplexed
>    over a single TCP connection. I agree that a hypothetical multiplexing
>    AXFR client would have to check IDs. But this has no relevance to the
>    behavior of my AXFR client.

I agree that the issues of spoofing and multiplexing are irrelevant.
They were not the reasons for the current wording of the draft.

> Servers repeating questions
> 
>    axfr-clarify-02 says that ``The initial message of a zone transfer
>    response SHOULD have a question section identical to that in the
>    request.''
>    
>    I object to this recommendation, because (1) it is not necessary for
>    interoperability and (2) it discourages the behavior of my AXFR
>    server, which doesn't bother repeating the question.
>    
>    Wellington* claims that this recommendation is ``an arbitrary decision
>    based on existing practice.'' In fact, it is a pointless
>    recommendation that does not take full account of existing practice.

Responses to other forms of DNS queries contain a copy of the
question, and again I don't see any indication in RFC1034/1035 that
AXFR was intended to be an exception.

>    I also proposed that RD be prohibited in AXFR requests. RD makes no
>    sense for AXFR and is not used by existing AXFR clients. This proposal
>    was ignored.

I have no problem with adding such a requirement, but wouldn't that
violate RFC 2119, section 6?

> Servers repeating records
> 
>    axfr-clarify-02 says that, aside from the repeated SOA, each record
>    ``MUST be transmitted exactly once.''
>    
>    This is how my AXFR server works, and it is how BIND 9 works. It is,
>    however, completely out of whack with how most versions of BIND work.

I have already agreed to change this into a SHOULD.

>   I object to this document being fraudulently characterized as a
>   ``clarification,'' a codification of ``existing practice,'' and a
>   description of ``the fielded DNS server software''; it should be
>   labelled and reviewed as a revision of the protocol.

The draft *is* a revision of the protocol as it replaces "The first
and last messages must contain the data for the top authoritative node
of the zone" with "The first and last RR transmitted must be the SOA
record of the zone".  Whether any other aspects of the draft should
also be characterized as changes to the protocol will depend on your
particular interpretation of RFC103[45].  In any case, I fully expect
the draft to be reviewed as a revision of the protocol.

As for using the word "clarifications" in the title, that follows the
example of RFC2181, which also updated RFC1034.
-- 
Andreas Gustafsson, [e-mail]


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.