that's how I understand it also. This DNS query is happening before the SCSCF would issue an ENUM. I believe it would eventually do this but the purpose of this dns query is to find the SIP entry point (icscf) into a domain for the call.<div>
<br></div><div>I think this is either a config issue on my end or a bug. The tel uri is coming in from an ims subscriber who is registered to the domain. I would think the P-CSCF would use the domain from the caller for the dns query.</div>
<div><br></div><div>Thanks for verifying that bind is doing the right thing....</div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 12:52 PM, Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com" target="_blank">kcd@chrysler.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I don't believe SRV lookups use the
"search" directive in /etc/resolv.conf; I think that's only for A
(name-to-address) lookups. But I could be wrong on that...<br>
<br>
It all comes back to: the client should know what domain contains
the resources it's looking for. There's fundamentally no such
thing as a "generic" SRV lookup; SRV lookups are always contextual
to a particular domain.<br>
<br>
As for your point about "tel:" URIs having no domain, I'm no IP
telephony expert by any stretch of the imagination, but isn't ENUM
used to map a phone number (as found in a "tel:" URI) to one or
more domains for the SRV lookup(s)? Or am I way off-base here?<span class="HOEnZb"><font color="#888888"><br>
<br>
-
Kevin</font></span><div><div class="h5"><br>
On 8/15/2012 12:06 PM, Thomas Secula wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">That's what I tried to tell the OpenIMS folks. I have
search mydomain in/etc/resolv but somehow they aren't adding
mydomain to the query. This only happens when the PCSCF tries to
find the ICSCF after receiving a SIP invite with a TEL uri which
by definition has no domain since it's in the pstn.
<div>
<div><br>
</div>
<div>I don't believe this is a bind issue as I would expect the
P-CSCF to get that NXDOMAIN and be able to handle it, likely
an openims bug.</div>
<div><br>
</div>
<div>thanks for all your replies!!!1<br>
<br>
<div class="gmail_quote">On Wed, Aug 15, 2012 at 10:57 AM,
Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com" target="_blank">kcd@chrysler.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>There's no point in answering a "domain-less"
SRV-record query, since the whole point of the SRV
record type is to allow clients to find resources
associated with a particular domain (and
protocol/transport).<br>
<br>
You need to set the proper domain on the client doing
the lookup.<span><font color="#888888"><br>
<br>
- Kevin</font></span>
<div>
<div><br>
<br>
On 8/15/2012 10:42 AM, Thomas Secula wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>Hello,
<div><br>
</div>
<div>I hope this is the right list.. I am using
bind 9.8.2on centos 6 with a system called
openims. I am trying to get my bind server to
respond to an SRV query of _sip._udp where the
query has no domain. I am told by the openims
folks that I should be able to get my bind to
respond but I have been unable to.</div>
<div>If I do a dig it only works if I have a
+search on the request. without teh +search I
get NXDOMAIN back.</div>
<div><br>
</div>
<div>Is this something I should expect bind to
support?</div>
<div><br>
</div>
<div>thank you...</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<div>
<pre>_______________________________________________
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</div>
</blockquote>
<br>
<br>
</div>
<br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
</div></div></div>
<br>_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div><br></div>