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

From: Jim Reid <[email-masked]>
Date: Mon, 07 Jul 2003 07:54:18 -0700

>>>>> "Michael" == Michael Haberler <[email-masked]> writes:

    Michael> maybe we should just cook up a syntax for a bind9 config
    Michael> file and a= semantics

Please don't confuse the DNS protocol with an implementation of that
protocol. In all probability a "solution" based around BIND9 is not
likely to be practical in the long run. If/when ENUM takes off, the
datasets are going to be 1-2 orders of magnitude bigger than what's in
the DNS today, maybe more. [Compare the number of registrations or
domain names under .at with the number of phones in Austria for
example.] Managing and provisioning these sorts of datasets with BIND9
text files will be very, very painful. They may even be unworkable.

_______________________________________________
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: Michael Haberler <[email-masked]>
Date: Mon, 07 Jul 2003 16:38:46 +0200

At 18:31 06.07.2003 +0200, Patrik Fältström wrote:

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.

that is quite an elegant idea - if I get you right you propose to PROVISION 
it as a wildcard, have special code interpret it and give specific  answers 
if the wildcard would match in the status ante scenario

however - do i get this right that this will break zone transfer as we know 
it? and I'm fuzzy what the DNSsec implications are - I would assume you 
cant sign a record which isnt in the zone

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?

those with working ENUM trials;) have a strong interest in a good solution 
of this problem (enumeration of number space != good)

if we can reach consensus as to how to provision this and what the 
semantics are, we might have a non-problem afterall and we instead could go 
home and build the damn thing

maybe we should just cook up a syntax for a bind9 config file and a semantics

-Michael

---

From: Michael Haberler <[email-masked]>
Date: Mon, 07 Jul 2003 17:02:57 +0200

did that math - that's why we are not running bind9 for 3.4.e164.arpa; we 
run a server straight off a database

I really dont care about the vehicle, I just assumed a bind9 config option 
would serve well as an operational specification and guideline for the rest 
of us

So what would you propose instead?

-Michael

---

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

On måndag, jul 7, 2003, at 16:38 Europe/Stockholm, Michael Haberler 
wrote:

> however - do i get this right that this will break zone transfer as we 
> know it? and I'm fuzzy what the DNSsec implications are - I would 
> assume you cant sign a record which isnt in the zone

The proposal I saw talked about using a wildcard in DNS, which is a 
very very special thing in the DNS specification. What I saw the 
proposal talked about was a "simple" way of specifying what to do with 
not all possible labels in a zone (which DNS wildcard help with) but 
instead what happens with the labels which matches the syntax of an 
ENUM NAPTR. (Just digits, one digit in each label.

Those are two very different things.

And, what you talk about above are some of the issues with Wildcards.

What I said was not that wildcards in dns should not be used, but, as 
Jim says, it should be as the absolute last resort, and the one 
choosing to use wildcards must know about the implications.

    paf