In article [EMAIL PROTECTED] you write:
-BEGIN PGP SIGNED MESSAGE-
Mark Andrews wrote:
The correct fix to this will be to just stop making IP6.INT
queries.
The best think that could be done is for the PTB to install
IP6.INT. DNAME IP6.ARPA. *now
In article [EMAIL PROTECTED] you write:
On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:
or just put http://www.isc.org/pubs/tn/?tn=isc-tn-2002-1.txt into effect.
I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
rvdp
RFC 3363 does NOT say that DNAME
, Mark Andrews wrote:
RFC 3363 does NOT say that DNAME is deprecated. All it says
is that since A6 was moving the exprimental using DNAME to
support renumbering is deprecated.
Which part of:
Therefore, in moving RFC 2874 to experimental,
the intent
.
Either way, this is one of those issues where everyone has an
opinion and they've all been stated before.
--
J.D. Falk be crazy dumbsaint of the mind
[EMAIL PROTECTED] -- Jack Kerouac
--
Mark Andrews, ISC
1
In article [EMAIL PROTECTED] you write:
Has anyone else noticed any strange problems lately when querying
UltraDNS for name server records?
I have a few scripts that seem to have broken in the past week. A
simple PERL script that looks up NS records from the root servers, which
worked fine
In article [EMAIL PROTECTED] you write:
VeriSign will add support for accessing the com/net zones using IPv6
transport on October 19, 2004. On that day, records for
a.gtld-servers.net and b.gtld-servers.net will be added to the root
and gtld-servers.net zones.
We do not anticipate any
dropped over it's 25 day uptime:
RPF Failures: Packets: 34889152, Bytes: 12838806927
RPF Failures: Packets: 4200, Bytes: 449923
RPF Failures: Packets: 3066337401, Bytes: 122772518288
RPF Failures: Packets: 30954487, Bytes: 3272647457
RPF Failures: Packets:
In article [EMAIL PROTECTED] you write:
You would put in a global wildcard that says no smtp sender here. Only
for those boxes being legitimate SMTP to outside senders you'd put in a
more specific record as shown above. You probably have to enter some dozen
to one hundred servers this way.
In article [EMAIL PROTECTED] you write:
On 5-jan-05, at 17:39, Sabri Berisha wrote:
Are there any common examples of the DF bit being set on non-TCP
packets?
[...]
Here you go. A root-nameserver setting the DF-bit on its replies :)
This is very bad.
With a 296 byte MTU I don't get
glue records for
the COM/NET servers.
The correct thing to do is to fix your firewall to handle the
EDNS responses.
Mark
RFC 2671: Extension Mechanisms for DNS (EDNS0)
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871
What is wrong with MTAMARK?
As currently described it doesn't fit well with RFC 2317
style delegations. They would need to be converted to use
DNAME instead of CNAME which requires all the delegating
servers to be upgraded to support DNAME.
There are
.INT.
For the forward part all the end systems just register their
new addresses in the DNS using UPDATE.
Mark.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
On Fri, Jan 14, 2005 at 10:05:05AM +1100, Mark Andrews wrote:
What is wrong with MTAMARK?
As currently described it doesn't fit well with RFC 2317
style delegations. They would need to be converted to use
DNAME instead of CNAME which requires all the delegating
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote:
Lots. I'm sure that there are lots of ISPs/IAPs on NANOG
that do RFC 2317 style delegations for their customers.
How many is lots?
Does it really matter? Even if it was only one site the problem
give away).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
harvested by address from
a nanog mailing (including the entire contents of my last mailing
to the list was a sure give away).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED
In article [EMAIL PROTECTED] you write:
From [EMAIL PROTECTED] Tue Mar 15 14:12:12 2005
Date: Tue, 15 Mar 2005 15:12:10 -0500
From: Robert Blayzor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Mike Sawicki [EMAIL PROTECTED], nanog@merit.edu
Subject: Re: Delegating /24's from a /19
[EMAIL
In article [EMAIL PROTECTED] you write:
--==D714B409A8D84E671065==
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
[EMAIL PROTECTED] wrote:
Either by doing DNS delegation on the zone boundary or
+uMqGf9ob9RfSHJFWnQCghs2K
Ltjk1dF5GCdssFNx1KiczoQ=
=Se+y
-END PGP SIGNATURE-
--==63ACF217CA8F895998F9==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
that they can just use
x.y.z.in-addr.arpa for the PTR records.
Note for reliable local reverse lookups when the external
link is down they will need to slave the ISP's x.y.z.in-addr.arpa
zone and well as manage the zone the CNAME / DNAME maps to.
Mark
--
Mark
In article [EMAIL PROTECTED] you write:
On Wed, 30 Mar 2005 22:33:49 -0800, Alexei Roudnev [EMAIL PROTECTED] wrote:
Heard of a little thing called 'spam'?
So what? You can use your car as a weapon; should we prohibit you from car
driving?
No, but if your car doesn't have seat belts, we
In article [EMAIL PROTECTED] you write:
On 4/6/2005 5:00 PM, Sean Donelan wrote:
Why does BIND forward lookups for RFC1918 addresses by default?
As has been pointed out already, caches need to be able to ask other
(local) servers for the PTRs.
OTOH, it might make a good feature (and
In article [EMAIL PROTECTED] you write:
On Fri, 29 Apr 2005, Miller, Mark wrote:
Unfortunately, a lot of static business DSL IP space is still on
those lists and legitimate mail servers can get blocked. I usually use
the DUL as a white list to negate hits on the traditional dnsbls since
In article [EMAIL PROTECTED] you write:
[In the message entitled Re: Schneier: ISPs should bear security
burden on May 1, 12:25, Jay R. Ashworth writes:]
Ok, so here's a question for your, Dave:
do you have a procedure for entertaining requests to be excluded from
your replies from people
In article [EMAIL PROTECTED] you write:
Noticied today. All Verisign's GTLD servers broke
EDNS0 (RFC2671). Here's how it looks like:
query:
$ dnsget -t mx -vv microsoft.net. -n 192.5.6.30
;; trying microsoft.net.
;; sending 42 bytes query to 192.5.6.30 port 53
;; -HEADER- opcode: QUERY,
In article [EMAIL PROTECTED] you write:
Hello all.
We have a client containing an underscore in the email address domain
name. Our email server rejects it because of it's violation of the RFC
standard. This individuals claim is that he doesn't have problems
anywhere else and if this is going to
One should note that COM and other tld's stopped giving out
domains outside of LDH to prevent these sorts of interoperability
issues. COM actually retrieved the ones they had delegated.
not being legal in hostnames to keep their names spaces
seperate from the hostname namespace.
Half the anti-spam/DNS schemes depend upon underscore not
being legal in a hostname.
Mark
Rgds,
-drc
On May 17, 2005, at 6:08 PM, Mark Andrews wrote:
RFC 952
In article [EMAIL PROTECTED] you write:
There are also mail domains to consider. They have superficially the same
syntax as host names (they cannot have a trailing dot) but they are
generally checked much more strictly for conformance to that syntax. I'm
not sure whether the original post was
In article [EMAIL PROTECTED] you write:
quote who=william(at)elan.net
Since changing SMTP2821 and waiting until everyone complies and accepts
email addresses with no . is not an option, the solutions proposed are
to either have address like [EMAIL PROTECTED] or [EMAIL PROTECTED]
The only
i
On Thu, 30 Jun 2005, Mark Andrews wrote:
No. These are just a mis-configured zones.
hangzhou.gov.cn only has glue records for the nameservers.
zpepc.com.cn has CNAMEs for the nameservers.
Both of these misconfigurations are visible to nameservers
namespace then yes.
I would have thought the Site Finder experience would have
stopped people from thinking that they can arbitarially add
names to to the public DNS.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871
In article [EMAIL PROTECTED] you write:
I just tested it from a Verizon DSL host and it worked.
You might want to consider reading RFC 2182 though, particularly the
part about geographically diverse nameservers.
Yeah, yeah, that is overrated. If my site goes dark and my DNS goes
down
In article [EMAIL PROTECTED] you write:
I just started seeing thousands of DNS queries that look like some sort
of DOS attack. One log entry is below with the IP obscured.
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
When you look at z.tn.co.za you see a huge TXT record.
Is anyone
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig8BD22DF9AD3BC6F2B19E8B12
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mark Andrews wrote:
In article [EMAIL PROTECTED] you write:
I just started seeing thousands
In article [EMAIL PROTECTED] you write:
# class ANY has no purpose in the real world, not even for debugging. if
# you see it in a query, you can assume malicious intent. if you hear it in
# a query, you can safely ignore that query, or at best, map it to class
# IN.
#
# er... i
In article [EMAIL PROTECTED] you write:
On Mon, 16 Jan 2006, Paul Vixie wrote:
[EMAIL PROTECTED] (Mark Andrews) writes:
For repeat offenders create a list of networks that won't
implement BCP 38 and collectively de-peer with them telling
them why you are de-peering and what
One of method missing is doing top down random walks of ip6.arpa.
Mark
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly
not the case. Because there are not typically NS's at every nybble level,
you have to do more
On Wed, 15 Feb 2006, Mark Andrews wrote:
One of method missing is doing top down random walks of ip6.arpa.
That's only easy if delegation were on a per-nybble basis, which is commonly
not the case. Because there are not typically NS's at every nybble level,
you have to do more
On Wed, 15 Feb 2006, Mark Andrews wrote:
I suggest that you re-read RFC 1034 and RFC 1035. A empty
node returns NOERROR. A non-existant node returns NXDOMAIN
(Name Error).
Right. This means depth-first walk, which will reduce the *possible*
address space to probe
Apologies if anyone thinks this does not require coordination or is somehow
not operational.
However, I have a situation where some nameservers for which I am=20
responsible
are receiving queries for hosts for which we are authoritative. We
return the SOA only as it seems we are supposed
Actually there can be false positive. ISP's
who put address blocks into dialup blocks
which have the qualification that the ISP is
also supposed to only do it if they *don't*
allow email from the block but the ISP's
policy explicitly allows email
Mark Andrews wrote:
Actually there can be false positive. ISP's
who put address blocks into dialup blocks
which have the qualification that the ISP is
also supposed to only do it if they *don't*
allow email from the block but the ISP's
policy explicitly
In article [EMAIL PROTECTED] you write:
On Mon, 11 Dec 2006, Simon Waters wrote:
Yes. Most of the root server traffic is answering queries with
NXDOMAIN for non-existant top level domains, if you slave root
on your recursive servers, your recursive servers can answer those
queries
In article [EMAIL PROTECTED] you write:
--==_Exmh_1166716384_12674P
Content-Type: text/plain; charset=us-ascii
On Thu, 21 Dec 2006 05:59:21 CST, Robert Bonomi said:
How many people have a search engine as their 'home page' in their web
browser?
How many end-user types _don't_know_ about
In article [EMAIL PROTECTED] you write:
On Sun, May 20, 2007 at 09:25:37PM -0700,
Roger Marquis [EMAIL PROTECTED] wrote
a message of 15 lines which said:
If not, have any root nameservers been hacked?
To partly answer my own question, no.
I cannot find the original message in my
In article [EMAIL PROTECTED] you write:
John Curran wrote:
Steve -
For the first end site that has to connect via IPv6,
it will be very bad if there is not a base of IPv6
web/email sites already in place.
As the network administrator for a Web hosting company, I've not seen
Barrett Lyon wrote:
=20
Apparently GoDaddy does not support v6 glue for their customers, who
does? I don't think requiring dual-stack v6 users perform v4 queries t=
o
find records is all that great.
At least eNom does.
There are a few others but it tends to be that you have to raise a
In article [EMAIL PROTECTED] you write:
I've read your email twice and I dont follow.
Either you are telling me
a) Provide my own hints with included (you specifically say thats not
what you mean tho)
or
b) Serve my own root zone. From a root operator, surely thats not right either
In article [EMAIL PROTECTED] you write:
http://www.pcworld.com/article/id,134159-c,internetlegalissues/article.html
Note that this is based on their interpretation of EU law.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
The court has confirmed that the ISPs have both a
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits that
were UDP only which totally busted the myth but it continues
to live.
In article [EMAIL PROTECTED] you write:
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits that
were UDP only which totally busted the myth but it
On 8/9/2007 at 10:07 PM, Mark Andrews [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits
This comment was added as a follow-on note. Sorry for not being clear.
Accepting messages from a domain lacking MX records might be risky
due to the high rate of domain turnovers. Within a few weeks, more
than the number of existing domains will have been added and deleted
by then.
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
Accepting messages from a domain lacking MX records might be risky
due to the high rate of domain turnovers. Within a few weeks,
more than the number of existing domains will have been added and
deleted by then. Spammers
On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
Since all valid email domains are required to have a working
postmaster you can safely drop any email from such domains.
Use of root . as a name for a target may create
On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:
Yes, and this convention still generates nuisance root traffic
whenever the application fails to comprehend . is a special
target. This is true even when _defined_ as a special target for
the specific resource record
In article [EMAIL PROTECTED] you write:
Tuc at T-B-O-H.NET wrote:
Down is there isn't power to it until it gets repaired. So its not
answering period. A nslookup shows timed-out. A dig shows
connection timed out; no servers could be reached (When querying ONLY
against the down
In article [EMAIL PROTECTED] you write:
On 9/15/07, Jeroen Massar [EMAIL PROTECTED] wrote:
[spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)]
Somewhat long, hopefully useful content follows...
Barrett Lyon wrote:
[..]
[ clip ]
Of course when there is only a A or
In article [EMAIL PROTECTED] you write:
Iljitsch van Beijnum wrote:
That isn't actually true. I could move to IPv6 and deploy a NAT-PT
box to give my customers access to the v4 Internet regardless of
whatever the rest of the community thinks.
And then you'll see your active FTP sessions,
In article [EMAIL PROTECTED] you write:
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select
In article [EMAIL PROTECTED] you write:
On 10/15/07, Mark Andrews [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
The correct way to change a delegation is to:
* add the new servers as stealth servers for the
current zone.
* if the old master is to be removed, make it a slave
of the new master.
* add the new NS records to the zone.
* wait for all
In article [EMAIL PROTECTED] you write:
On Sun, 4 Nov 2007 11:52:11 -0500 (EST)
Sean Donelan [EMAIL PROTECTED] wrote:
I just wish the IETF would acknowledge this and go ahead and define a
DNS bit for artificial DNS answers for all these address correction and
domain parking and domain
Mark,
On Nov 5, 2007, at 5:31 PM, Mark Andrews wrote:
All you have to do is move the validation to a machine you
control to detect this garbage.
You probably don't need to bother with DNSSEC validation to stop the
Verizon redirection. All you need do is run a caching
I think we got here when site-local went away - we've effectively
redefined link-local to mean site-local, while using globally unique
addressing.
site-local was replaced with ULA. Have you got your ULA yet? :-)
ULA gives you /48's.
6to4 gives you /48's.
Your
In article [EMAIL PROTECTED] you write:
I'd rather push for /48 and have people settle on /56 than push for=20
/56 and have people settle on /64.
=20
Again, why the hang-up on 8 bit boundaries?
Look, why are we arguing about this? Why not split
the difference? If /48 is too big and /64 is
In article [EMAIL PROTECTED] you write:
On Jan 14, 2008 5:08 PM, Tony Finch [EMAIL PROTECTED] wrote:
the . convention then it will look up the root's and A records,
which is stupid but should cause the message to bounce as desired. However
if it does implement the convention (just like
they are configured as final delivery agents for and if not
found log that there are missing MX records.
Mark
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
randy
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In article [EMAIL PROTECTED] you write:
On 4-Feb-2008, at 16:05, Iljitsch van Beijnum wrote:
And the new named.root has arrived:
ftp://rs.internic.net/domain/named.root
I seem to think it has become fairly widespread practice for people to
refresh their named.root files (or whatever they
.
This will only affect users that have deliberately overridden
the responses returned by the root servers.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
In article [EMAIL PROTECTED] you write:
On Feb 5, 2008 2:10 AM, Pekka Savola [EMAIL PROTECTED] wrote:
On Mon, 4 Feb 2008, Leo Bicknell wrote:
may try dig any . @[a-m].root-servers.net.
When I do that, I get the following response:
a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3
On Feb 6, 2008 12:11 AM, Mark Andrews [EMAIL PROTECTED] wrote:
(from me)
How does a cache-resolver know that it's time to issue a query with edns0?
cache-resolver that support EDNS0 will make EDNS0 queries
by default. They will fallback to plain DNS if the query
--Apple-Mail-32-671463028
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote:
IPv6 capable nameservers are supposed to use EDNS (see IPv6
node
75 matches
Mail list logo
