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
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

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