ietf
[Top] [All Lists]

axfr-clarify breaking RFC 1034, continued

2003-02-18 23:33:03
Mark(_dot_)Andrews(_at_)isc(_dot_)org writes:
; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2
  [ claims that ns2.child.example.net doesn't exist, as compared to: ]
; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2
ns2.child.example.net.        10      IN      A       10.53.0.2

Once again: That configuration violates RFC 1034. Specifically, sections
4.2.1 and 4.2.2 of RFC 1034 make crystal clear that the ns2 glue in the
parent zone is supposed to match the data in the child zone.

My software enforces the RFC 1034 requirement in this situation. If it
had been running on 10.53.0.2 then you wouldn't have been able to screw
up the configuration in the first place.

What you're complaining about is my software's perfectly straightforward
enforcement of the RFC 1034 requirement on the client side after you set
up an RFC-1034-violating configuration with your server. Is it really so
difficult to understand that it's your fault for violating RFC 1034?

  [ complaining about zone transfers in tinydns ]
You have to roll your own from what I can see.

No, you don't. Have you ever heard of ``third parties''? How about
``interchangeable parts''? Monolithic design is good for a company
trying to achieve lock-in, but modular design leads to faster evolution
and, in the end, better software for the users.

If you're trying to say that I haven't bothered to write up the existing
AXFR tools on my web pages, you're right. These tools have an extremely
limited audience; I have better things to do. The vast majority of users
are much happier with rsync+ssh than they would ever be with anything
based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago