Subject: RE: [Enum] New DNS record class values?

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 20 Jan 2000 12:05:55 -0500

Patrik Fältström wrote:
> --On 2000-01-20 02.51 +0100, Sören Nyckelgård 
> <[email-masked]>
> wrote:
> 
> > If instead the E.164 
> > number identifies a user that might move between different 
> terminals, 
> > then the DNS record preferably should point to an address data 
> > repository that can be dynamically updated. 
> 
> Or, we update the DNS to hold the correct record. I.e. it all 
> depends on
> what timeframes you talk about. DNS refresh values which are 
> minutes is no
> problem at all. Seconds are a problem because of cacheing. I.e. having
> inconsitencies over a few minutes is not (today) so strange.

The DNS system updates slowly, though, so you don't want to use it for
keeping track of mobile stations. You can expect hours for all DNS servers
to get synched up.

> But, when I leave the office and redirect my phone to the 
> phone switch, it
> still takes me a few minutes to grab all my stuff and 
> actually leave the
> building, so a few minutes delay is no problem for me.
> 
> That said, DNS will NOT be able to be updated atomically, but 
> neither will
> a distributed/replicated LDAP solution. Forcing always a query to the
> authoritative source will be costly, regardless of protocol 
> (but of course
> more problematic in DNS because of client-side cacheing).
> 
> So, as long as one _know_ what delays the protocol inject in 
> the resolution
> process, it is possible to build services which match those services.

I'm not sure about mobile telephones, but if they operate similar to mobile
IP and mobile ATM, you'll need the DNS to point to a "home server" of some
sort, which keeps track of the current location of the mobile host?

Bert
[email-masked]

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Jan 2000 19:25:37 +0100

> keeping track of mobile stations. You can expect hours for all DNS servers

Nope, not any longer. Newer versions of bind, and many other implementors
servers:

(1) Have individual TTL on each record, and not on all records in the zone,
i.e. TTL in the SOA is no longer "default"

(2) Have the TTL shorter than 15 minutes (earlier implementations sometimes
had problems with this)

(3) Have the primary server sending notifications to secondaries when the
zone is updated

All of this works so well in todays internet, so I would say that DNS
servers today are in sync modulo a few seconds, and TTL is set by the
master server -- which by this is in total control of how long the delay is
before the records are in sync.

   paf

---

From: Giuseppe Ricagni <[email-masked]>
Date: Fri, 21 Jan 2000 16:42:50 +0100

Patrick,

Patrik Fdltstrvm wrote:

> servers today are in sync modulo a few seconds

I' m not a DNS expert.
The only thing I am sure of is that I kept getting hits on my old web server for
at least four days when I  changed the IP address associated to my domain name.
This happened in June 1999.

Something must have changed in these last six months...

Giuseppe

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:[email-masked]
----------------------------------------------------------

---

From: Bill Manning <[email-masked]>
Date: Fri, 21 Jan 2000 07:57:42 -0800 (PST)

% > All of this works so well in todays internet, so I would say that DNS
% > servers today are in sync modulo a few seconds
% 
% I' m not a DNS expert.
% The only thing I am sure of is that I kept getting hits on my old web server for
% at least four days when I  changed the IP address associated to my domain name.
% This happened in June 1999.
% 
% Something must have changed in these last six months...
% 
% Giuseppe

	Based on the size and frequency of the update, patrick is correct,
	syncronization occurs in seconds.  However, the historical methods
	involve manual, out-of-band coordination with the parents and children
	of a zone. So it may take you four weeks to contact me and for me
	to update the data on my servers. Once I do however, the change is
	done in seconds.

-- 
--bill

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 21 Jan 2000 17:02:36 +0100

--On 2000-01-21 16.42 +0100, Giuseppe Ricagni <[email-masked]>
wrote:

> The only thing I am sure of is that I kept getting hits on my old web
> server for at least four days when I  changed the IP address associated
> to my domain name. This happened in June 1999.

You might have hit two different problems here, and which it is in this
case I can not tell given your information:

(1) You have your own domainname, and moved the domain by contacting the
registry for the parent domain of yours, and the holder of _that_ DNS
didn't update his DNS, or did have misconfigured things in his DNS

(2) You have changed the A record in your DNS server for the web server,
but you have not correct TTL's -- misconfigured slave servers etc

Things have been relative fine regarding DNS updates since version 8 of
bind came out, which I guess was some 3 years ago.

I.e. I don't think the problems of yours was the DNS server itself, but
configuration issues. If you tell me the domainname in question, and the
name of the A-record you changed, I can have a look.

   paf

---

From: Giuseppe Ricagni <[email-masked]>
Date: Fri, 21 Jan 2000 17:33:14 +0100

> didn't update his DNS, or did have misconfigured things in his DNS

Not possible: I was getting hits on BOTH addresses: the new one and the old
one.
I don' t even believe in misconfiguration: I think they know what they are
doing at nic.it.

My much simpler explanation is the same one that Bill provided:

        to update the data on my servers.

That is to say: in theory you might be right, but if we use the word "Internet"
to mean the "Big Internet", there is a legacy of "historical methods" that will
take years to disappear.

To summarize, in the "Big Internet" as it is today, it still takes days before
all the DNS servers in the world sync, and we don' t really know whn this is
really going to change.

Giuseppe

BTW...

> If you tell me the domainname in question, and the

....it was my personal domain name (ricagni.it), but I think it's better if we
take this off-line !

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jan 2000 15:17:38 +0100

--On 2000-01-21 17.33 +0100, Giuseppe Ricagni <[email-masked]>
wrote:

> To summarize, in the "Big Internet" as it is today, it still takes days
> before all the DNS servers in the world sync, and we don' t really know
> whn this is really going to change.

You have still not told me _what_ you wanted to change. It is not clear if
you are refering to a problematic manual re-delegation of a zone, or if it
is an update of a record in your zone.

What I claim is that the latter nowadays do work and the zones and records
will be updated within seconds. What Bill talks about is the former, the
manual process regarding updates of delegation points of zones, and the
manual processes which too far often lead to lame delegation.

What we talk about in the ENUM group is the changes in one zone, which does
not involve any manual work at all, given that the primary zone server is
updated correctly (serial number is changed in the SOA etc). Not the
problem Bill talks about.

   Patrik

---

From: Giuseppe Ricagni <[email-masked]>
Date: Mon, 24 Jan 2000 23:14:29 +0100

I suggested to take it off-line, but....

Patrik Fältström wrote:

> whn this is really going to change.

You have still not told me _what_ you wanted to change. It is not clear
if

you are refering to a problematic manual re-delegation of a zone, or
if it

will be updated within seconds. What Bill talks about is the former,
the

manual process regarding updates of delegation points of zones, and
the

you are right, I was re-delegating a zone, which might  be not the
same thing we need to do in ENUM.

Nevertheless, today, the TTL of the record we've been discussing about
is 2 days. It seems to me this is a fairly common value in the nowadays
Internet. (RFC 1034: While short TTLs can be used to minimize caching,
and a zero TTL prohibits caching, the realities of Internet performance
suggest that these times should be on the order of days for the typical
host)

That means that I still need 2 days to be sure all the resolutions of
the domain go to the new IP, should I decide to change IP.

My question now are:

can anybody point us to any paper/BCP RFC/document of any kind reporting
an analysis in term of performance requirements on the authoritative DNS
servers and on other "bottleneck" DNS servers in the Big Internet adopting
TTLs in the order of a few seconds, for a number of records comparable
to the Enum users (1E5, 1E7, more ?)

can anybody point us to any paper/BCP RFC/document of any kind reporting
an analysis in term of traffic in the Big Internet adopting TTLs in the
order of a few seconds, for a number of records comparable to the Enum
users

What RFC are you referring to when you claim we can "Have the primary server
sending notifications to secondaries when the zone is updated".

Has anybody any idea of the percentage of DNS servers in the Internet that
comply with such RFC ?

Then, if we recognize that, given the number of Enum users,
performance is not an issue, I will be the first one to be interested in
DNS-based mobility applications.

Best Regards

Giuseppe Ricagni

Giuseppe RICAGNI

Broadband Networks

Italtel

via Reiss Romoli - C10

ITALY

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 25 Jan 2000 06:46:20 +0100

> I suggested to take it off-line, but.... 

Yes, but it is important to discuss some of these things so we all
understand where the bottlenecks are. As Bill said, there are some
bottlenecks! There are other places which are not bottlenecks.

> you are right, I was re-delegating a zone, which might  be not the same
> thing we need to do in ENUM. 

I think not. I might be wrong, but we need to, as there is a manual process
regarding changing zone delegations, be careful when designing this thing
so we don't force people into manual handshaking when doing day-to-day
operations.

> Nevertheless, today, the TTL of the record we've been discussing about is
> 2 days. It seems to me this is a fairly common value in the nowadays
> That means that I still need 2 days to be sure all the resolutions of the
> domain go to the new IP, should I decide to change IP. 

You should set a TTL which is say 2 minutes. If then both the primary and
secondary servers support RFC 1996, the zone will be updated and kept up to
date between the servers within seconds of the change in the primary
server. The only issue then is the 2 minute caching in the client issue. I
claim that this value _nowadays_ can be very low, but still not zero.

> My question now are: 
>   
>   · can anybody point us to any paper/BCP RFC/document of any kind
>   reporting an analysis in term of performance requirements on the
>   authoritative DNS servers and on other "bottleneck" DNS servers in the
>   Big Internet adopting TTLs in the order of a few seconds, for a number
>   of records comparable to the Enum users (1E5, 1E7, more ?) 

No. I have tried to get some people working on this issue, but have not
found anyone being able to _really_ looking at the problem. Note that we
only talk about the records at the leaves of the DNS tree, and I claim that
the individual records which are stored there had a time before which was
about 3 hours. I further claim that the same entity do not often call the
same party (use the same E.164 number) two times or more within that time
period. Because of that, it doesn't matter if the TTL is 3 hours or 2
minutes. One will still very seldom reuse the cached value.

The _real_ gain regarding updates in DNS is the syncronization between
primary and secondaries, and before NOTIFY (RFC 1996) one had to have a
very short refresh value, which increased the load on the primary server.
Now, the primary server will push information to the secondary, and
together with  RFC 1995, incremental zone transfer, the servers are kept in
sync in a very efficient and bandwidth-saving way.
 
>   · can anybody point us to any paper/BCP RFC/document of any kind
>   reporting an analysis in term of traffic in the Big Internet adopting
>   to the Enum users 

See above. No, but I guess that TTLs which are short will not change the
number of lookups. The query have to go to an authoritative source anyways.
So, in calculations we do (if someone starts) have to work on the
assumption that queries have to be done to the authoritative source, where
the TTL for intermediate nodes (NS records) are long, but TTLs on leaf
nodes are short.

>   · What RFC are you referring to when you claim we can "Have the primary
>   server sending notifications to secondaries when the zone is updated". 

RFC 1996, and then 1995 for incremental updates.

>   · Has anybody any idea of the percentage of DNS servers in the Internet
>   that comply with such RFC ? 

I know that Bind do, since a number of versions back. I don't have the bind
history in front of me, but it was implemented quite soon after the RFCs
was published, if not before even. The RFCs are dated august 1996.

> Then, if we recognize that, given the number of Enum users,  performance
> is not an issue, I will be the first one to be interested in DNS-based
> mobility applications. 

Well, note that I am talking about having a TTL of a minute or so, and that
secondaries and masters are only kept in sync within seconds. That means
that you still have an interval where one do not have correct information
on the net after an update. The interval is though nowadays 1 minute or so,
and not several hours (or days). In many applications 1 minute out of sync
is bad, really bad, but in others it is fairly ok. So, for general
redirection service, I think this is a service level which is kind of ok,
but serious IN systems still have to be updated simoultanously, and I would
implement that by having the DNS always point to the IN system, which in
turn gives back a good response.

Conclusion, DNS is better than what many people belive, but it is not 100%
correct. Minute-delay happens, but not much more.

   Patrik