Can someone share a complete bind setup example for enum support. I've been stabbing (unsuccessfully) all day. I'm pretty good with DNS, just can't grasp the NAPTR thing.
---greg
some samples are at http://iptel.org/~faqomatic/fom-serve/cache/83.html
-jiri
At 02:40 AM 12/15/2003, Greg Fausak wrote:
Can someone share a complete bind setup example for enum support. I've been stabbing (unsuccessfully) all day. I'm pretty good with DNS, just can't grasp the NAPTR thing.
---greg
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Using the newest version of bind, I've got a file called /tmp/gregtest/dns/named.conf: ---- options { directory "/tmp/gregtest/dns"; pid-file "named.pid"; allow-transfer { none; }; }; ---- another file called /tmp/gregtest/dns/named.boot: ---- directory /tmp/gregtest/dns cache . named.root primary e164.arpa e164.arpa.db ---- another file called /tmp/gregtest/dns/e164.arpa.db ---- $ORIGIN . $TTL 0 e164.arpa IN SOA august.net. root.august.net. 254370021 ; 2003.12.14 13:28:46 IG_CMP 10800 ; refresh 3600 ; retry 604800 ; expire 1200 ; minttl ) ; NS august.net.
$ORIGIN e164.arpa. $ORIGIN 5.6.2.1.6.4.5.9.6.4.e164.arpa. 5.6.2.1.6.4.5.9.6.4.e164.arpa. NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!" ---- I start named with the command: ---- named -g -d 1 -c /tmp/gregtest/dns/named.conf ---- from another window I do a lookup to test: host -v -t NAPTR 5.6.2.1.6.4.5.9.6.4.e164.arpa. localhost ---- lookup fails with: Host 5.6.2.1.6.4.5.9.6.4.e164.arpa not found: 3(NXDOMAIN) ---- and the following is the debug output from the named process. Any clues would be appreciated! Michael, are you out there? Dec 15 22:34:45.293 createfetch: 5.6.2.1.6.4.5.9.6.4.e164.arpa NAPTR Dec 15 22:34:45.293 createfetch: . NS Dec 15 22:34:45.322 createfetch: NS.SUNET.SE A Dec 15 22:34:45.322 createfetch: NS0.VERIO.NET A Dec 15 22:34:45.322 createfetch: TINNIE.ARIN.NET A Dec 15 22:34:45.322 createfetch: E164-ARPA.CNNIC.NET.CN A Dec 15 22:34:45.442 createfetch: dns.digisip.com A Dec 15 22:34:45.442 createfetch: dns5.telia.com A Dec 15 22:34:45.442 createfetch: foot.snowman.sunet.se A Dec 15 22:34:45.442 createfetch: slave.sth.netnod.se A Dec 15 22:34:45.525 no_references: delete from rbt: 0x81c65b0 d3.nstld.com Dec 15 22:34:45.525 no_references: delete from rbt: 0x81c4788 c3.nstld.com Dec 15 22:34:45.525 no_references: delete from rbt: 0x81c4788 b3.nstld.com Dec 15 22:34:45.525 createfetch: b3.nstld.com A Dec 15 22:34:45.525 createfetch: c3.nstld.com A Dec 15 22:34:45.525 createfetch: d3.nstld.com A Dec 15 22:34:45.578 createfetch: server.nordu.net A Dec 15 22:34:45.716 no_references: delete from rbt: 0x81c5a10 cns.cernet.NET Dec 15 22:34:45.716 createfetch: cns.cernet.net A Dec 15 22:34:45.716 createfetch: sld-ns1.CNNIC.NET.CN A Dec 15 22:34:45.716 createfetch: sld-ns2.CNNIC.NET.CN A Dec 15 22:34:45.716 createfetch: sld-ns3.CNNIC.NET.CN A Dec 15 22:34:45.716 createfetch: sld-ns4.CNNIC.NET.CN A Dec 15 22:34:45.716 createfetch: sld-ns5.CNNIC.NET.CN A Dec 15 22:34:45.718 no_references: delete from rbt: 0x81d4b30 server.nordu.NET Dec 15 22:34:45.805 createfetch: dns.edu.cn A Dec 15 22:34:45.805 createfetch: ns2.net.edu.cn A Dec 15 22:34:45.839 no_references: delete from rbt: 0x81cb310 server.nordu.NET Dec 15 22:34:45.861 createfetch: ns.webway.se A Dec 15 22:34:45.862 createfetch: eco.webway.se A Dec 15 22:34:45.862 createfetch: sec.webway.se A Dec 15 22:34:45.865 no_references: delete from rbt: 0x81dae70 ns2.cw.NET Dec 15 22:34:46.013 no_references: delete from rbt: 0x81d2c70 ns2.cuhk.hk Dec 15 22:34:46.013 no_references: delete from rbt: 0x81bd768 ns2.cernet.NET Dec 15 22:34:46.013 no_references: delete from rbt: 0x81d2c70 deneb.dfn.de Dec 15 22:34:46.013 createfetch: ns2.cuhk.hk A Dec 15 22:34:46.014 createfetch: ns2.cernet.net A Dec 15 22:34:46.014 createfetch: deneb.dfn.de A Dec 15 22:34:46.016 no_references: delete from rbt: 0x81b4d10 ns2.cuhk.hk Dec 15 22:34:46.016 no_references: delete from rbt: 0x81d2760 ns2.cernet.NET Dec 15 22:34:46.016 no_references: delete from rbt: 0x81d2790 deneb.dfn.de Dec 15 22:34:46.054 no_references: delete from rbt: 0x81b4918 dns.hecc.SE Dec 15 22:34:46.497 no_references: delete from rbt: 0x81c4b80 ns1.CUHK.EDU.hk Dec 15 22:34:46.563 no_references: delete from rbt: 0x81bacf0 ns2.NET.edu.CN ---greg
Jiri Kuthan wrote:
some samples are at http://iptel.org/~faqomatic/fom-serve/cache/83.html
-jiri
At 02:40 AM 12/15/2003, Greg Fausak wrote:
Can someone share a complete bind setup example for enum support. I've been stabbing (unsuccessfully) all day. I'm pretty good with DNS, just can't grasp the NAPTR thing.
---greg
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
On (14.12.03 22:36), Greg Fausak wrote:
$ORIGIN e164.arpa. $ORIGIN 5.6.2.1.6.4.5.9.6.4.e164.arpa. 5.6.2.1.6.4.5.9.6.4.e164.arpa. NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!"
Greg,
two things:
- The NAPTR record above is missing the "replacement" field, which, if you do not use it, should be represented by a dot. So, it should look like:
NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!" .
(mind the trailing dot).
Dec 15 22:34:45.293 createfetch: 5.6.2.1.6.4.5.9.6.4.e164.arpa NAPTR Dec 15 22:34:45.293 createfetch: . NS Dec 15 22:34:45.322 createfetch: NS.SUNET.SE A Dec 15 22:34:45.322 createfetch: NS0.VERIO.NET A Dec 15 22:34:45.322 createfetch: TINNIE.ARIN.NET A
From the debug output, it seems to me that the dns is ignoring the
authoritative zone, but looking up the record in the "official" public tree.
Probably it would be easier to start with a private ENUM zone, e.g.
e164.august.net.
and enter those test records there. In that case, you don't risk confusing your private DNS tree with public information.
cheers
axelm
Thanks!
I tried these things...still get the same NXDOMAIN error.
I'll poke about some more....
Dang, I'm pretty good at DNS, I've do DNS for thousands of domains. MX, SRV, A, CNAME, PTR, etc... Just when I think I'm an expert :-)
---greg
Alexander Mayrhofer wrote:
On (14.12.03 22:36), Greg Fausak wrote:
$ORIGIN e164.arpa. $ORIGIN 5.6.2.1.6.4.5.9.6.4.e164.arpa. 5.6.2.1.6.4.5.9.6.4.e164.arpa. NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!"
Greg,
two things:
The NAPTR record above is missing the "replacement" field, which, if you do not use it, should be represented by a dot. So, it should look like:
NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!" .
(mind the trailing dot).
Dec 15 22:34:45.293 createfetch: 5.6.2.1.6.4.5.9.6.4.e164.arpa NAPTR Dec 15 22:34:45.293 createfetch: . NS Dec 15 22:34:45.322 createfetch: NS.SUNET.SE A Dec 15 22:34:45.322 createfetch: NS0.VERIO.NET A Dec 15 22:34:45.322 createfetch: TINNIE.ARIN.NET A
From the debug output, it seems to me that the dns is ignoring the
authoritative zone, but looking up the record in the "official" public tree.
Probably it would be easier to start with a private ENUM zone, e.g.
e164.august.net.
and enter those test records there. In that case, you don't risk confusing your private DNS tree with public information.
cheers
axelm
A couple of things were stumping me. I have the DNS working now. The problems I ran into were the 'dot' you mention below, and the 'named.boot' file. named.boot is used for dns, version 4? named.conf is used for version 9. Our dns system supports both, so I had a brain fart...I was modifying the named.boot file when in fact dns9 used named.conf.
Anyway, I have my e164 stuff in DNS and ready to test.
I've got a request uri, and it does not have the leading '+' sign. I am going to use enum for some internal routing. Ultimately I'll try to interconnect with other sip domains.
Can enum do a lookup on the current uri without the leading '+' sign? Will this do the trick?
prefix("+"); if(enum_query("")) { t_relay(); } else { strip(1); };
thanks!
---greg
Alexander Mayrhofer wrote:
On (14.12.03 22:36), Greg Fausak wrote:
$ORIGIN e164.arpa. $ORIGIN 5.6.2.1.6.4.5.9.6.4.e164.arpa. 5.6.2.1.6.4.5.9.6.4.e164.arpa. NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!"
Greg,
two things:
The NAPTR record above is missing the "replacement" field, which, if you do not use it, should be represented by a dot. So, it should look like:
NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:4695461265@addaline.com!" .
(mind the trailing dot).
Dec 15 22:34:45.293 createfetch: 5.6.2.1.6.4.5.9.6.4.e164.arpa NAPTR Dec 15 22:34:45.293 createfetch: . NS Dec 15 22:34:45.322 createfetch: NS.SUNET.SE A Dec 15 22:34:45.322 createfetch: NS0.VERIO.NET A Dec 15 22:34:45.322 createfetch: TINNIE.ARIN.NET A
From the debug output, it seems to me that the dns is ignoring the
authoritative zone, but looking up the record in the "official" public tree.
Probably it would be easier to start with a private ENUM zone, e.g.
e164.august.net.
and enter those test records there. In that case, you don't risk confusing your private DNS tree with public information.
cheers
axelm
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 03:46 PM 12/16/2003, Greg Fausak wrote: [...]
Anyway, I have my e164 stuff in DNS and ready to test.
I've got a request uri, and it does not have the leading '+' sign. I am going to use enum for some internal routing. Ultimately I'll try to interconnect with other sip domains.
Can enum do a lookup on the current uri without the leading '+' sign? Will this do the trick?
The ENUM module takes only URIs with leading +, numbers in it, length >2 and < 17. You can normalize numbers to this form as you suggest. For example, that's what I do to make sure that phones without + can live with it too...
if (uri =~ "sip:[+*#][0-9]+@") { # normalize prefixes strip(1); prefix("+");
-jiri
Greg Fausak wrote:
Can someone share a complete bind setup example for enum support. I've been stabbing (unsuccessfully) all day. I'm pretty good with DNS, just can't grasp the NAPTR thing.
http://www.voip-info.org/wiki-Asterisk+E164+Call+Routing includes some examples of DNS entries, even though this article covers Asterisk.
Beware that you need Bind 9 to use regular expressions in DNS, bind 8 zone transfers messes these up.
/O