Subject: [Enum] Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 4 Nov 2003 14:46:43 +0000

Hi folks,
   We have seen domains with more than one NAPTR with the same 
priority/preference
field value "out there"; this shouldn't happen, but as we prefer to be liberal,
how should a Client react?

Again, this is a pure implementation issue; there doesn't seem to be 
anywhere in
2916bis or in 340x where this is explicitly barred, even though the 
WG discussions
have suggested that it's a bad idea.

Some of the affected domains are "published" via DNS servers that 
return responses
in a fixed RRset pattern; examining the NAPTRs themselves, it looks 
like some folk
assume that an "in order" processing is expected.

Now...of course this is risky activity, as there's no guarantee of 
ordering, and
a simple change of DNS server (or version) can remove the option of 
fixed delivery
order, causing some strange results (i.e. Clients calling what were 
assumed to be
lower contacts).
In short, the simple answer is: "don't do it", but whilst there are 
some out there
that do...

We chose to treat NAPTRs with identical order and preference/priority 
field values
in the order they were delivered. I can't see any harm in doing this, 
and if anyone
can see a reason for random evaluation, please holler.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Tue, 04 Nov 2003 15:56:50 +0000

>>>>> "lwc" == Conroy, Lawrence (SMTP) <[email-masked]> writes:

    lwc> Hi folks, We have seen domains with more than one NAPTR with
    lwc> the same priority/preference field value "out there"; this
    lwc> shouldn't happen, but as we prefer to be liberal, how should
    lwc> a Client react?

Well there doesn't seem to be anything which prohibits NAPTRs for some
name having identical priority/preference values and it wouldn't be
reasonable to do so IMO. So in these cases, the client should
figuratively toss a coin to make the decision, just like when mail
software finds there's 2 or more equal preference MX records for some
domain.

    lwc> Now...of course this is risky activity, as there's no
    lwc> guarantee of ordering, and a simple change of DNS server (or
    lwc> version) can remove the option of fixed delivery order,
    lwc> causing some strange results (i.e. Clients calling what were
    lwc> assumed to be lower contacts).  In short, the simple answer is:
    lwc> "don't do it", but whilst there are some out there that  do...

I must be missing something. If the NAPTRs are equal, whoever is
publishing them doesn't care which URI clients go to after they do a
lookup. Therefore the client shouldn't need to be given rules to make
it behave deterministically for these cases. 

A rule which says "select equal NAPTRs in the order they appear in the
DNS response" is meaningless. [Though in practice this is what mail
software tends to do when MX records are equal.] The reason for that
is there could be a resolving name server between the client and the
authoritative name server. So even if the authoritative server sends
out responses with equal NAPTRs in some order, it can't be assumed
that will be the order seen by an end client. A resolving server in
between would almost certainly be doing round-robin on the stuff it
hands out from its cache. There's also the distinct possibility that
authoritative name servers for some ENUM zone could be sending out
responses with equal NAPTRs in a different order, say because they use
different DNS implementations.

Even in the case where the ordering in responses is always the same, I
don't think it's necessary for 2916bis or whatever to tell the client
which one to choose. The publisher of the NAPTR records could/should
have done that by explictly giving them different priority and/or
preference fields. Presumably that publisher had a reason for making
the NAPTRs equal and therefore left it up to the client to choose
based on whatever criteria it felt like applying. It would worthwhile
documenting this: "when NAPTRs are equal, a client is free to choose
any one of the RRs according to its own criteria which may or may not
be random."

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 4 Nov 2003 16:14:41 +0000

Hi Jim, folks,
   Thanks Jim for the detailed comments.
I report only what I've seen. I didn't say it was sensible.
I did say that this is just a pure implementation issue - I'd share your
unhappiness if any such admonition were to be added to a standards track doc.

I stated what ours did, and I asked if there were any good reasons for
randomising evaluation - I didn't see a "don't do this" in your comments,
which I take to mean we aren't doing anything badly dodgy (or the mail
software is as well, which would explain some things). A Result.

all the best,
   Lawrence