e is trying to reduced the size of the IP stack on the client
(e.g. in a phone) then NAT64 may be a better alternative but for
home users it really isn't.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@i
al_ actual disincentive for users to go v6-only. (Think Metcalfe's
> Law.)
>
> And without a lot of users who are v6-only, what's the incentive for
> _everyone_ to make content available in v6? (Close loop, feed back.)
>
> Noel
> ___
Pv6 today.
Mark
> > You can find Daniel's recent talk at http://www.ipv6.ie/summit2010/.
>
> I can find a link to his talk on that site, but each time I click on
> that link I get a quickly-broken TCP connection. Overloaded, perhaps?
> -- Cos
> ___
> Ietf mailing list
>
_
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> >
>
>
>
> -- =
>
> -- =
>
> New Website: http://hallambaker.com/
> View Quantum of Stupid podcasts, Tuesday and Thursday each week,
but it's understood even by non-IETFers.
And even that can be confusing if English is not a language you
understand.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_
gt; > unambiguous; no widely used date format uses hyphens and has the
> > ordering different.
>
> Exactly.
>
> Marshall
It's confusing but not ambigious.
> > Just get used to it. And while at it, switch to 24h :-)
> >
> > Best regards, Julian
> &g
-capable PDF"? A PDF viewer
> that doesn't understand, for example, code point 160?
The problem with email is people use html way too much. TXT ->
HTML -> TXT does not work reliable. Too many one way transformations.
> Best regards, Julian
> ___
Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to pass back a
recommendations to filter the response. The data itself would still
be signed and verifiable. The recommendation itself can be secured
with TSIG/SIG(0).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma
r, it does _NOT_ say what to
> do if GOST R34.10-2001 signatures with other parameter sets are encountered.
Since each end adds the parameters and they are NOT transmitted this
can never happen. If one end was to change the parameters then nothing
would validate.
Mark
--
Mark Andrews, IS
audio stream) which made commenting hard.
Webx on the other hand was good because the presentation
material is properly synced.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: m...@isc.org
gt; policy.
>
> But even then, we are getting way ahead of ourselves. In the real
> world every network is going to have IPv4 devices on it for decades. I
> have a 36" plotter upstairs that is ten years old. I am not paying $3K
> to upgrade it just for the sake of IPv6
provide a political
> support base that ICANN desperately needs. It would also be justified
> on the basis that ICANN exists to further the development of the
> Internet and that ICANN revenues are driven by increased use of open
> Internet protocols.
>
>
> -- =
>
> New Website: http://hallambaker.com/
> View Quantum
> --
> Dave Aronson, software engineer or trainer for hire.
> Looking for job (or contract) in Washington DC area.
> See http://davearonson.com/ for resume & other info.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://ww
In message <4a544405.8020...@gmx.de>, Julian Reschke writes:
> Mark Andrews wrote:
> > I had wierd results with the following just printing out "Zone" and
> > not the rest of the lines in the table.
> >
> >
> > Zone
>
In message <200907080044.n680ir6n028...@drugs.dv.isc.org>, Mark Andrews writes:
>
> In message <4a537666.7060...@att.com>, Tony Hansen writes:
> > I also had to copy rfc2629-other.ent, rfc2629-xhtml.ent and rfc2629.dtd
> > into the current directory to get it to
does not support xml2rfc's "include" processing
> > instruction, thus external references will only work using the XML
> > entity inclusion mechanism (see <http://xml.resource.org/>, "Including
> > Files").
> >
> > BR, Julian
>
&
manufactures are not going to build equipment that can't
be used by those markets.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
are
> the most widely embedded.
>
> You may disagree with my arguments here, but you do not have the
> standing to call them 'specious'.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
__
> made, i.e., it doe snot provide the fundamental security one wants in
> DNS, i.e., an ability to verify the integrity and authenticity of
> records as attested to by authoritative domains, din the face of
> caching.
>
>
> Steve
> _
by lifting tiles. Attacks at the registry level are the
equivalient of lifting tiles. It happens sometimes. Locking the
doors and windows stops most attacks however.
> Masataka Ohta
>
> _______
>
ative name servers that I have no reason not to hang on to
> and, as needed, to propagate. Besides, it's easier this way to detect
> discrepancies between the delegation and the zone master.
>
> Cheers,
> Sabahattin
>
> __
In message , Paul Wou
ters writes:
> On Wed, 3 Jun 2009, Mark Andrews wrote:
>
> >>> You can, for example, bribe a personnel or two, against which there
> >>> is no cryptographical protection, which means PKI is weakly secure.
> >>
> >> Yo
ty Module?
HSM doesn't stop the wrong data being signed. It just stops
it being signed on machines other that the designated servers.
Mark
> Paul
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.iet
isks are is how you do risk management. If you
arn't willing to accept some risks then don't connect to the
net.
> Masataka Ohta
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 47
In message <874c02a20906010608p3e7fbdd3wa31c9ea5452a7...@mail.gmail.com>, Joe
Baptista writes:
> On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews wrote:
>
> >
> >If you believe that I have a bridge to sell you.
>
>
> Keep the bridge - it's all y
ows DNSCurve server names for the root servers, its packets
to and from those servers are protected, so it securely learns the
DNSCurve server names for .com and other top-level domains, so its
packets to and from the .com servers are protected, so it securely
learns the DNSCurve server names for ny
ively serve U.S. network infrastructure.
>
> regards
> joe baptista
>
> p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.
>
> http://dnscurve.org/
DNSCurve has exactly the same trust issues as DNSSEC does.
You are trusting the parent
better as a PKI for domain names.
Mark
> Masataka Ohta
>
> _______
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
M
be accepted.
2.
DHCP offers not being accepted due to the offer have a ttl of
1. Fault in the router.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
__
distribute those break points.
This is a little like a automated sortlist built into modern
resolvers.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
In message , John C Klensin writes:
>
>
> --On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews
> wrote:
>
> >...
> > There is no "interesting direction". I'm pretty sure customs
> > gets the same sort of search and ceasure rights
tps://www.ietf.org/mailman/listinfo/ietf
There is no "interesting direction". I'm pretty sure customs
gets the same sort of search and ceasure rights on exit and
it does on arrival. They do here in Australia.
Mark
--
Mark Andrew
vers, hosting
> http://jhvc.com
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
The message was sent to the "IETF community" for comment.
It wasn't s
In message <[EMAIL PROTECTED]>, Theodore Tso writes:
> On Tue, Dec 09, 2008 at 05:49:02PM +1100, Mark Andrews wrote:
> >
> > They didn't say why they had blacklisted that IP so there
> > is no way to determine if it was a false positive or not.
> >
error pretty hard to determine.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
od to both allow hotspot access and fully
> use DNSSEC.
>
> Paul
> _______
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +6
In message <[EMAIL PROTECTED]>, David Mo
rris writes:
> On Thu, 27 Nov 2008, Mark Andrews wrote:
> >
> > If your OS requires a reboot when you renumber get a real OS.
> > If your apps require that they restart when you renumber get
> > your apps fixed.
sive servers offered by DHCP and RAs. This should be
on for the entire week. This is what we are asking ISP's
to do and I see no reason why we shouldn't do the same.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW
going to mean a very serious
> disruption when it happens. DHCP only solves some of the problems, I am
> still effectively forced to perform a reboot, I will lose connections
> and this will cost me real time and money to fix.
If your OS requires a reboot when you renumber get a real OS.
In message <[EMAIL PROTECTED]>, Florian Weimer writes:
> * Mark Andrews:
>
> > In message <[EMAIL PROTECTED]>, Florian Weimer writes:
> >> * Stephane Bortzmeyer:
> >>
> >> > Second question, the document indeed standardizes many things
In message <[EMAIL PROTECTED]>, Florian Weimer writes:
> * Mark Andrews:
>
> >> >> The lack of a macro capability also means that it's basically
> >> >> impossible to secure DNSBL zones with DNSSEC when they contain larger
> >> &g
ability also means that it's basically
> impossible to secure DNSBL zones with DNSSEC when they contain larger
> chunks of address space; see the example in section 2.1.
How so?
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
In message <[EMAIL PROTECTED]>, Mark Andrews writes:
>
> In message <[EMAIL PROTECTED]>, Pekka Savola write
> s:
> > On Fri, 14 Nov 2008, Mark Andrews wrote:
> > >> How does an application do "accept if signed and validated by DNSSEC"?
&g
In message <[EMAIL PROTECTED]>, Pekka Savola writes:
> On Fri, 14 Nov 2008, Mark Andrews wrote:
> >> How does an application do "accept if signed and validated by DNSSEC"?
> >
> > You validate the CERT RRset using the techniques in RFC
> >
In message <[EMAIL PROTECTED]>, Pekka Savola writes:
> On Fri, 14 Nov 2008, Mark Andrews wrote:
> > In message
> > <[EMAIL PROTECTED]>, Tony F
> > inch writes:
> >> You also need the server to provide a verifiable TLS certificate.
> >> The vas
have their own validitiy period. Attempt
to retieve a new one via DNS of the on disk one doesn't
match.
Certs that are signed by private CAs are harder to deal
with as you don't have the linkage from the name to the
CA.
Mark
--
Mark
In message <[EMAIL PROTECTED]>, Dave CROCKER writes:
>
>
> Mark Andrews wrote:
> > In message <[EMAIL PROTECTED]>, Ton
> y Fi
> > nch writes:
> >> SMTP over TLS to an MX does NOT protect against man in the middle attacks.
> >
> >
In message <[EMAIL PROTECTED]>, Tony Fi
nch writes:
> On Wed, 12 Nov 2008, Mark Andrews wrote:
> >
> > It also stops the small sites being able to use cryptography to stop man
> > in the middle attacks as they are forced to insert a middle man.
> SMTP over TLS to
..
>
> /~\ The ASCII Mouse
> \ / Ribbon Campaign
> X Against HTML [EMAIL PROTECTED]
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
> ___
> Ietf mailing li
e around the damage caused by used DNSxBLs.
This makes the outbound email more fragile. It also stops
the small sites being able to use cryptography to stop man
in the middle attacks as they are forced to insert a middle
man.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dun
r the provider to provide truthful data.
The address is listed as "not supposed to be sending email".
The provider blocks port 25 outbound by default and has a
remove block support that doesn't remove the address from
the list when the port filter is rem
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enigB56BE6D16B38F294AC1B9ED5
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
>
> Mark Andrews wrote:
> >>>> It's nonsens
>
> --5me2qT3T17SWzdxI
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote:
> > > Let me be precise. The resolver treats t
;hk" is not a legal fully qualified host name. Demanding that
applications support final dots to support uses that are outside
of the original design scope is nonsensical.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australi
ied.
Mark
> But it was pretty cool. :-)
>
> --=20
> Ted Faber
> http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.=
> asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
> SIG
>
> --mvpLiMfbWzRoNl4x
> Content
>
>
> --On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> The site-dependent interpretation of the name is determined
> >> not by the presence of dot within the name but its absence
> >> from th
>
> --YD3LsXFS42OYHhNZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote:
> >=20
> > > The site-dependent interpretation
ot; and
> "hk.com" are both relative names and their resolution is resolver
> dependent.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ie
> On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote:
> > > That's at least as reliable as my (multi-dotted) home domain. :-)
> > >=20
> > > I'm not sure what's not to like here. But then again, I may be blind.
> >=20
> >
URE-
>
> --tsOsTdHNUZQcU9Ye--
>
> --===1515233305==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
> --===1515233305==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
il address, a
> single string is used without any dots." What I'm interested in is
> any reason to proscribe the use of a TLD as a single label hostname
> (particularly for email addresses) other than the fact that there is
> software out there that will interpret it
multiple times by multiple people. It's also
easily addressable by the end user.
Set browser.fixup.alternate.enabled to false in about:config.
Two wrongs don't make a right. They just make two things
that need to be fixed.
Mark
> R's,
> John
>
e future when the
conditions described are met.
Not every action has a immediate consequence. Some consequences
can happen years after the initial action was taken.
The consequences here are foreseeable but not necessarially
obvious t
ark
> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for
> Dummies
> ",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
,
> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
issued a problematic
> specification, then ICANN needs to ask the IETF to fix it, rather than to hav
> e
> ICANN, or anyone else, issue a modification/clarification.
>
> d/
>
> --
>
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> _
nic.museum.
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 5 08:22:30 2008
;; MSG SIZE rcvd: 162
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
having to delegate the name
space to the customer. TCP is a strong enough authenticator
for this role.
Mark
> - Original Message -
> From: "Bill Manning" <[EMAIL PROTECTED]>
> To: "Mark Andrews" <[EMAIL PROTECTED]>
> Cc: &qu
>
> > Mark Andrews wrote:
> >
> > > The Internet went to multi-label hostnames ~20 years ago.
> >
> > As noted in RFC 2821 as "one dot required" syntax, also
> > mentioned in RFC 3696. Recently *overruled* by 2821bis.
>
>
> Mark Andrews wrote:
>
> > The Internet went to multi-label hostnames ~20 years ago.
>
> As noted in RFC 2821 as "one dot required" syntax, also
> mentioned in RFC 3696. Recently *overruled* by 2821bis.
There is a difference between allowing protocol
s:
> http://www.postfix.org/IPV6_README.html
> 8<----
> /etc/postfix/main.cf:
> smtp_bind_address6 =3D 2001:240:587:0:250:56ff:fe89:1
> >8
> Other SMTP serve
> On Thu, Jul 03, 2008 at 09:23:58AM +1000,
> Mark Andrews <[EMAIL PROTECTED]> wrote
> a message of 32 lines which said:
>
> > No sane TLD operator can expect "http://tld"; or "[EMAIL PROTECTED]"
> > to work reliably.
>
>
t hard to auto register in the reverse DNS. TCP is usually
a strong enough authenticator to add a PTR record. 6to4
only requires a TCP connection to set up the reverse
delegation.
Mark
> Kent
>
> PS -- I'm not sure this will a
ll digits". The former was
> >certainly the IANA intent when we were discussing RFC 1591.
> >But does it apply today? Can ICANN override it? I can assure
> >you that there are groups within ICANN who believe that they can.
>
> RFC 1591 has been swept away by the c
h states that single label
hostnames/mail domains SHOULD NOT be looked up "as is" in
the DNS?
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_
isting practice of any current OS. This
will prevent users that switch OS's and use something other
than dotted decimal quad getting a match in the DNS when
the new OS is not as permissive as the old OS.
> _______
> Ietf ma
appropriate. My comments below are
> applicable to IPv6.
>
>
> On 2008-06-03 02:24, Mark Andrews wrote:
> >> Mark Andrews escribi=EF=BF=BD:
> >>>> Well, longest prefix match is kind of useful in some scenarios i thi=
> nk.
> >>>>
> >>>
> Mark Andrews escribió:
> >> Well, longest prefix match is kind of useful in some scenarios i think.
> >>
> >> Imagine a site that is multihomed to two ISPs and has two PA address block
> s.
> >>
> >> Now, longest prefix match ensures tha
when your ISP has a single prefix. For any other senario
it is biased garbage.
> Mark Andrews escribió:
> > This rule should not exist for IPv4 or IPv6. Longest match
> > does not make a good sorting critera for destination address
> > selection. In f
> On Mon, 2 Jun 2008, Mark Andrews wrote:
> > This rule should not exist for IPv4 or IPv6. Longest match
> > does not make a good sorting critera for destination address
> > selection. In fact it has the opposite effect by concentrating
> > traffic o
request today asking us to break up DNS RRsets
as a workaround to the rule.Can we please get a errata
entry for RFC 3484 stating that this rule needs to be ignored.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
g list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
It's is the only unique token on the blue sheets. This
assumes no shared email accounts which is a pretty reasonable
assumption in this case.
Mark
--
Mark Andrews, ISC
1 Seymour St.,
There was a call for me to explain this statement.
> Mark Andrews wrote:
> >
> > Also getting rid of implict MX records would "deal" with all
> > those ISP's that insist that they need to re-write NXDOMAIN
> > responses.
e ISP's that insist that they need to re-write NXDOMAIN
responses.
Mark
> --
>
>Dave Crocker
> Brandenburg InternetWorking
>bbiw.net
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymou
not my idea to reopen this issue here, it was not my
> idea to close it, and whether you think that is a lunacy on
> my side or not, various folks said that an "implicit MX" for
> IPv6 is wrong, IIRC Doug, Keith, JohnL, and JohnL. And Ned
> for some hours.
>
> Frank
>
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
>
> On 27 Mar 2008, at 20:38 , Mark Andrews wrote:
>
> >> OTOH, I think standardizing this convention makes all sorts of
> >> sense, but
> >> not, of course, in 2821bis.
> >
> > Why not in 2821bis? Is 2821bis really that time criti
> > SMTP session.
>
> OTOH, I think standardizing this convention makes all sorts of sense, but
> not, of course, in 2821bis.
Why not in 2821bis? Is 2821bis really that time critical?
> Ned
--
Mark Andrews, ISC
1 Seymour St., Du
's issue, which sparked off this latest debate, would
be addressed by codifying "MX 0 .". This would allow hosts
to say that do not accept email and any email (MAIL FROM)
claiming to come from such a domain to be dropped in the
SMTP sessio
> At 00:57 26-03-2008, Mark Andrews wrote:
> > Which is not documented in any RFC despite being a good idea.
> >
> > It is easy to turn "MX 0 ." into "This domain doesn't support
> > email" as "." is not confu
ty between
> IPv4 and IPv6 systems while considering local circumstances."
> We could look at the question by asking whether the fallback MX
> behavior should be an operational decision. But then we would be
> treating IPv4 and IPv6 differently.
>
>
_______
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
The same thing that happens today with zones that don't
have A records. You use MX records to refer to machines
that have address (A and/or ) records.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
quot; with "attendees".
>
> --
> Clint (JOATMON) Chaplin
> Principal Engineer
> Corporate Standardization (US)
> SISA
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark An
> > Reliance upon a communication system should not be
> > predicated upon such a questionable mechanisms. During the
> > next disaster, would you want FEMA to not use MX records or
> > to depend upon IPv6 address records? Not including IPv6 as
> > a discovery record would be
> At Sun, 16 Mar 2008 19:44:12 +0100,
> Iljitsch van Beijnum wrote:
> >
> > On 16 mrt 2008, at 2:16, Mark Andrews wrote:
> >
> > > Enable DNSSEC validation on the network's servers. At a
> > > minimum make them DNSSEC transparent.
> >
> On 16 mrt 2008, at 2:16, Mark Andrews wrote:
>
> > Enable DNSSEC validation on the network's servers. At a
> > minimum make them DNSSEC transparent.
>
>
> Is there any software out there for common OSes that does something
> useful with this?
Enable DNSSEC validation on the network's servers. At a
minimum make them DNSSEC transparent.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROT
ees? I'm not subscribed there and I'd
> > rather not do that (not attending IETF at all).
> >
> > Bernhard
> >
>
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Ma
Outage
> >
>
> Currently getting a 503 error from the server.
>
> --
> Cyrus Daboo
>
> _______
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews
201 - 300 of 427 matches
Mail list logo
