Subject: Re: I-D ACTION:draft-hayatnagarkar-dnsext-validator-api-06.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 Jun 2008 15:00:37 +0200

On Tue, May 27, 2008 at 11:15:01AM -0700,
 [email-masked] <[email-masked]> wrote 
 a message of 56 lines which said:

> 	Title		: DNSSEC Validator API
> 	Author(s)	: A. Hayatnagarkar, S. Krishnaswamy

Long time I've not been reading I-Ds about the DNSSEC API. So, feel
free to file my concerns in the "Already discussed" folder, if
necessary. Pointers to FAQ are also welcome :-)

I am sure that most applications would not want to adapt to DNSSEC
(just look at the time it took to adapt them to the multi-protocol
- IPv4 and IPv6 - paradigm). In most cases, the resolver should do the
work and just send back a SERVFAIL to the application (RFC 4035, 5.5).

But, for the applications that want to do DNSSEC (for instance a SSH
client implementing RFC 4255), the lack of a standard API is clearly a
big problem. So, I welcome this work and appreciate the amount of work
it is.

Now, for my concerns.

I do not see much usefulness in val_gethostbyname, section 3.1. These
gethostby* routines are obsolete for a very long time (RFC 2292, ten
years ago) and, if an application still use them, its maintainers will
not want to switch to DNSSEC either. I suggest to drop these routines
completely.

In 3.2, val_getaddrinfo et al., it is not clear if the possible status
code list is exhaustive or not. For instance, VAL_BOGUS is not
mentioned in the list but seems to be a reasonable possible result.

For the val_status_t of section 7.1, I do not find an obvious code for
"validated by a non-DNSSEC mechanism", for instance because I used
LDAP with a TLS connection. Is it VAL_LOCAL_ANSWER despite the fact
that LDAP is not local?

I do not find much guidance for the future implementors of this
draft. For example, if I write a library implementing the val_*
functions, should I always set the CD bit in the requests to the
resolver? (It seems so but I'm not sure.)

--
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/>