Query on the Order in which RR are answered by Bind of Order/preference are Same

Mark Andrews marka at isc.org
Tue Jul 19 05:35:19 UTC 2016

In message <20160718141147.GA16055 at fantomas.sk>, Matus UHLAR - fantomas writes:
> On 18.07.16 13:59, Harshith Mulky wrote:
> >I had a query on how the following Records can be ordered on how the Records are configured in the 
> Zone file
> >
> >I have done 2 different Tests
> >
> >I have configured following records in the Zone file e164enum.net with TTL value as 0
> >
> > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:7895673454 at ATLANTA.COM
> ;user=phone!" .
> > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:7895673453 at ATLANTA.COM
> ;user=phone!" .
> >Since I did not want the Answers to be toggled in each susbsequent digs, and I wanted the Answers t
> o be in the same Order they were configured in the Zone file(since the Order and Preference of both 
> these records were same), I enabled this line in the options field of named.conf
> >rrset-order {order fixed;};
> >and restarted named
> >
> >I ran the dig query again
> >
> >This time, the Answers did not toggle, but I found that, the second configured RR was being Answere
> d as first always sip:7895673453 at ATLANTA.COM
> >
> >Why is Bind answering the Second RR as first and not my original First RR as 1st Answer?
> the order provided applies only for your bind instance - any other
> nameserver can change the order.
> why don't you use higher order if you want to have them in order?

Agreed.  NAPTR records contain instructions for how the client
processes multiple records.

      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

      A 16-bit unsigned integer that specifies the order in which NAPTR
      records with equal "order" values SHOULD be processed, low
      numbers being processed before high numbers.  This is similar to
      the preference field in an MX record, and is used so domain
      administrators can direct clients towards more capable hosts or
      lighter weight protocols.  A client MAY look at records with
      higher preference values if it has a good reason to do so such as
      not understanding the preferred protocol or service.

      The important difference between Order and Preference is that
      once a match is found the client MUST NOT consider records with a
      different Order but they MAY process records with the same Order
      but different Preferences.  I.e., Preference is used to give weight
      to rules that are considered the same from an authority
      standpoint but not from a simple load balancing standpoint.

As for the output order from named you need to compile named with
fixed ordering support enabled (--enable-fixed-rrset). It takes
more memory per record and requires additional processing in lots
of places to preserve the entry order.  What you are seeing is named
returning the records in DNSSEC order which is how they are stored
by default.  Named needs to sort the records into DNSSEC order to
validate them.

> -- 
> Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the bind-users mailing list