On Wed Mar 12 11:10:16 2008, rwfranks@acm.org wrote:
Show quoted text>
> RFC4343 seems to be the the most recent word on this topic.
>
> 4.1 (DNS Output Case Preservation) seems to support your view about
> case-insensitive matching for name compression, although without stating
> any reasons for doing so.
>
> 4.2 (DNS Input Case Preservation) is even less helpful and leaves
> implementations free to do their own thing.
>
>
> The present Net::DNS implementation takes a thoroughly pragmatic view by
> performing case-sensitive name compression. This ensures that any
> obligation to preserve case can be met in full, and any case folding is
> entirely the responsibility of the nameservers.
>
> The only penalty is a small loss of compression efficiency. Name
> compression is not mandatory, therefore efficiency can not be the
> deciding factor.
>
> Adopting case-insensitive matching would introduce the possibility that
> case information can be lost within the resolver itself, which is
> entirely unnecessary.
>
> Sitting on the fence is probably the realistic option right now.
>
To add... preserving case fits into the general approach of being conservative in what you do
to the network while being liberal in what you accept from it.
Also, in the context of trying to increase entropy in answer-response in order to cope with
cache poisoning there is an example that is critically dependent on case preservation in the
question section:
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20
For Net::DNS this is not so relevant as dnames would be compressed against the first occurrence of a set of labels (which is in the question section most likely). But there is
nothing in the standard that prohibits forward pointing compression pointers.
In other words, I'm grateful for the heads up, but I support Dick's assessment.
No further action, closing ticket.
--Olaf
