Jun-ichiro itojun Hagino | 1 Aug 02:14 2004

Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface

> On the other hand, introducing an new ai_ttl field at the end of struct
> addrinfo can be done without any effect on binaries (since the field offsets of
> the other fields do not change, and freeaddrinfo() will free the correct size
> structure). Applications which want to use ai_ttl would then do
> 
> 	call getaddrinfo...
> #ifdef _GETADDRINFO_AI_TTL
> 	ttl = ai->ai_tll;
> #else
> 	ttl = 30;	/* Or some other constant */
> #endif
> 
> While this is more painful than if we'd included ai_ttl from the start,
> it seems to be less painful than standardizing getrrsetbyname() to
> ensure portability of that interface across platforms.

	getaddrinfo() is not a DNS-only function; it can lookup hostname-to
	address using /etc/hosts, NIS, LDAP, whatever you have.  what value
	would you put in to ai_ttl when the lookup is done by non-DNS method?

itojun

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

Paul Vixie | 1 Aug 02:37 2004

Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface

i don't think expansing getaddrinfo/getnameinfo to return ttl is the
right approach.  we need a "getrrsetbyname" for dns-aware applications
that returns ttl, security status, and so on.  it should be in an rfc,
like the advanced ipv6 api document.  it should be pushed toward posix.

isc had proposed this to some of our funding agencies but i believe it
was "too much too soon" at the time.  perhaps MODA will pick it up now.

re:

> To: Erik.Nordmark <at> sun.com
> Cc: miekg <at> atoom.net, pekkas <at> netcore.fi, namedroppers <at> ops.ietf.org,
> 	dnsop <at> lists.uoregon.edu
> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface
> X-Mailer: Cue version 0.8 (040717-1035/itojun)
> Date: Sun,  1 Aug 2004 09:14:19 +0900 (JST)
> From: itojun <at> itojun.org (Jun-ichiro itojun Hagino)
> Sender: owner-namedroppers <at> ops.ietf.org
> 
> > On the other hand, introducing an new ai_ttl field at the end of struct
> > addrinfo can be done without any effect on binaries (since the field offsets of
> > the other fields do not change, and freeaddrinfo() will free the correct size
> > structure). Applications which want to use ai_ttl would then do
> > 
> > 	call getaddrinfo...
> > #ifdef _GETADDRINFO_AI_TTL
> > 	ttl = ai->ai_tll;
> > #else
> > 	ttl = 30;	/* Or some other constant */
> > #endif
(Continue reading)

Pekka Savola | 1 Aug 05:15 2004
Picon

Re: Re: getaddrinfo/TTL and resolver application-interface

On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote:
> 	getaddrinfo() is not a DNS-only function; it can lookup hostname-to
> 	address using /etc/hosts, NIS, LDAP, whatever you have.  what value
> 	would you put in to ai_ttl when the lookup is done by non-DNS method?

-1, unless something else is provided?

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Olaf Kolkman | 1 Aug 08:35 2004
Picon
Picon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.

(Continue reading)

Erik Nordmark | 1 Aug 16:05 2004
Picon

Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface

> My point is - applications developers ought to rely on DNS at it's 
> service's face value, not by inferring anything in the ancillary 
> data.  If application developers try to read between the lines, we 
> muddle the architecture of the Internet and will end up with a "house 
> of cards."

If we started with a blank sheet of paper that might work; but we 
unfortunaly have to deal with the existing house of cards.

When I try to tell application/middleware developpers to stop
retaining information returned by getaddrinfo/gethostbyname forever
and instead requery every time the information is needed it isn't well
received. The perception is that application caching (more or less forever)
work in the majority of cases so why is doing something different
the app developpers problem.

Hence I think we could collectively be more effective in fixing this
if we could present an API mechanism by which the application/middleware
could find out an upper limit on how long time it should retain
the information in its own cache.
Whether it is quicker and better to do this by standardizing getrrsetbyname
or by extending getaddrinfo is something we can debate once we have an
agreement that this is a useful approach.

  Erik

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
(Continue reading)

itojun | 2 Aug 00:03 2004
Picon

Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface

>On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote:
>> 	getaddrinfo() is not a DNS-only function; it can lookup hostname-to
>> 	address using /etc/hosts, NIS, LDAP, whatever you have.  what value
>> 	would you put in to ai_ttl when the lookup is done by non-DNS method?
>
>-1, unless something else is provided?

	then what do you expect application to do with the data?  when does
	it expire?  any fabricated value (-1, 0, whatever) in ai_ttl is
	problematical to TTL-aware application, IMHO.  what i'm suggesting
	is to use DNS-only API like getrrrsetbyname() if you want TTL.

itojun

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

Pekka Savola | 2 Aug 00:48 2004
Picon

Re: Re: getaddrinfo/TTL and resolver application-interface

On Mon, 2 Aug 2004 itojun <at> iijlab.net wrote:
> >On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote:
> >> 	getaddrinfo() is not a DNS-only function; it can lookup hostname-to
> >> 	address using /etc/hosts, NIS, LDAP, whatever you have.  what value
> >> 	would you put in to ai_ttl when the lookup is done by non-DNS method?
> >
> >-1, unless something else is provided?
> 
> 	then what do you expect application to do with the data?  when does
> 	it expire?  any fabricated value (-1, 0, whatever) in ai_ttl is
> 	problematical to TTL-aware application, IMHO.  what i'm suggesting
> 	is to use DNS-only API like getrrrsetbyname() if you want TTL.

Let's assume that currently apps keep records forever, i.e., "-1" 
(infinite).

If apps would use TTL info to requery the addresses now and then, 
telling them that a particular record has infinite lifetime (because 
lifetime information wasn't provided) seems like pretty much equal to 
the situation now -- i.e., it doesn't make situations worse. (And 
infinite would actually probably be rather accurate esp. with 
/etc/hosts).

getrrsetbyname has the generic problem that the applications don't
want to care about the lookup mechanism used.  /etc/hosts or whatever
is just as fine as DNS.  Thus I think only apps which specifically
know that they definitely want their answers to come from DNS (and not
from hosts file or whateveR) can use getrrsetname.  But I don't think
the majority cares, or should need to care.

(Continue reading)

Eric A. Hall | 2 Aug 03:51 2004

Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface


On 7/31/2004 8:37 PM, Paul Vixie wrote:

> i don't think expansing getaddrinfo/getnameinfo to return ttl is the
> right approach.  we need a "getrrsetbyname" for dns-aware applications
> that returns ttl, security status, and so on.

"rrset" is the right target, too.

apps that try to do their own load-balancing and whatnot need to be given
the original unordered set, not a random member of the set

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

Hallam-Baker, Phillip | 2 Aug 21:32 2004
Picon

RE: dictionary attack on nameservers

At blackhat there was a presentation on the ongoing .il vs .ps cyberwar.
This began with an attack on various pro-Palestinian groups and was shortly
followed by a retaliation on pro-Israeli sites and the entire .il domain.

It is pretty clear that whoever is running the .il domain is not going to
implement any scheme that makes it easier to walk the domain.

With respect to the claim made by Olaf that it is possible to zone walk
today, the possibility of a dictionary attack is very different from an
enumeration.

No dictionary attack is ever going to recover all the addresses in the
domain. You may get some proportion of the domains, but you will not get all
of them and will probably not even get most of them.

Security schemes ultimately come down to complexity arguments. The
complexity of an exhaustive dictionary attack is 28^l where l is the length
of the domain name. The complexity of an enumeration is n, where n is the
number of domains registered. Thus the number of steps required to recover a
domain on average is (28^l)/n vs 1. That is quite a big difference in
complexity terms. 3E11 harder for an 8 character domain name, which is not
all that long.

Sure you can cut down the complexity of a dictionary attack somewhat by
using phonemes, but you still have a lot of work. 12 character domain names
are commonplace. Even with phonemes you still have an exponential.

I think that it is pretty clear that what is being asked for here is a
mechanism that ensures that the cost of walking a domain remains an
exponential function of the length of the domain name.
(Continue reading)

Jelte Jansen | 3 Aug 00:12 2004
Picon

NSECX proposals

Hi,

do the drafts describing possible NSEC replacements or the 
requirements/transitions documents say anything about how much (or maybe 
just if) these proposals add to the complexity of maintaining zones (for 
example does it make it harder to change anything, or is incremental 
signing still possible)? If DNSSEC acceptance is an argument for 
proposing other NSEC schemes, i think that maintainability is a huge factor.

Jelte

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


Gmane