Subject: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt

From: "Martin Streller" <[email-masked]>
Date: Mon, 7 Jul 2003 17:18:40 +0200

Thanks, for the facts

(1) Ok a problem, but wouldn't disturb in my living case/example

(2) Well, it can only be a fair move to foster ongoing discussion
among the DNSSEC group about this issue.

(3) ff. 
- I'd favour the record-synthesizing DNS server. 
I guess such a gizmo at customer/corporate premises would also need to 
be dnssec aware ? Or could I ship around this ? Pls. clarify.

- Yes, the query string containing a Not-A-Number sublabel may happen but wouldn't
cause damage beyond wasted bandwidth.

- If you want to stay away from wildcards you should at least note that it represents
a cheap ENUM entry for low. Intricate provisioning means costs while we're all living in
a consolidating world.

Martin

-----Ursprüngliche Nachricht-----
Von: Patrik Fältström [mailto:[email-masked]]
Gesendet: Montag, 7. Juli 2003 11:35
An: Martin Streller
Cc: Marian Durkovic; [email-masked]; [email-masked]
Betreff: Re: AW: [Enum] Fwd: [Sipping] I-D
ACTION:draft-ietf-sipping-e164-03.t xt

On måndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller 
wrote:

>> The wildcard in DNS
>> have many side effects -- most of them today felt being negative.
>
> you may admit such a statement is a bit vague and nebulous.
>
> Given an example like Marian's or mine - what are the definite
> side effects that you feel negative about ?

(1) If you have an owner which have a CNAME, you can not have any other 
RR with the same owner. Many many people fail on this (for example, 
they add an MX record).
(2) The implications with DNSSEC is not known in enough detail. 
Especially when looking at negative caching. Yes, compared to some 6-12 
months ago, there are ideas on how it might work, but the proposal is 
still to run wildcards in either a delegated zone which is not secure, 
or you synthesize your records, which in turn means you need to have 
the private key online.
(3) It is easy to forget the wildcard when you later need to delegate 
something, and understand the implications (together with (1) above).

But, the largest problems are with (1) and (2).

As DNSSEC is important for ENUM, I rather stay away from wildcards. The 
wildcards _can_ be simulated by either generating many records, or by 
having a DNS server which synthesizes the records.

Another problem when you do ENUM is that there will be responses if 
someone query for for example:

  NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR

and in the DNS I have

  *.1.2.3.4.6.4.e164.arpa. IN NAPTR ....

I don't like that. You might want to store other RR types with similar 
names in the same hierarchy, for example SRV records (which Microsoft 
Active Directory uses heavily) or whatever.

     paf

>
> Martin
>
> -----Ursprüngliche Nachricht-----
> Von: Patrik Fältström [mailto:[email-masked]]
> Gesendet: Sonntag, 6. Juli 2003 18:32
> An: Marian Durkovic
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [Enum] Fwd: [Sipping] I-D
> ACTION:draft-ietf-sipping-e164-03.t xt
>
>
> On söndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic
> wrote:
>
>> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik Fältström wrote:
>>> Can we please keep the discussions about the wildcard in DNS separate
>>> from the regular expression in NAPTR as separate as possible?
>>
>> I don't think this is fully possible. If you want to use wildcard in
>> DNS,
>> you must use non-greedy regular expression with a subpattern ( ) to
>> extract
>> and reuse the digits matched by the wildcard:
>>
>> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa.
>> * IN  NAPTR   100 10 "u" "E2U+sip"
>> "!^\\+42155555(.*)$!sip:1\\[email-masked]!" .
>
> Yes, you are absolutely correct. And one can say dependencies exists in
> the other direction as well.
>
> BUT, today I still see a large number of arguments (especially when
> looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards
> in DNS.
>
> My point is that that is not enough as an argument for removing the
> regular expression in the NAPTR for ENUM. It is needed anyway, and I
> gave an example.
>
> You say you don't want a million NAPTR records in your DNS server, and
> I can understand that given the most common provisioning mechanisms
> which exists.
>
> The IETF do though concentrate on what goes on the wire between hosts,
> and not so much of how things are inside the host itself.
>
> I.e. you might have some DNS software that you can configure given some
> kind of wildcard, BUT, it will not be a wildcard from a DNS
> perspective. That is a very very big difference. The wildcard in DNS
> have many side effects -- most of them today felt being negative.
>
>      paf
>
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
>

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 7 Jul 2003 17:50:44 +0200

On måndag, jul 7, 2003, at 17:18 Europe/Stockholm, Martin Streller 

> (1) Ok a problem, but wouldn't disturb in my living case/example

Good, just remember this... ;-)

> among the DNSSEC group about this issue.

Yes, and there _IS_ a discussion going. I do though think DNSSEC might 
be deployable before we know all details of wildcards, DNSSEC etc 
together. It would be sad if you can not deploy DNSSEC at that date for 
your zone just because of the wildcard (or, you deploy and things go 
*poof*).

> be dnssec aware ? Or could I ship around this ? Pls. clarify.

It can happen in two ways:

  - The records are created for certain queries when the query arrive at 
the server
  - The records are created by the provisioning system

Because of DNSSEC, I would prefer the second, because otherwise you 
need to have the private key signing the zone on the host which 
responds to DNS queries, and that is not something _I_ would like to 
have.

> a cheap ENUM entry for low. Intricate provisioning means costs while 

Absolutely. As I said, the one using wildcards should use it as a last 
resort. That can be implementation issues, cost issues or whatever. One 
should spend some time investigating _why_ wildcards are needed. If one 
have an answer, fine.

One good control question might be:

"Let's use wildcards today. If DNSSEC is not possible together with 
wildcards, will we do DNSSEC or wildcards when that day comes?"

Different people have different answers.

    paf

---

From: Jim Reid <[email-masked]>
Date: Mon, 07 Jul 2003 10:05:36 -0700

>>>>> "Martin" == Martin Streller <[email-masked]> writes:

    Martin> (2) Well, it can only be a fair move to foster ongoing
    Martin> discussion among the DNSSEC group about this issue.

However some of that discussion has to happen here IMO. The DNSSEC
guys will define their protocol. But it'll be up to this WG to figure
out how/if that protocol gets deployed for ENUM and what that means.

    Martin> (3) ff.=20 - I'd favour the record-synthesizing DNS
    Martin> server.=20 I guess such a gizmo at customer/corporate
    Martin> premises would also need to=20 be dnssec aware ? Or could
    Martin> I ship around this ? Pls. clarify.

If your record-synthesising box also signs those records, it'll need
to keep the private key on-line. This is not wise. And generating
signatures on-the-fly introduces a bunch of entertaining denial of
service attacks.

    Martin> - If you want to stay away from wildcards you should at
    Martin> least note that = it represents a cheap ENUM entry for
    Martin> low. Intricate provisioning means costs while = we're all
    Martin> living in a consolidating world.

Indeed. But just because something is cheap doesn't necessarily mean
it's the Right Thing To Do. It could mean that the real issue -- which
seems to be provisioning in this case -- does not get addressed. Or
else a quick+dirty solution imposes undesirable constraints on
whatever is ultimately deployed.

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Jul 2003 10:15:14 -0700 (PDT)

%     Martin> (2) Well, it can only be a fair move to foster ongoing
%     Martin> discussion among the DNSSEC group about this issue.
% 
% However some of that discussion has to happen here IMO. The DNSSEC
% guys will define their protocol. But it'll be up to this WG to figure
% out how/if that protocol gets deployed for ENUM and what that means.

	to that end,  I offer up,   www.rs.net for those who
	wish to integrate DNSSEC into their trials.

%     Martin> (3) ff.=20 - I'd favour the record-synthesizing DNS
%     Martin> server.=20 I guess such a gizmo at customer/corporate
%     Martin> premises would also need to=20 be dnssec aware ? Or could
%     Martin> I ship around this ? Pls. clarify.
% 
% If your record-synthesising box also signs those records, it'll need
% to keep the private key on-line. This is not wise. And generating
% signatures on-the-fly introduces a bunch of entertaining denial of
% service attacks.

	online key storage does not have to have the risk profile
	that is presumed.   Some very interesting work has been done
	w/ ULDR and optical links for having the private key available.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Marian Durkovic <[email-masked]>
Date: Tue, 8 Jul 2003 08:41:42 +0200

> Jim Reid wrote:

Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend
a couple of minutes writing the script to generate the zone files instead 
of opening the topic here.

The approach of having one record per every PBX extension is perhaps usable in 
trials, but it does not scale. Our institutions typically have 3-digit
extensions, the larger ones 4-digit extensions. Having this in mind you can
easily find yourself in the situation, where e.g. 300 customers generate
as much as 1 million records. If there's 1 million records in top-level
domain, you have 1 milion customers to cover the costs. But what will be the
cost per customer, if the number of customers is 300 ?

The approach with wildcards generates only 300 records per 300 customers.
This is huge difference certainly worth inverstigating. 

> Patrik Faltstrom wrote:
> The only place they are used is when the MX record refer to a gateway
> (to X.400 or UUCP) where the other side of the gateway is managing a
> number of (sub-) domains, and it is impossible to point all these
> domains in DNS with individual MX records to the media gateway.

You hit the nail. We need to do similar thing - redirect all voice traffic
to a VoIP gateway connected to PBX with many many extensions.
 
> Michael Haberler wrote:
> Or do you propose to have a wildcard in the zone, and have the server
> interpret it differently - i.e giving a matching non-wildcard response?

This is how wildcards work _now_ with standard DNS - they are internal to 
the host running the DNS daemon. The end-user's resolver has no way to tell,
if the response is based on wildcard or exact record, since the response 
is formulated as exact match in both cases. We can certaintly improve
the default wildcard behaviour with more sophisticated record synthesizing,
in order to get rid of common problems with classic wildcards, but I think
we really need the capability for one-to-many conversion in ENUM DNS.

I'd take BGP as an example. In early BGP3 stages, every C-class network has
to be announced via BGP. Due to scaling issues, BGP4 has to be introduced,
which enabled route aggregation. The ENUM problem is perhaps not that
urgent, since ENUM zones are not dumped to every backbone router, but the
basic principle is the same - the need for some form of aggregation is here
now, and I think we can't close our eyes.

	With kind regards,

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail: [email-masked]        ----
----                                                                  ----
--------------------------------------------------------------------------

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Jul 2003 10:58:46 +0200

The approach of having one record per every PBX extension is
    perhaps usable in trials, but it does not scale. Our institutions
    typically have 3-digit extensions, the larger ones 4-digit
    extensions. Having this in mind you can easily find yourself
    in the situation, where e.g. 300 customers generate as much as
    1 million records. If there's 1 million records in top-level
    domain, you have 1 milion customers to cover the costs. But
    what will be the cost per customer, if the number of customers
    is 300 ?

Most instances of this idea with customers with n-bit extensions
PBX I'm familar with, are actually maintaining such a PBX themselves.
If theu want top do ENUM, the obvious solution is to delegate to
that customer.

    

No, that is different. You can delegate to a nameserver which
maintains that part of the name space for that particular PBX.
There is no need to populate the toplevel with all the nitty gritty
details of that PBX.

	jaap

---

From: Jim Reid <[email-masked]>
Date: Tue, 08 Jul 2003 02:08:02 -0700

>>>>> "Marian" == Marian Durkovic <[email-masked]> writes:

    Marian> The approach of having one record per every PBX extension
    Marian> is perhaps usable in trials, but it does not scale. Our
    Marian> institutions typically have 3-digit extensions, the larger
    Marian> ones 4-digit extensions. Having this in mind you can
    Marian> easily find yourself in the situation, where e.g. 300
    Marian> customers generate as much as 1 million records. If
    Marian> there's 1 million records in top-level domain, you have 1
    Marian> milion customers to cover the costs. But what will be the
    Marian> cost per customer, if the number of customers is 300 ?

I don't understand the point you're trying to make here. You seem to
be saying something "won't scale" for 300 names but somehow scales
just fine for 1 million names. I'm confused. And you've still to
explain why provisioning NAPTRs for each number -- something you said
was trivial -- couldn't be done and why a wildcard RR was the only
possible solution to the problem you're trying to solve. Despite what
you said earlier, this still looks to me that the wildcard has been
suggested as a kludge to work around a provisioning problem. And a
straightforward one at that.

    Marian> The approach with wildcards generates only 300 records per
    Marian> 300 customers.  This is huge difference certainly worth
    Marian> inverstigating.

It has even bigger implications which you don't seem to appreciate.
You've not given any convincing explanation why a wildcard RR is the
only solution and why alternatives are not viable. Please provide that
explanation. 

    >> Patrik Faltstrom wrote: The only place they are used is when
    >> the MX record refer to a gateway (to X.400 or UUCP) where the
    >> other side of the gateway is managing a number of (sub-)
    >> domains, and it is impossible to point all these domains in DNS
    >> with individual MX records to the media gateway.

    Marian> You hit the nail. We need to do similar thing - redirect
    Marian> all voice traffic to a VoIP gateway connected to PBX with
    Marian> many many extensions.

Well this is a perfect example of why DNS wildcards provide the wrong
answer to the wrong question. You're assuming that the only use of
ENUM for some range of numbers would be to contact a VoIP gateway. This
cannot be guaranteed. What happens when the owners of (some of) those
numbers want additional NAPTRs for other services? What if they *don't*
want to use this default VoIP gateway? Or can't use it. What happens
with numbers that are not in service? Should applications which look
these up be pointed at the VoIP gateway regardless? That's what you'd
get with a wildcard. Maybe it would be better to get an NXDOMAIN
response from the DNS. Which of course you can't get if there's a
wildcard RR. The same goes for numbers that are invalid because they
don't have the correct number of digits. What if some of the active
numbers must not be used for VoIP because they're bound to things like
a fax machine or a modem? What if you need to introduce additional
VoIP gateways for some or all of the numbers?

BTW, what you're proposing is NOT similar to the scenario Patrik
outlined at all. You're talking about a known, well-defined, if large,
name space: a range of telephone numbers. It is possible to enumerate
all the domain names that exist there. In fact, it's trivial. In the
scenario Patrik explains the wildcard MX record covers a name space
that is not known and cannot be enumerated because it is somewhat
unstructured and dynamic.

    >> Michael Haberler wrote: Or do you propose to have a wildcard in
    >> the zone, and have the server interpret it differently - i.e
    >> giving a matching non-wildcard response?

    Marian> This is how wildcards work _now_ with standard DNS - they
    Marian> are internal to the host running the DNS daemon. The
    Marian> end-user's resolver has no way to tell, if the response is
    Marian> based on wildcard or exact record, since the response is
    Marian> formulated as exact match in both cases. We can certaintly
    Marian> improve the default wildcard behaviour with more
    Marian> sophisticated record synthesizing, in order to get rid of
    Marian> common problems with classic wildcards,

Sorry, you can't change the semantics of DNS wildcarding without a
wholesale protocol rewrite. And somehow keeping backwards
compatibility with the installed base. Please show how you intend to
do this. For bonus points, get the DNS WGs to adopt your proposal. :-)

    Marian> but I think we really need the capability for one-to-many
    Marian> conversion in ENUM DNS.

I've not seen any justification for this so far though I accept it
might be useful. Perhaps you could provide some examples?

---

From: Marian Durkovic <[email-masked]>
Date: Tue, 8 Jul 2003 15:20:00 +0200

On Tue, Jul 08, 2003 at 10:58:46AM +0200, Jaap Akkerhuis wrote:
> that customer. [snip] You can delegate to a nameserver which

Sure, those records would not appear in the toplevel, but at the ISP level,
since the customers either outsource the DNS to them or at least request
a backup DNS to be operated by the ISP.  

On Tue, Jul 08, 2003 at 02:08:02AM -0700, Jim Reid wrote:
> possible solution to the problem you're trying to solve.

No, I'm saying that 300 PBX customers might create as much 1 million records.
Operating DNS servers with millions of records is not a trivial task at
least not for commonly available DNS software and just this is IMHO a good
reason to look for alternatives which make more decent use of resources.

> numbers want additional NAPTRs for other services? 

I'm not saying everyone _should_ use wildcards for every possible
configuration. But plese don't do the opposite - i.e. don't tell me that
we _must not_ use them.

> What if they *don't*
> want to use this default VoIP gateway? Or can't use it. 

You might still point the wildcard towards e.g. SIP proxy server, which can
handle this more effectively (changes are visible immediately).

> wildcard RR.

This can only introduce another point of failure. This would mean, that PBX
configuration and DNS configuration must be always in sync which is hard
to achieve. Better get the "No subscriber" from the PBX like with PSTN. 

> The same goes for numbers that are invalid because they

Again, you can point the wildcard towards e.g. SIP proxy and introduce much
more services.

> do this.

I don't. I was mentioning record synthesizing indepened of classic wildcards
and their problems.

> might be useful. Perhaps you could provide some examples?

DID (Direct Inward Dial) is a standard telco service that the customers are
used to. Emulating it by enumerating all possible digit combinations could
be only considered as a workaround and is in many cases pure waste of 
resources. If the wildcards are no good, other solution has to be found.

	M.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Jul 2003 15:47:58 +0200

No, I'm saying that 300 PBX customers might create as much 1
    million records.  Operating DNS servers with millions of records
    is not a trivial task at least not for commonly available DNS
    software and just this is IMHO a good reason to look for
    alternatives which make more decent use of resources.

Did you ever try? I'm running a zone with about 3.7 Million records
om a standard PC with standard DNS software. No sweat. In case you
want to know, that is the signed .nl zone (DNSSEC). The normal zone
has about 1.9 records and runs also on commonly known DNS implementations
(Bind 8 & 9, nsd).

The DNS server is not a problem. As said the provisioning is. A
proper registriation system which keeps track of all the (differenvt)
records is the problem. If the (sets of) records are the same, you
can easely generate these in some automatic fashion.

	jaap