Wildcard behaviour

Edward Lewis Ed.Lewis at neustar.biz
Mon Feb 25 14:29:42 UTC 2008


At 10:16 +0000 2/25/08, Howard Wilkinson wrote:
>I have been asked about the behaviour of the MyDNS product when
>answering questions that match wildcards. I am looking for a
>(definitive) answer as to the behaviour of BIND in this case.
>The particular case I have is that the server has a wildcard A record
>for a zone (e.g *.example.com -> 192.168.1.1) and the query is for a
>host with a label that contains a dot (e.g. www.us.example.com)

Read RFC 4592..."The Role of Wildcards in the Domain Name System "

ftp://ftp.rfc-editor.org/in-notes/rfc4592.txt
http://rfc-editor.org/errata_search.php?rfc=4592

See section 2.2.1

>Should the server match the wildcard if:
>
>    1. The label is in the example.com zone?

It's hard to understand the question - if the label (=query name) is 
in (exists in?) the zone, then there's no wildcard processing.

>    2. The label is in a delegated zone which is also served by this server?

Wildcards do not synthesize across zone cuts.

>    3. The label is in a delegated zone which is served by another server
>       and we are supporting recursion?

When doing recursion, the server does not "do" wildcards.

>    4. The query is for a different type of record?

Wildcard processing is independent of type after you have found the 
name that will generate the answer.

>With item 4 this becomes complicated if we are looking for MX records etc.
>
>What would BIND's behaviour be in these cases, are there any other
>subtle things to worry about and what behaviour is likely to kill
>resolvers/clients if we get it wrong.

The best way to answer that (what would BIND do) is set up BIND with 
a sample zone and use dig to issue queries.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.


More information about the bind-users mailing list