Wildcard matching logic for NAPTR Records (bind9)

Mark Andrews Mark_Andrews at isc.org
Wed Mar 17 21:55:53 UTC 2004


> I have the following 3, and only these 3, NAPTR records in my named
> server (bind v9.2.3):
> 
>     (output of "dig -t AXFR e164.localdomain @localhost")
> 
> *.e164.localdomain.     3600    IN      NAPTR   100 100 "u" "SIP+E2U"
> "!^(.*)sip:\\1 at any.com!" .
> *.6.6.e164.localdomain. 3600    IN      NAPTR   100 100 "u" "SIP+E2U"
> "!^(.*)sip:\\1 at six.com!" .
> *.7.6.e164.localdomain. 3600    IN      NAPTR   100 100 "u" "SIP+E2U"
> "!^(.*)sip:\\1 at seven.com!" .
> 
> If I do a query of "dig -t NAPTR 8.e164.localdomain", the named server
> gives me the expected answer, with dig output of:
> 
> ;; ANSWER SECTION:
> 8.e164.localdomain.     3600    IN      NAPTR   100 100 "u" "SIP+E2U"
> "!^(.*)sip:\\1 at any.com!" .
> 
> If I do a query of "dig -t NAPTR 8.6.6.e164.localdomain", it also
> generates the expected answer of:
> 
> ;; ANSWER SECTION:
> 8.6.6.e164.localdomain. 3600    IN      NAPTR   100 100 "u" "SIP+E2U"
> "!^(.*)sip:\\1 at six.com!" .
> 
> 
> But, if I do a query of either
> 
> (A):  dig -t NAPTR 8.6.e164.localdomain
> ,or
> (B):  dig -t NAPTR 6.6.e164.localdomain
> 
> The named server gives me no ANSWER section in dig output.  Is this
> the expected behavior of DNS/NAPTR key matching logic? 

	Yes.  This is how wildcards work.

> I would expect
> query (A) to return me the NAPTR record corresponding to key
> "*.e164.localdomain.", and query (B) to return the NAPTR record that
> matches key "*.6.6.e164.localdomain.".

	
	(A) the empty node 6.e164.localdomain blocks the wildcard
	    match.

	(B) '*' matches 'one or more labels'. You need a NAPTR
	     record for 6.6.e164.localdomain to get a match.

	You need to add

	6.e164.localdomain	NAPTR	@any.com
	*.6.e164.localdomain	NAPTR   @any.com
	6.6.e164.localdomain	NAPTR   @six.com
	7.6.e164.localdomain	NAPTR	@seven.com
 
> Can anyone point me to the detailed logic explaining the key lookup
> logic of DNS/named when there's a wildcard (*) in the key?  I couldn't
> find it in RFCs.

	It's in RFC 1034.
 
> Thanks,
> 
> --- Jeffrey
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org


More information about the bind-users mailing list