note 1: in my prior mail on this thread i referred to the meng weng interview
at <http://www.circleid.com/article/634_0_1_0_C/>, and my response there. it
turns out the circleid folks braino'd the URL for MAIL-FROM. i've since added
an httpd "Alias" here that makes their broken URL work. if you tried to
follow that link and couldn't, please try again now.
note 2: i'm replying to a message that was sent to both namedroppers@ and
spf-discuss(_at_)(_dot_) this terrifies me. i'm setting reply-to; plz honour
it even
though i'm not a member of the spf-discuss@ list and won't see the rest of
this thread. if you're replying to the DNS issues, do so on namedroppers@,
but in any case, do not bridge this thread to both mailing lists.
I preferred SOA because that is real authority data
...
This all points out that using existing DNS RFC2181 as reference for
what we want is probably not the best idea
I assume that RFC 2181 uses NS for a reason. I do not know it but we
could ask the authors or Google or the namedroppers' archive.
SOA is never cached. it is only meant to be queried for as part of DNS
protocol operations like figuring out if the serial number has changed
(for IXFR/AXFR) or figuring out where to send a DNS UPDATE message. no
normal client of DNS data should propose to query for this. those of you
who are coders can look at my comments in bind8's res_findzonecut() for
more information about finding zone cuts, and you should be asking yourself,
why would a mail server ever do this, let alone do it on every SMTP session?
Below are the results of me checking .ac as Stephane suggested - as
you can see they always provide same zonecut domain name
answers. The difference does exist for sub.domain.com where some of
the servers do provide the answer but majority do not.
This is because some name servers of the TLD are recursive but not all
(there is a "rd" in your flags but not always a "ra" in the
answer). Check with "dig +norecurse" and you'll see a different
picture, specially for zone cuts.
indeed, it is vitally unwise to depend on the behaviour of a specific zone
or a specific dns implementation when planning a protocol feature. you have
to look at what's permitted under the existing specification, and then delete
(not add) some things based on current global practices. sending back an
SOA is optional in many cases. see RFC 2308.
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>