In message <20160718141147.ga16...@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 > > > >2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" > >"!^.*$!sip:7895673...@atlanta.com > ;user=phone!" . > >2.7.5.2.7.9.2.5.3.1.8.e164enum.net. IN NAPTR 100 10 "u" "E2U+sip" > >"!^.*$!sip:7895673...@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:7895673...@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. Order 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). Preference 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, uh...@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@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users