DNS query reliability (was Re: The internet architecture)

[Dave CROCKER]

Andrew Sullivan wrote:

It seems to me true, from experience and from anecdote, that DNS out
at endpoints has all manner of failure modes that have little to do
with the protocol and a lot to do with decisions that implementers and
operators made, either on purpose or by accident. 

...

This suggests to me that there will be an opportunity to improve some
of the operations in the wild,

...

If you have a cache of these examples, I'd be delighted to see them.



One could imagine producing a BCP about common DNS implementation and operation 
errors or, more positively, recommendations for implementation and operation.


One could equally imagine some group actively pursuing improvements to the major 
implementations (and operations) that have problems.


I seem to recall seeing small forays in this direction, in the past.  Your query 
might encourage an organized effort that follows through with making actual DNS 
operation -- as opposed to attack or defense of the protocol -- provide the 
needed level of *end-to-end* reliability.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Friday experiment

[John C Klensin]

--On Saturday, 06 December, 2008 17:53 -0700 Cullen Jennings
<[EMAIL PROTECTED]> wrote:

> 
> On Nov 29, 2008, at 5:15 AM, Julian Reschke wrote:
> 
>> I think it would be good to finally enforce the rules for
>> agenda   submissions. For instance, if no agenda for a
>> meeting is published   in time, the meeting shouldn't take
>> place.
> 
> +1
> 
> But in practice, every time something is late, an exception is
> made for it.

While I would favor more enforcement of those rules, I'm not
personally convinced that this is enough of a problem by itself
and fixing it would make a lot of difference.

However, in practice, late agendas are either a problem or they
are not a problem.  If they are not a problem, we should stop
pretending that they are.  If they are a problem, then the AD
granting the exception, or the entire IESG, should be held
accountable by the community for encouraging the problems to
occur.  

We really can't have it both ways, and neither can the WGs or
the IESG.

 john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Friday experiment

[Cullen Jennings]

On Nov 29, 2008, at 5:15 AM, Julian Reschke wrote:



I think it would be good to finally enforce the rules for agenda  
submissions. For instance, if no agenda for a meeting is published  
in time, the meeting shouldn't take place.


+1

But in practice, every time something is late, an exception is made  
for it.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Christian Vogt]

Keith -

Up front:  Many of your arguments are based on the assumption that the
name-oriented stack architecture proposed in [1] is limited to a new API
between applications and the stack.  If that was so, then the benefits
of the new stack architecture would undoubtedly be limited.  But the
name-oriented stack architecture goes beyond providing a new API.  It
also comprises changes further down the stack to take maximum benefit of
the proposed new naming concepts.  A new API alone would only provide a
new layer of abstraction, which (here I agree with you) would fail to
yield a substantial improvement.  Therefore, please keep in mind when
reading my further responses below, that the proposed name-oriented
stack architecture is more than a new API.

And another general comment up front, regarding your arguments related
to DNS reliability:  Yes, I agree with you that this is important.  For
sure it must be keep in mind when transitioning towards an architecture
that implies a stronger dependency on name-to-address mapping.  The
reason why I am convinced that we will get this right is that (i) the
tools to ensure various levels of DNS reliability and security already
exist due to existing dependencies on the DNS, and (ii) which level of
DNS reliability and security to provide for, in each particular
deployment scenario, will continue to be under the control of the
respective name owners.  I.e., as today, the name owners will be able to
select a hosting provider with sufficient trustworthiness, or to set up
the necessary DNS infrastructure themselves, or even to use hard-coded
name-to-address mappings in hosts.

Of course, a name-oriented stack architecture does not /have/ to use the
DNS as its name-to-address mapping system.  As Stephane said earlier in
this email thread: There are alternatives.  Still, I have two reasons to
believe that the DNS would be appropriate in this regard:

(1) The DNS protocol enables exactly the flexibility in name-to-address
   mapping that we need:  It enables an abstraction from the physical
   implementation of a service -- i.e., from the details of which hosts
   run the service and where these hosts are located.

   Note that the term "hostname", which is common in the DNS realm, is
   misleading due to exactly this abstraction.  And I think it has led
   to misunderstandings also in our discussion.  This is why I am now
   using the term "name" instead.

(2) The DNS has very attractive operational and security properties:
   Since resolution is along administrative relationships,  the right
   incentives are in place for DNS to work correctly.  Of course, this
   doesn't mean that there is no room for improvement.  Certain
   existing administrative procedures may be inappropriate, as you say.
   And clearly there would be benefit to additional cryptographic
   protection such as through DNSSEC.  But the DNS provides a certain
   level of faithfulness already without such improvements, and this is
   in my opinion very attractive.


The service name is a well-known string replacing the overloading of
port numbers for the same purpose, and the hostname maps to the set  
of

IP addresses through which the service is currently reachable.


I'll never forget the time, back when I ran a mail server for a few
thousand users, that mail started dropping on the floor because a call
to getservbyname ("smtp", "tcp") inside sendmail started failing.

The call failed not just because some dim bulb at Sun decided that it
would be a good idea to take an API that originally did a flat file
lookup and reimplement it with an RPC to an NIS server that didn't  
share

fate with the caller (not to mention several other fragilities
associated with NIS).   On a deeper and more important level, the
failure happened because the whole idea of getservbyname (and similar
things, including the service name parameter to getaddrinfo) is
brain-damaged [*].  "smtp" is not better than 25, and adding an extra
layer of indirection just to make the port number be human readable is
not an improvement.


There won't be a new indirection layer.  Instead, there will be a
separate name space for services, which will be distinct from the name
space for session identification.  Nowadays, port numbers are overloaded
for both, service identification and session identification.

And the separation of service identification and session identification
is going to have value.  An example is in IPv4 NAT'ing:  Here, the
overloading of port numbers limits the efficiency with which sessions
can be multiplexed onto the same IP address because the overloading
requires one of the two port numbers of a session to take a certain,
well-known value.  This problem is coming up nowadays in the discussions
around IPv6 transition, for which many techniques require aggressive
multiplexing of sessions onto the same IPv4 address.  You may argue that
this alone is not sufficient to motivate a change, but this would be a
separate topic for d

Better non-meeting progress, was Re: [73attendees] Attendance by country

[Iljitsch van Beijnum]

On the 73attendees list we had a discussion about making face-to-face  
meetings unnecessary through better technology.


In my opinion, that will be extremely hard to the point of being  
impossible, for various reasons. (See the 73attendees discussion for a  
bunch of them.) However, a more useful way forward would be to make  
remote participation work a whole lot better.


At one point we had multicast video for a couple of tracks, which  
didn't work very well. Now we have audo for all sessions, which works  
much better (although when the audio quality is bad it takes a lot of  
energy to listen and the lag makes reacting problematic). Jabber came  
along before we had audio everywhere, giving rise to the notion that  
someone should type in whatever happens in the meeting. I think that  
use of jabber is problematic, but using jabber as a back channel for  
additional discussion without interrupting the speaker only works on  
occasion because too few people participate in jabber, or participate  
in that way. And we don't use jabber anywhere in our process. I think  
there's an opportunity there once we figure out how to use it well.


But that's just the state of affairs today. Bandwidth and hardware are  
now cheap enough that we could revist video in the form of unicast  
streaming, although that may take more person hours. Or maybe we can  
create some other way to allow remote participants to see the slides  
"live". I assume there are solutions for this, although they may not  
be compatible with the quaint operating systems some participants  
choose to use. Maybe we can hack something together ourselves? Export  
slides to images or HTML, use some web magic to have the current one  
on a web page, a volunteer triggers advancing the slides?


Something that I'd like to see is a way for remote participants to  
talk back. I know a system that can do this called Talk Shoe exists  
that allows people to make home brew call in radio shows. If it works  
well enough, we could even do away with microphones in the meetings  
and people can just speak into their laptops.


However, making progress here probably requires more than just  
volunteer work. Would it make sense to charge a fee for remote  
participation? At first, the extra money could be used to improve the  
tools for this. If it them becomes popular it could become a new  
revenue stream for the IETF.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The internet architecture

[Masataka Ohta]

Stephane Bortzmeyer wrote:

> If it were true, I would wonder why people never use legal URLs like
> ...

The problem to represent a host with raw addresses is that they
can't represent a host with multiple addresses, supporting of
which is useful and often required, for example, for DNS and SMTP
clients.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: sockets vs. fds

[Florian Weimer]

* Tony Finch:

> On Fri, 5 Dec 2008, Dave CROCKER wrote:
>> Melinda Shore wrote:
>> >
>> > Not to go too far afield, but I think there's consensus among us old
>> > Unix folk that the mistake that CSRG made wasn't in the use of
>> > addresses but in having "sockets" instead of using file descriptors.
>> > This was actually fixed in SysVRSomethingOrOther with the introduction
>> > of a network pseudo-filesystem (open("/net/192.168.1.1", ... ) with
>> > ioctls but never got traction.
>>
>> It isn't immediately obvious to me why file descriptors would have had a
>> major impact, so can you elaborate?
>
> This isn't a question of sockets versus file descriptors, since
> sockets *are* file descriptors.

In any case, now that more and more protocols use TLS, if you encode
the a-socket-is-a-file-descriptor assumption too heavily (for example,
by using descriptor passing and expecting that it preserves all
connection state) in your application, you might run into significant
problems very soon.

> It is actually a question of how to specify network addresses in the
> API, i.e. the BSD sockaddr structure versus the Plan 9 extended
> pathname semantics. Using pathnames for everything would eliminate
> warts like embedding pathnames in sockaddrs in order to address a
> local IPC endpoint. On the other hand, filesystem pathnames are a
> uniform hierarchial namespace, which isn't true for the combination
> of network protocol, address, and port - what happens if you
> opendir("/net/")?

Some people have already mounted more classic file systems with
practically unenumerable directories. 8-/

I really wish there were a standard textual representation of socket
addresses.  A couple of years ago, when I was younger and had high
hopes, I designed something for Ada which used

  INET/127.0.0.1/80
  INET6/::1/80
  LOCAL/var/run/server.socket

and so on, and thought it was pretty neat.  But I haven't seen few
efforts in this area, maybe it's not that useful after all.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf