Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-02.txt

From: Alex Bligh <[email-masked]>
Date: Mon, 02 Mar 2009 19:37:39 +0000

A few nits. None of them should require another revision before last
call, and I'd certainly not die in a ditch for any of them.

* Section 1, Introduction, para 3
  s/This documents/This document/

* Section 3, The Transparency principle, para 1
  It would not only be impractical but require clairvoyance for a proxy to
  implement all *future* DNS features. I think "all DNS features" is
  sufficient for the meaning.

* Section 3, The Transparency principle, para starting "Furthermore"
  perhaps reads easier if you insert commas as in
    "then, for it to function correctly, it would need"

* Section 3, The Transparency principle,
  >    Except when required to enforce an active security or network policy
  >    (such as maintaining a pre-authentication "walled garden"), end-users
  >    SHOULD be able to send their DNS queries to specified upstream
  >    resolvers.  In this case, the proxy SHOULD NOT modify the packets in
  >    any way except for modifying IP and TCP/UDP headers as required by
  >    NAT.
  a) technically the exclusion should be "IP forwarding or NAT" (you are
     not deprecating reducing the IP TTL). Perhaps better to refer to
     not modifying the query? Also the response to the query should not
     be modified.
  b) I fully agree with the sentiment here, but I think the point that
     if DNS packets to other name servers are passed through
     without alteration then it isn't (in respect of those packets)
     acting as a proxy in any sense at all. It's acting as an IP
     forwarding device and/or NAT.
  How about "In this case, the device SHOULD NOT proxy the query, SHOULD
  transmit the packets onward as it does any other packet and SHOULD NOT
  modify the DNS query or any response to it".

* 4.4.1.  TCP Transport, para 1
  Add a comma after "because of truncation". Also there is a surplus space
  before the final full stop.

* 4.4.3.  IP Fragmentation
  >    Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in
  >    use) that gateways SHOULD be capable of forwarding UDP packets up to
  >    a payload size of at least 4096 octets.
  Is there a IETF-semantic reason not to write this the simpler and more
  obvious way, i.e.
    Therefore, gateways SHOULD (whichever of options 2 or 3 above is taken)
    be capable of forwarding UDP packets up to a payload size of at
    least 4096 octets.
  Also, elsewhere the style you have used is "proxies SHOULD" not "gateways
  SHOULD"; there is a risk people might see the distinction as significant
  and wonder what it is. I realise this is where the proxy is acting
  as a gateway rather than a proxy, but you haven't made this distinction
  elsewhere. So s/gateways SHOULD/proxies SHOULD/ in the above.

* 6.1.  Forgery Resilience
  >    If a DNS proxy is running on a broadband gateway with NAT that is
  >    compliant with [RFC4787] then it SHOULD also follow the
  >    recommendations for how long DNS state is kept from Section 10 of
  >    [RFC5452]
  Unfortunate "kept from". Try:
    If a DNS proxy is running on a broadband gateway with NAT that is
    compliant with [RFC4787] then it SHOULD also follow the
    recommendations in Section 10 of [RFC5452] concerning how long
    DNS state is kept.

Alex

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>