[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fqdn and trailing dot in IDs
Howdy ()
So when we use a FQDN as a name to Identify an endpoint, do we require
and/or enforce that the 'trailing dot' be applied?
An FQDN without a trailing dot is ambigous as pointed out by rfc1912
sect 3.2 (exerpt below)
Always remember your $ORIGIN. If you don't put a `.' at the end of
an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then
the nameserver will append $ORIGIN to the name. Double check, triple
check, those trailing dots, especially in in-addr.arpa zone files,
where they are needed the most.
If we follow the 'robustness' principle and try to say that we always
send with a trailing dot but accept without a trailing dot, then
certianly we would run into trouble hashing over the IDs in the Phase 2
negotiation.
If we follow the 'let the user deal with it' principle, and try to say
"the user must make the ID string be the same on both ends but we don't
really care if it has a trailing dot or not as long as it matches", then
sometimes a non-trailing dot form will be used. In this case, after we
suceed the negotiation, we will have some ambiguity in which packets
match our FQDN rule.
If we follow the 'big brogher knows best' principle and always tag on a
trailing dot for the administrator if they 'forgot' it, then this may
need to be a clearly specified MUST behaviour in the RFCs for it to be
interoperable.
What do y'all think? I vote for enforcing the placement of a trailing
dot. I also note that the example in rfc2401 of fqdn does not have a
trailing dot. This simple fact will lend a strong argument to the 'let
the user deal with it' system and just accepting the small abiguity in
the name.
--
####################################
# Ricky Charlet
# (510) 795-6903
# rcharlet@redcreek.com
####################################
end Howdy;
Follow-Ups: