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