s. This is the syntax used by programming
> languages like C and perl. For example, ASCII ESC (0x1b) is represented as
> \033, not \027.
The C convention also has \t, \r, \f, \n none of which are
the special in domain labels.
We are not trying to change convention
for
> DNSSEC (at least I would argue that they should require DNSSEC support).
>
>
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
--
Mark Andrews, ISC
1 Seymour St., Dundas
INE network configuration alone. The
> use of DHCP discovered DNS servers is a major security hazzard. All DNS
> transactions should be TSIG signed.
>
> I will accept the use of DHCP to assist initial machine configuration
> and local network configuration. Use of an unaut
so renumbering will be
> viewed by many as a non-starter.)
>
> -teg
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTE
ts of its IPv6 address when using stateless autoconfig.
You also don't want to do it as you would also need massive churn in
the DNS.
Microsoft gets this wrong as they don't register the privacy addresses
in the DNS which in turn causes services to be blocked because there
Can't you set your MUA to emit TEXT/PLAIN? It's just
plain impolite to send only HTM ~!#!~!#$~ L.
>
>
>
>
>
>
> Mark Andrews wrote :
> type="cite">
>
> On 19 feb 2008, at 10:02, Dan Wing wrote:
>
>
0.11
Note: Firefox has a root cert from them. Just not the one
that signed this cert.
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
http://www.ietf.org/mailman/listinfo/ietf
fore 2929bis? (It would be a bad idea,
> IMHO, to tell people they must use a new RR type, before the new
> procedure for doing so is ready.)
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark An
> On Wed, Mar 05, 2008 at 12:52:05AM +1100,
> Mark Andrews <[EMAIL PROTECTED]> wrote
> a message of 94 lines which said:
>
> > So you want to hold up everything because one company
> > produced a API that was not RFC 1123 compliant?
>
> Read my
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
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
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
> 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?
> 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.
> >
> > 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
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
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
_______
> 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
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.
>
>
> 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
'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
> > 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
>
> 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
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
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
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.
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.,
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
> 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
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
> 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
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.
> >>>>
> >>>
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
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]
_
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
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
> 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.
>
>
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
> 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
>
> > 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.
>
>
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
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
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
> _
,
> 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
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
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
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
>
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
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
> 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
> >
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
>
> --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
>
>
> --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
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
;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
>
> --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
> 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
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
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
..
>
> /~\ 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
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
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.
> >
> >
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]>, 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
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]>, 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
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]>, 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
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
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.
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
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.
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
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
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.
> >
PGP SIGNATURE-
>
> --enigCADC6924BAD7521CFFC2A32E--
>
>
> --===1336328525==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing
that you didn't need to do
that because it provide a *single* namespace from a *single*
set of servers and you didn't have to graft on hundreds of
TLDs.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Austra
munications within Sri
Lanka would have had a much better chance of just continuing
to work for the time it took to fix the cables. It wouldn't
have been perfect but it would have helped.
Mark
> _______
> Iet
ion for the DNS.
> I recommend ABNF be used to detail the syntax
> of each of these fields and that the I-D detail
> how values of these fields are to be compared.
> Additionally, the I-D should discuss how IDNs
> are to be handled.
> -- Kurt
* Hostnames
>
> On 3/7/2006 8:16 PM, Mark Andrews wrote:
>
> > * Hostnames that are 254 and 255 characters long cannot be
> > expressed in the DNS.
>
> Actually hostnames are technically defined with a maximum of 63 characters
> in total [RFC1123], and there have bee
need no more
> than one /64 each to service those networks.
Well I see cell phones as routers for the on body IPv6 bluetooth
network.
I see cell phones as routers for your laptop.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:
it in the marketplace.
>
> How? I haven't been able to pressure or shame my ISP into setting
> rDNS correctly for my IP address. In fact, nobody at my ISP knows
> what that means.
>
>
>
> ___
> Ietf mailing list
> Ie
> Mark Andrews writes:
>
> > Which was why IPv6 when to 128 bits rather than 64 bits.
>
> That won't help. It will add perhaps 25% to the lifetime of the
> address space, no more.
>
> > 64 bits of address space would have been fine to give
> > everyon
nd if you
do the right thing choosing your prefix then you can usually
connect multiple sites together without having to renumber
one of them.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL
used for NSEC3 as it
preserves the sort order.
> Having LGPL code in the draft will no doubt cause concerns for some people -
> given the simplicity in understanding this algorithm and wide availability
> of working code, does having this code here really improve the
> specificatio
> On 4/10/06 4:31 PM, "Mark Andrews" <[EMAIL PROTECTED]> wrote:
>
> >> Did the base32 extended hex version get used in the SASL work? Can we upda
> te
> >> the reference or if it is not needed not just remove it.
> >
> > base32 extended he
; eeps the Internet together.
>
> My theory (which I make no appologies for acting on) is that Vint Cerf and Jo
> n Postel intended the mechanisms set up to control and allocate to act as the
> Gordian knot.
>
> ___
> Ietf mailing
directed broadcast addresses. Modern routers can be
configured to drop directed broadcast packets. The need
to block ICMP has long gone. All it does is make debugging
the network harder.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:
; _______
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP. Email [EMAIL PROTECTED]
--
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://www1.ietf.org/mailman/listinfo/ietf
___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP. Email [EMAIL PROTECTED]
--
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP. Email [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Du
cimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
This implies that entering a address query for #.#.#.# will
NOT return a RRset.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
>
>
> Joe
The documents are essentially the same. In particular the
policy to resolve the handling of multiple dlv namespaces
which overlap is the same. This was not so in earlier
versions.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Vall
--On Tuesday, 31 October, 2006 08:42 +1100 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> > The documents are essentially the same. In particular the
> > policy to resolve the handling of multiple dlv namespaces
> > which overlap is the same. This was n
compression could be used was flawed.
I really don't know why we are arguing about this anymore.
Adding new RR's has not been a real issue this millenia.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9
the binary blobs.
> (of course there are lots of other reasons to look for a replacement for
> DNS even if the new RR type problem is solved, but that doesn't mean the
> new RR type problem shouldn't be solved)
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley,
clouded your judgement.
> FACTS are not FUD. In this case the facts are in the code.
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.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://www1.ietf.org/mailman/listinfo/ietf
g they usually address the issue.
The non conformance with RFC 103[45] usually takes the form
of dropping packets the server doesn't know how to handle
rather than returning a error code.
Note: in general EDNS0 just works.
Mark
--
Mark Andrews, ISC
1
7;m very wary of this recommendation.
--
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://www1.ietf.org/mailman/listinfo/ietf
1 - 100 of 427 matches
Mail list logo
