First off, even a modest NAPTR RRset will comfortably exceed a 512
byte payload. My ENUM zone (3.2.5.2.5.8.8.9.6.1.4.4.e164.arpa)
contains 6 NAPTR RRs. Which is on the low side for reasonable usage.
just as a data point, not to argue about the 'reasonable' size: under +49
the average number of NAPTRs in an RRSet is a little above 2, with very few
going beyond 5 and the largest having 14 NAPTR RRs.
etc, etc. This lookup gets a 507 byte response. And that's with
dropping potentially useful data from the Additional Section as well
as optimal label compression. With EDNS0, the Additional Section
Compression is mandatory and there's not much useful in the additional
section in this case, given today's anti-poisoning measures.
isn't "truncated" and the full response is 602 bytes.
No doubt there's a gain (for size, no real one here) with EDNS0 and we are
in violent agreement that EDNS0 is just 'state of the art' (more precisely:
EDNS0 _and_ reasonable buffer size).
draft says "All servers involved in ENUM resolution". The client
doing the lookup or the server resolving that ENUM lookup does not
have a priori knowledge of the size of the target zone's NAPTR RRset.
There are servers 'involved in ENUM resolution' that don't even serve NAPTR
RRSets and depending on your setup you might be able to know how large NAPTR
responses will grow. Again agreed, i do not think aiming at 512 is reasonable
in the latter case.
Mandating EDNS0 with good buffer sizes is not only essential and
prudent, it's just an application of the "be liberal in what you
receive" principle.
Supporting EDNS0 is just good practice, but the arguments did not support
the claim. Anyway, how can i argue against a non-normative 'MUST'?
Even at 6 NAPTRs -- which is by no means XXL sized -- using EDNS0 is
Sorry for being lazy w.r.t. "XXL" -- i meant that to indicate an RRSet
bringing the response > 512 octets.
to get the data that could/should have been in the Additional
Section. That extra latency is bad news, especially on things like
GPRS networks.
Cool, tell that the low TTL advocates. The additional section doesn't
solve the problem, though.
We will have to sort this out over a few beers at RIPE52. :-)
That sounds intersting enough to postpone further detailed discussion :-)
-Peter
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum