Re: Repotting report

[Mark Andrews]

> 
> --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 requirements).  The roots can be tuned to preference
> > A vs  records.  Most/all currently maintained caching
> > servers support EDNS now or the next release will support
> > EDNS.
> 
> So would there be benefit in the roots being tuned to only return  
>  if the request is EDNS?

No.
 
> Just out of curiousity that is.
> --Apple-Mail-32-671463028
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/html;
>   charset=ISO-8859-1
> 
>  -webkit-line-break: after-white-space; ">
> On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote: class=3D"Apple-interchange-newline"> style=3D"margin: 0.0px 0.0px 0.0px 0.0px"> size=3D"3" style=3D"font: 12.0px Helvetica">  style=3D"white-space:pre">   IPv6 capable nameservers are =
> supposed to use EDNS (see IPv6  0.0px 0.0px 0.0px"> 12.0px Helvetica"> style=3D"white-space:pre">node requirements). class=3D"Apple-converted-space">=A0 The roots can be tuned to =
> preference  face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"> class=3D"Apple-tab-span" style=3D"white-space:pre">   A vs  =
> records.=A0 Most/all =
> currently maintained caching  0.0px 0.0px"> Helvetica">  =
> servers support EDNS now or the next release will =
> support  face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"> class=3D"Apple-tab-span" style=3D"white-space:pre">   =
> EDNS. So would there be =
> benefit in the roots being tuned to only return  if the request is =
> EDNS?Just =
> out of curiousity that is.=
> 
> --Apple-Mail-32-671463028--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Repotting report

[Mark Andrews]

> 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
> > fails or they get a response that indicated the authoritative
> > server doesn't support EDNS.
> >
> > BIND's been making EDNS0 queries for ~8 years now. If your
> > cache-resolver doesn't support EDNS it is long past time to
> > upgrade.
> >
> 
> excellent, thanks! (as always). Any thoughts on the possible lack of
> resilence from losing 9 server names/ips in the v4 to v6 move? (and I
> realize that later most/all root boxes will have both addresses)

It won't be a issue.

IPv6 capable nameservers are supposed to use EDNS (see IPv6
node requirements).  The roots can be tuned to preference
A vs  records.  Most/all currently maintained caching
servers support EDNS now or the next release will support
EDNS.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Repotting report

[Mark Andrews]

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 's (the first 3).
>> > b, h, l, k, and m return 1 SOA, 13 A, no  records.
>> >
>> > If you make this mistake you might think b, h, l, k and m have no
>> > IPv6 data, which is wrong.  Querying with NS (as nameserver would
>> > do) clearly shows that.
>> >
>> > While a cosmetic problem, I fear it may confuse a number of admins
>> > as the troubleshoot problems in the near future.
>>
>> It certainly will.  Section 1.4 of RFC 4472 may be helpful here,
>> though it mainly talks about this from the viewpoint of caching, not
>> root servers.
>
>So, how will this sort of thing affect traffic levels to the servers
>in question? Will this affect stability on a v6only or v4-limited
>site/network? (13 v4 servers, 4 v6 servers...)
>
>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
fails or they get a response that indicated the authoritative
server doesn't support EDNS.

BIND's been making EDNS0 queries for ~8 years now. If your
cache-resolver doesn't support EDNS it is long past time to
upgrade.

Mark

>Having inconsistent information seems like it might cause more than
>just troubleshooting headaches...
>
>-Chris

F.ROOT-SERVERS.NET IPv6 address has changed.

[Mark Andrews]

With the official deployment of IPv6 addresses for the
root servers, F.ROOT-SERVERS.NET IPv6 address changed.

The old address, 2001:500::1035, is no longer valid and
will be turn off at some point.  The new address is
2001:500:2f::f.

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]

Re: Repotting report

[Mark Andrews]

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 decide to call it)  
>using something like this:
>
>$ dig . NS >named.root
>
>This worked before today. From today, it still works (in the sense  
>that it will still result in a named.root file which is sufficiently  
>complete in most situations for a nameserver to be able to send a  
>priming query) but it won't contain a complete set of glue.
>
>So, if you're in the habit of doing
>
>   dig . NS >named.root
>
>you would ideally change that habit to something like
>
>   curl -O ftp://rs.internic.net/domain/named.root

Why?  dig is quite capable of coping.

Depending apon dig's age and firewall configuration one or
more of these will work.

dig +edns=0 . NS @a.root-servers.net > named.root
dig +bufsize=1200 . NS @a.root-servers.net > named.root
dig +vc . NS @a.root-servers.net > named.root

As none of these sets DO, they should suffice for the
foreseeable future.

When DNSSEC is deployed for the root and root-servers.net
you will want to do crypto checks.  Even then the above
queries won't break.

Mark

>instead. (Incidentally, for me, rs.internic.net is giving "530 Login  
>incorrect" after PASS when logging in using "ftp" 
>
>
>Joe

Re: houston.rr.com MX fubar?

[Mark Andrews]

> > Fallback to A should be removed sure sounds like a plan.
> 
> great idea.  it will only break mail to 42% of the internet.

Since there is no fallback to , in a few years it will
break very little as most of the internet will have IPv6
MTA's (and hence MX's) for their mail domains.

MX fallback to A should have had a sunset time added to it
when it was originally proposed.  It is, after all, only a
transition strategy.  We can still add a sunset clause.

MTA's would lookup their own MX records for the mail domains
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 INTERNET: [EMAIL PROTECTED]

Re: houston.rr.com MX fubar?

[Mark Andrews]

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 the "usage rules" for a SRV
>> record target of "." in RFC 2782) then it can skip the address lookups and
>> save the root some work. (It can also produce a better error message.)
>> This really ought to be explained in draft-delany-nullmx.
>
>The draft died.  And I think this stuff about looking up A /  for
>the root was certainly raised in the IETF sometime back.  Not that
>there isnt enough junk traffic (and DDoS etc) coming the roots' way
>that this kind of single lookup would get lost in the general noise ..
>
>Might want to revive it and take it forward?  I rather liked that
>draft (and Mark Delany cites me in the acknowledgements as I suggested
>a few wording changes for the definition of a null MX - dot terminated
>null string, STD13 etc, during his drafting of the document)
>
>--srs
>
>-- 
>Suresh Ramasubramanian ([EMAIL PROTECTED])

There are lots of places in the DNS where "." makes sense
as a null indicator.  RP uses it today, as does SRV.  MX
should use it and fallback to A should be removed.  It
actually takes more cache space to record that a MX record
does not exist than it takes to record that a A or 
record exists (SOA rdata is atleast 22 octets).

draft-ietf-dnsop-default-local-zones used it for SOA RNAME
but was changed under WG pressure.

A and  should use 0.0.0.0 and :: to indicate that a host
exists but is not currently connected.

Mark

Re: Assigning IPv6 /48's to CPE's?

[Mark Andrews]

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 too small,
>let's go halfway and use /56, OK?
>
>This has the advantage that it is on a 4 bit nibble=20
>boundary which makes it the boundary between network
>and interface much clearer in writing
>2001:3ff3:effe:1200::0/56=20
>If you wrote 2001:3ff3:effe:12a0::0/56 then I would=20
>immediately see that there are too many bits in the network
>portion. It also avoids a messy situation with reverse
>DNS delegations.

And /48 is easier still.

2001:3ff3:effe:1234::::
<--ASSIGNED-->::<--auto--->

>In the end, the decision had to be made to but the boundary
>somewhere, and with 16 bits to be divided plus the need to
>use 4-bit boundaries, the choices were (4,12), (8,8), and
>(12,4). Split the difference was the least objectionable.
>
>ARIN's decision on this boundary point has since been accepted
>by two other RIRs, so it seems to be community consensus now.
>
>--Michael Dillon

Re: v6 subnet size for DSL & leased line customers

[Mark Andrews]

>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 customers already have /48's whether they know it or not
(and some do).

Mark

Re: Hey, SiteFinder is back, again...

[Mark Andrews]

> 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 server.

Yep.
 
> > dnssec-enable yes;
> > dnssec-validation yes;
> > forward only;
> > forwarders { ; };
> 
> Why bother forwarding?

It was just to prove that you could detect this coming out
of a ISP's servers.
 
> > dnssec-lookaside . trust-anchor ;
> 
> You forgot the bit where everybody you want to do a DNS lookup on  
> signs (and maintains) their zones and trusts and registers with  registry> (of which there is exactly one that I know of and that one  
> has 17 entries in it the last I looked).   You also didn't mention  
> that everyone doing this will reference the DLV registry on every non- 
> cached lookup.  Puts a _lot_ of trust (both security wise and  
> operationally) in ...

There are also other lists of trust anchors.

With 17 entries there arn't a lot of queries that need to
be made to have the entire name space covered by cached
NSEC records which DLV will use.
 
> > All lookups which Verizon has interfered with from signed zones
> > will fail.
> 
> Yeah, and Verizon customers would get a timeout (after how long?)  
> instead of a more quickly returned A (or maybe a ) RR to a  
> Verizon controlled search engine.  Not really sure the cure is better  
> than the disease.

But then you can log a complaint that DNSSEC doesn't work
using their caching resolvers.  Or this just gives you
the heads up to find the web form to change the servers
returned by DHCP.  There is contributed code to do this
linkage for BIND.  Or to manually update the forwarders.

i.e. it's useful for those who use ISP's that havn't yet
gone over to the dark side. :-)

> Also not sure what the point is -- most common  
> typos are already squatted upon and validly registered to a adsense  
> pay-per-click web page, typically a search engine (e.g.,  
> www.baknofamerica.com).  Seems to me the slimeballs have won yet  
> again...

That's a different issue on a different battle front.
 
Mark

> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Hey, SiteFinder is back, again...

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On Nov 5, 2007, at 8:23 AM, David Lesher wrote:
>> What affect will Allegedly Secure DNS have on such provider
>> hijackings, both of DNS and crammed-in content?
>
>If what Verizon is doing is rewriting NXDOMAIN at their caching  
>servers, DNSSEC will _not_ help.  Caching servers do the validation  
>and the insertion of the search engine IP addresses in the response  
>would occur after the validation.
>
>Regards,
>-drc
>

All you have to do is move the validation to a machine you
control to detect this garbage. 

dnssec-enable yes;
dnssec-validation yes;
forward only;
forwarders { ; };
dnssec-lookaside . trust-anchor ;

All lookups which Verizon has interfered with from signed zones
will fail.

Mark

Re: Hey, SiteFinder is back, again...

[Mark Andrews]

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 tasting" people to use for their keen
>> "Web 2.0" ideas.
>
>Yes, let's let the IETF go off for 7 years to debate and try to put
>into an RFC something else that won't actually be used.  Sorry Sean,
>you've lost me on this one.  :-)
>
>John

You already have the bits for SE (and other signed
infrastructure zones) that allow you to detect when this
sort of garbage is pulled.  All you have to do is deploy
a DNSSEC aware resolver.

Mark

Re: dns authority changes and lame servers

[Mark Andrews]

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 the slaves to have the new zone.
* inform the parent zone of the new NS records.
* wait until all the old NS RRsets have expired from
  caches (implies waiting for the parent's changes to propagate).
* remove the old NS records from the zone.
* wait for all the slaves to update.
* inform the parent zone of the new NS records.
* wait until all the intermediate NS RRsets have expired from
  caches (implies waiting for the parent's changes to propagate).
* any slaves that are not being remove and that are still
  using the old master (or slave that is going away) need
  to be configured to use the new master by this point.
* stop serving the zone on the old servers.

Note: all through this process the namesevers listed in the
NS records are answering for the zone in a consistant manner.

Note: even if the parents informed you that the delegation
was removed you still have to wait for the records to expire
from caches *before* you can stop serving the zone.

One can collapse the above slightly by informing the parent
of the final NS RRset, rather than the intermediate NS
RRset, but that won't work with registrars that check the
childs NS RRset.

One way to get around this would be to charge a cleanup fee
that only gets charged when the client fails to notify you
in advance that they are going change delegations.

Mark

Re: Geographic map of IPv6 availability

[Mark Andrews]

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
>> >> was that the resolver behavior was being discussed. Not the client.
>> >> The resolver should have an attribute to select the preference between
>> >> A vs. . Otherwise, it's setting network policy through code.
>> >>
>> >> My question was if there is an option to adjust this, where is it? I
>> >> don't see it. I'm not a BIND uber-expert. If there is no option, there
>> >> quite possibly ought to be one.
>> >
>> >I guess the question could also be asked as to whether BIND honours
>> >the host's configuration of the address selection policy - which
>> >seems more likely than implementing it itself.
>> >
>> >For those who missed it - OS level address selection policy won't
>> >apply to BIND without specific code, as BIND is a recursive resolver
>> >so won't be calling getaddrinfo(3).
>> >
>> >--
>> >Nathan Ward
>>
>> named actually measures the response times to individual addresses
>> and uses those to determine which servers to query.  Named also
>> uses what addresses it has before attempting to determine if there
>> are alternate addresses.
>>
>> Address selection policies are kind of meaningless in this environment.
>
>How so? I think it's valuable to be able to decide for myself if I
>want preference for  or A. If I understand what I am reading, and
>am properly recalling past threads here, this would seem important
>since it affects the user experience.
>
>As far as how it sets network policy goes, any time something sets a
>preferred mode over other options and is not modifiable, it's akin to
>setting policy. History has shown that most of us agree with this.
>
>If I'm not interpreting this correctly, I'm all ears (eyes).
>
>[ Note, I'm not making any assumption that anyone has set out to set
>internet policy through software. ]
>
>-M<

getaddrinfo() is based on the assumption that there is *not*
a cache response times etc.  named builds such a cache.  To
do that however it needs to actually query the addresses.
It also has to have all the addresses to make that
determination.

Named works with partial information rather than going out
and fetching complete information then making the query.
Doing that would slow down the resolution process.

Most applictions also make exactly one connection and making
sure that is optimal is useful.  Named makes millions of
connections.  It's a completely different class of application.

Named is also pretty much agnostic about whether IPv4 or
IPv6 transport is used.  At the moment it still tends to
be IPv4 as there is very little  glue even when there
are  records for the nameserver.

Mark

Re: Geographic map of IPv6 availability

[Mark Andrews]

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 the preference between
>> A vs. . Otherwise, it's setting network policy through code.
>>
>> My question was if there is an option to adjust this, where is it? I
>> don't see it. I'm not a BIND uber-expert. If there is no option, there
>> quite possibly ought to be one.
>
>I guess the question could also be asked as to whether BIND honours  
>the host's configuration of the address selection policy - which  
>seems more likely than implementing it itself.
>
>For those who missed it - OS level address selection policy won't  
>apply to BIND without specific code, as BIND is a recursive resolver  
>so won't be calling getaddrinfo(3).
>
>--
>Nathan Ward

named actually measures the response times to individual addresses
and uses those to determine which servers to query.  Named also
uses what addresses it has before attempting to determine if there
are alternate addresses.

Address selection policies are kind of meaningless in this environment.

But what really trumps all of these is getting rid of firewalls
that don't handle EDNS queries.  These along with nameservers that
fail to respond to EDNS queries slow up the resolution process much
more than picking a sub-optimal addresses to query.

Mark

Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action:

[Mark Andrews]

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, SIP calls, RTSP
>> sessions, etc fail.
>
>Somehow we made it work for v4.  How did that happen?

The problem is that NAT constrains the solution space available to
application developers.  I have no problem with PT-NAT to get to
IPv4 because the IPv4 space is already constrained by the existing
use of NAT.  Most/many of the existing applications have been
crippled by the existance of NAT.

Almost no-one attempts to run the passive side (server) of a
connection behind a NAT.  With PAT try running more services that
use the same port than you have public addresses.  It just won't
work.  Similarly double or tripple NAT further reduce the application
space that works.

Even hotels realise NAT is bad.  Have you notice that you now get
asked if you can live behind the NAT or do you need a public address
when you register?

I work from behind a NAT as I work from home.  There have been lots
of things that should have been simple, but wern't, as that NAT was
there.  Something just didn't work because I couldn't find a ALG
for that protocol.

I have a big problem with pulling those constraints into IPv6.

Without NAT I can, if needed, open up a complete address in the
firewall to work around lack if a ALG.  I don't get that choice
with NAT.

Mark

Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

[Mark Andrews]

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  only that protocol will be
>> used. All applications are supposed to use getaddrinfo() which sorts
>> these addresses per the above specification, the app should then
>> connect() to them in order, fail/timeout and try the next one till it
>
>Since when is a timeout on the Internet ok?  Haven't we moved beyond
>that?

You mean to say you get 100% connectivity with IPv4?

> This is a controllable timeout. We don't have to do it, which is
> the point. What's the right way to do this?
>
> Thank you, and thank you Barret for starting the thread. :-)
>
>-M<

I've been running dual stacked for 5 years with a trans
pacific tunnel to HE (10 hops).  While there have been the
occasional glitch I don't see much difference between IPv4
and IPv6.

Work has also been running dual stacked.  I very rarely fall
back to IPv4, and given my usage patterns I do notice when
IPv6 connectivity fails.

Looping through the addresses as returned by getaddrinfo is
a reasonable strategy.

Mark

Re: Do I or RR need dns clue?

[Mark Andrews]

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 server).
>> > 
>> >So how do I go back to RR, who told me to take it out of my 
>> > NS records, that DNS is supposed to be silently falling back and trying
>> > again? 
>> 
>> 
>> The fact that they're rejecting on a 5xx error based on no DNS PTR is a
>> bit harsh.  While I'm all for requiring all hosts to have valid PTR
>> records, there are times when transient or problem servers can cause a
>> DNS lookup failure or miss, etc.  If anything they should be returning a
>> 4xx to have the remote host"try again later".
>> 
>Robert,
>
>   Sorry, they aren't giving a hard fail. Its a soft fail, so we'll 
>retry. But after 5 days of retrying, my servers will give up. (And, in
>the mean time, the mail isn't getting through, so my users are without mail
>{We store/forward for them} I don't know if the down (hard) server will be 
>back that soon (Its been 2 days as is). But the whole POINT of DNS is I have 
>a 2nd one listed, and they don't seem to care. They are telling me that they 
>want my "primary" one back up and running.
>
>   Tuc/TBOH

I know this is strange for nanog but if you actually stated the
IP addresses of the mail servers we could look to see if there
is a problem other than what you think the problem is.

You havn't stated it here or on bind-users

Mark

Re: Discovering policy

[Mark Andrews]

> 
> 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, as with SRV.  In the case of an MX  
> >> record, there is _no_ such definition.
> >
> > So we write a RFC.  That I though was implicit.
> 
> Do not depend upon applications not to resolve addresses for root  
> names, even when a convention is explicit.  Depending upon root  
> answers to support a protocol feature unrelated to DNS is normally  
> considered a design mistake isn't it?

No.  The root must exist.  To many things break when there
is no root.
 
> > If you have applications which don't honour SRV's "." processing  
> > rules report the bug.
> 
> Even Paul Vixie, the author, will likely agree the RFC has the "bug".

No, it's the implementations that have the bug.

If you want really scary "A 0.0.0.0" to indicate that you are
offline but exist.  This is actually using 0.0.0.0 as it was
intended. i.e. I exist but I do not know my address.

> >> Not having an SMTP server and no MX record provides a clear  
> >> indication of a policy "I don't want email."
> >
> > Which requires a SMTP server to attempt the TCP connection.  It  
> > also requires the SMTP server to re-try until it times out the  
> > messages which could be days.
> 
> Who would be motivated in making the change?  Trying every address  
> record is unsuitable for today's email environment.  Its time for a  
> change.

I suspect the SMTP vendors would pick it up reasonably quickly.

I suspect everyone that uses "MX 0 nonexistant" today would
pick it up.

I suspect everyone has a SPF record indicating they don't
send email would pick it up.  They don't want the bounce
traffic.

It's usable by sites with idiotic resolver libraries that
can't return unknown record types.

> > SPF is optional.  MX processing is NOT optional.
> 
> MX records should not optional, but they are.

I said MX processing.  You *have* to do the lookup.
 
> > Most SMTP client will fail immediately if they get a positive  
> > indication that there are no address records for the MX.  Fixing  
> > them not to ask the question is a optimisation.
> 
> Publishing wildcard MX root records everywhere represents a poor and  
> possibly hazardous solution.
> 
> >> Policy will often require a greater amount of information.
> >
> > This is a simple binary decision.  I want email for this domain or  
> > not.
> 
> A policy may need to express whether the domain signs some or all of  
> their outbound messages.  Not very binary is it?
> 
> >> To discovery policy must the entire domain be queried?
> >
> > You have the name.  It has a address.  You don't want email to be  
> > sent there.  You add a single MX record next to the address. No  
> > seaching.  Just direct query.
> 
> Policy is not normally published for inbound traffic.  SMTP  
> extensions negotiate inbound policy requirements.  However, policy  
> could be essential for outbound traffic.  A domain name might be the  
> subject of phishing attacks.  How policy is applied must ensure even  
> sub-domains are covered.
> 
> A safe strategy for applying an outbound message policy is to:
> 
> - check whether there is a discovery (MX) record
> 
> - no discovery record, refuse the message

If there is a "MX 0 ." record, refuse the message
 
> - check whether a policy record is adjacent to the discovery record
> 
> - no policy record, there is no policy
> 
> >> A wildcard MX record and root name convention exposes a domain to  
> >> an SPF script attack, where a different convention is expected for  
> >> no email.
> >
> > No the presence of the record with "." as the MX target would stop  
> > all further processing.
> 
> The SPF script processing is looking for address matches, which may  
> or may not include those within the MX record.  SPF libraries might  
> not quit after hundreds of no answers.  This behavior is just one of  
> the reasons these libraries are hazardous.  Remember an outbound path  
> may not be the same as the inbound.
> 
> > You don't go to SPF processing as the source address is non repliable.
> 
> When the originating domain fails 

Re: Discovering policy

[Mark Andrews]

> 
> 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 undesired non- 
> >> cached traffic when applications unaware of this convention then  
> >> attempt to resolve an address for servers named root.
> >
> >  All modern iterative resolvers are required to support negative  
> > caching.
> 
> Indeed, RFC 2308 changed negative caching support from optional for  
> any caching resolver.  Those that have negative caching may  
> significantly truncate the duration.  There are several websites  
> recommending negative caching be disabled to permit faster recovery  
> from intermittent negative answers.  In other words, a negative  
> answer is less likely to have been cached.  Use of root target names  
> will impact roots in cases where:
> 
> - an assumption of negative caching is wrong,
> - for MX records where the root name convention is not in place.
> 
> With email, transaction rates are high and highly distributed which  
> tends to diminish negative caching protections.
> 
> >> The use of root as a convention will complicate a general strategy  
> >> identifying adoption of a protocol by publication of a discovery  
> >> record.  The use of root as a target name in SRV records has been  
> >> problematic, although this convention was defined for SRV records  
> >> at the outset.
> >
> >> Using an MX record to mean "no email is accepted" by naming the  
> >> target 'root' changes the meaning of the MX record.
> >
> >  Not really.  It's entirely consistant with existing DNS usage  
> > where "." is a domain name / hostname place holder.
> >
> >  Lots of RR types use "." to indicate non-existance.
> 
> 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, as with SRV.  In the case of an MX record,  
> there is _no_ such definition.

So we write a RFC.  That I though was implicit.

If you have applications which don't honour SRV's "."
processing rules report the bug.
 
> >> It is also not clear whether the root target would mean "no email  
> >> is sent" as well.
> >
> > That is, I'll agree, more of a issue but no one can reasonably  
> > expect people to accept non-repliable email.
> 
> That would have been made clear by simply requiring MX records for  
> acceptance!
> 
> >> A clearer and safer strategy would be to insist that anyone who  
> >> cares about their email delivery, publish a valid MX record.   
> >> Especially when the domain is that of a government agency dealing  
> >> with emergencies.  At least FEMA now publishes an MX record.  This  
> >> requirement should have been imposed long ago. : )
> >
> > I much prefer positive data vs the absence of data to make a  
> > decision.  "MX 0 ." is a definitive response saying you don't want  
> > email.
> 
> Not having an SMTP server and no MX record provides a clear  
> indication of a policy "I don't want email."

Which requires a SMTP server to attempt the TCP connection.
It also requires the SMTP server to re-try until it times
out the messages which could be days.

SPF is optional.  MX processing is NOT optional.

Most SMTP client will fail immediately if they get a
positive indication that there are no address records
for the MX.  Fixing them not to ask the question is
a optimisation.

> Policy will often  
> require a greater amount of information.

This is a simple binary decision.  I want email for this
domain or not.

> To discovery policy must  
> the entire domain be queried?

You have the name.  It has a address.  You don't want email to
be sent there.  You add a single MX record next to the address.
No seaching.  Just direct query.

> A wildcard MX record and root name  
> convention exposes a domain to an SPF script attack, where a  
> different convention is expected for no email.

No the presence of the record with "." as the MX target
would stop all further processing.  You don't

Re: [policy] When Tech Meets Policy...

[Mark Andrews]

> 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 take advantage of this flux.  SMTP
>  > > server discovery via A records is permitted and should be
>  > > deprecated.
>  >
>  >  All it would require is a couple of large ISP's to adopt
>  >  such a policy.  "MX 0 " really is not hard and benefits
>  >  the remote caches.
> 
> Agreed.  While some suggest deprecating A record discovery requires
> adoption by a standards body, it really only requires a few ISPs to make
> their intentions public.  A small minority of domains lacking an MX
> record are likely to comply quickly.  At that point, adoption by a
> standards body becomes possible.  It is rare to find a standards body
> willing impose additional requirements on email, but this is a case
> where such a requirement is clearly necessary.
> 
> That point forward, spammers would be less able to take advantage
> of domains in flux, and policy schemes would be far less perilous for
> roots or second level domains.
> 
>  > > Once MX records are adopted as an _acceptance_
>  > > requisite, domains not intended to receive or send email would be
>  > > clearly denoted by the absence of MX records.  SMTP policy
>  > > published adjacent to MX records also eliminates a need for email
>  > > policy "discovery" as well.  Another looming problem.
>  >
>  >  Better yet use MX records to signal that you don't want to
>  >  receive email e.g. "MX 0 .".  It has a additional benefits
>  >  in that it is *much* smaller to cache than a negative
>  >  response.  It's also smaller to cache than a A record.
>  >
>  >  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 undesired non-cached
> traffic when applications unaware of this convention then attempt to
> resolve an address for servers named root.

All modern iterative resolvers are required to support
negative caching.

> The use of root as a convention will complicate a general strategy
> identifying adoption of a protocol by publication of a discovery
> record.  The use of root as a target name in SRV records has been
> problematic, although this convention was defined for SRV records at the
> outset.

> Using an MX record to mean "no email is accepted" by naming the
> target 'root' changes the meaning of the MX record.

Not really.  It's entirely consistant with existing DNS
usage where "." is a domain name / hostname place holder.

Lots of RR types use "." to indicate non-existance.

> It is also not clear
> whether the root target would mean "no email is sent" as well.

That is, I'll agree, more of a issue but no one can reasonably
expect people to accept non-repliable email.
 
> A clearer and safer strategy would be to insist that anyone who cares
> about their email delivery, publish a valid MX record.  Especially when
> the domain is that of a government agency dealing with emergencies.  At
> least FEMA now publishes an MX record.  This requirement should have
> been imposed long ago. : )

I much prefer positive data vs the absence of data to make a
decision.  "MX 0 ." is a definative response saying you don't
want email.

> -Doug
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: [policy] When Tech Meets Policy...

[Mark Andrews]

>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.  Spammers take advantage of this flux.  Unfortunately SMTP  
>server discovery via A records is permitted and should be  
>deprecated.  

All it would require is a couple of large ISP's to adopt
such a policy.  "MX 0 " really is not hard and benefits
the remote caches.

>Once MX records are adopted as an _acceptance_  
>requisite, domains not intended to receive or send email would be  
>clearly denoted by the absence of MX records.  SMTP policy published  
>adjacent to MX records also eliminates a need for email policy  
>"discovery" as well.  Another looming problem.

Better yet us MX records to signal that you don't want to
receive email e.g. "MX 0 .".  It has a additional benefits
in that it is *much* smaller to cache than a negative
response.  It's also smaller to cache than a A record.

Since all valid email domains are required to have a working
postmaster you can safely drop any email from such domains.

>Don't accept a message from a domain without MX records.  When there  
>is no policy record adjacent to the MX record, there is no policy,  
>and don't go looking.
>
>-Doug
>

Re: large organization nameservers sending icmp packets to dns servers.

[Mark Andrews]

> >>> 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 that
> >>were UDP only which totally busted the myth but it continues
> >>to live.
> >>
> >>Mark
> > 
> > Just to make it clear.  This was BIND 4/8 code and the bugs
> > were addressed in the last millennia.
> > 
> > To date there are no known root exploits for BIND 9.
> 
> Because who runs BIND as root anymore?

Lots of people.  It's the only way you can handle some
events.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: large organization nameservers sending icmp packets to dns servers.

[Mark Andrews]

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 continues
>   to live.
>
>   Mark

Just to make it clear.  This was BIND 4/8 code and the bugs
were addressed in the last millennia.

To date there are no known root exploits for BIND 9.

Mark

Re: large organization nameservers sending icmp packets to dns servers.

[Mark Andrews]

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.

Mark

Re: Belgian court rules that ISPs must block file-sharing

[Mark Andrews]

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 legal responsibility and
 the technical means to tackle piracy.  This is a decision that we hope will
 set the mold for government policy and for courts in other countries in
 Europe and around the world," IFPI Chairman and CEO John Kennedy said in a
 statement.

Someone has succeeded in pulling the wool over the court's
eyes if it has been convinced that there is a technical
mechanism to do this.  A ISP does not have access to enough
information to determine this.  The same file can be both
legally and illegally copied over the same network.  What
determines the legality is the standing of the parties doing
the copying not the actual content.  Even content that is
illegal to possess may still be legally transmitted when
such content is evidence.

There is only one technological fix that will be 100%
effective and that is to shutdown the network.  There is
absolutely no way that a ISP can determine is any file
transfer is illegal or not.

This means no HTTP, no SMTP, no anything.

Mark

Re: ICANN registrar supporting v6 glue?

[Mark Andrews]

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 
>(I hope!)?

You don't want to override the NS records.  You want to augment the
address records.  You can do it on a per host basis (which is what I
do at home) or you can do it by augmenting the contents of
root-servers.net.  You will note that I have choosen not
to leak the addresses to anyone other than myself.

zone "b.root-servers.net" {
type master;
file "master/b.root-servers.net";
notify no;
allow-query { localhost; };
};

zone "f.root-servers.net" {
type master;
file "master/f.root-servers.net";
notify no;
allow-query { localhost; };
};

zone "h.root-servers.net" {
type master;
file "master/h.root-servers.net";
notify no;
allow-query { localhost; };
};

zone "k.root-servers.net" {
type master;
file "master/k.root-servers.net";
notify no;
allow-query { localhost; };
};

zone "m.root-servers.net" {
type master;
file "master/m.root-servers.net";
notify no;
allow-query { localhost; };
};

or

zone "root-servers.net" {
type master;
file "master/root-servers.net";
notify no;
allow-query { localhost; };
}

>>  In the few couple of years I've only seen two outages with the
>>  IPv6 root instances.  In both cases they were fixed soon after
>>  reporting the outage.
>
>So there are v6 roots out there?

I'm using the IPv6 addresses published by the root server
operators on http://www.root-servers.org/.  They are the
addresses that will be added to root-servers.net zone once
there is agreement to add them.

> Where are they hiding and why arent they being provided in
> the hints file or NS queries on . ?

They arn't hiding.  They were published years ago.  It's
just a long process to get them added to the root-servers.net
zone.

I added them to my config on Feb 18 2005 and they had been
published for a long time when I did that.

-rw-r--r--  1 root  wheel  160 Feb 18  2005 /var/named/master/b.root-servers.net
-rw-r--r--  1 root  wheel  156 Feb 18  2005 /var/named/master/f.root-servers.net
-rw-r--r--  1 root  wheel  162 Feb 18  2005 /var/named/master/h.root-servers.net
-rw-r--r--  1 root  wheel  154 Feb 18  2005 /var/named/master/k.root-servers.net
-rw-r--r--  1 root  wheel  155 Feb 18  2005 /var/named/master/m.root-servers.net

Mark

>Steve
>
>> 
>> B.ROOT-SERVERS.NET. 3600IN  A   192.228.79.201
>> B.ROOT-SERVERS.NET. 3600IN  2001:478:65::53
>> F.ROOT-SERVERS.NET. 3600IN  A   192.5.5.241
>> F.ROOT-SERVERS.NET. 3600IN  2001:500::1035
>> H.ROOT-SERVERS.NET. 3600IN  A   128.63.2.53
>> H.ROOT-SERVERS.NET. 3600IN  2001:500:1::803f:235
>> K.ROOT-SERVERS.NET. 3600IN  A   193.0.14.129
>> K.ROOT-SERVERS.NET. 3600IN  2001:7fd::1
>> M.ROOT-SERVERS.NET. 3600IN  A   202.12.27.33
>> M.ROOT-SERVERS.NET. 3600IN  2001:dc3::35
>> 
>> >Note also that various ccTLD's are able to add glue to your zone on
>> >request (notably .fr/.ch/.nl/.se do so already for quite some time)
>> >
>> >Greets,
>> > Jeroen

Re: ICANN registrar supporting v6 glue?

[Mark Andrews]

>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
>support ticket to actually get the records in, most webinterfaces don't
>support it yet unfortunately.
>
>One note here is that even though you can get glue into com/net/org
>using this method, there is no IPv6 glue for the root yet, as such even
>if you manage to get the IPv6 glue in, it won't accomplish much (except
>sending all IPv6 capable resolvers over IPv6 transport :) as all
>resolvers will still require IPv4 to reach the root. One can of course
>create their own root hint zone and force bind, or other dns server, to
>not fetch the hints from the real root, but that doesn't help for the
>rest of the planet. (Root alternatives like orsn could fix that up but
>apparently their main german box that was doing IPv6 is out of the air)

You don't change the hints you just provide zones that override
B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET,
K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your
own ROOT-SERVERS.NET zone with the s added in.

In the few couple of years I've only seen two outages with the
IPv6 root instances.  In both cases they were fixed soon after
reporting the outage.

Mark

B.ROOT-SERVERS.NET. 3600IN  A   192.228.79.201
B.ROOT-SERVERS.NET. 3600IN  2001:478:65::53
F.ROOT-SERVERS.NET. 3600IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 3600IN  2001:500::1035
H.ROOT-SERVERS.NET. 3600IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 3600IN  2001:500:1::803f:235
K.ROOT-SERVERS.NET. 3600IN  A   193.0.14.129
K.ROOT-SERVERS.NET. 3600IN  2001:7fd::1
M.ROOT-SERVERS.NET. 3600IN  A   202.12.27.33
M.ROOT-SERVERS.NET. 3600IN  2001:dc3::35

>Note also that various ccTLD's are able to add glue to your zone on
>request (notably .fr/.ch/.nl/.se do so already for quite some time)
>
>Greets,
> Jeroen
>
>
>--enig28DE1EA6E1A720C65610D130
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: OpenPGP digital signature
>Content-Disposition: attachment; filename="signature.asc"
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.4.7 (MingW32)
>Comment: Jeroen Massar / http://unfix.org/~jeroen/
>
>iHUEARECADUFAkaFMZMuFIAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
>b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Ixw1AKC8ycHIGT3Nzs296Xf4XeeDvq+m
>agCeM0cnyTZxnh0QbnuQXVwhw2kil1o=
>=UGVO
>-END PGP SIGNATURE-
>
>--enig28DE1EA6E1A720C65610D130--

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Mark Andrews]

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 
>any coherent (and useful) information about how I can provide both IPv6 
>addressing and IPv4 addressing for the sites I host.  I'm in the process 
>of doing OS upgrades, and IPv6 is included...but currently I shut off 
>IPv6 because I don't have a IPv6 firewall solution yet.

Well there are lots of firewalls that support IPv6.  If you can't
find one you really have not searched.

>That includes DNS, by the way.  I'm deploying new DNS servers, and would 
>be *very* interested in how to convince BIND 9.2.4 to answer IPv6 queries.

listen-on-v6 { any; };

If you want finer acls than that in listen-on-v6 then you want
BIND 9.3 (currently 9.3.4) or BIND 9.4 (currently 9.4.1).

>Another issue:  the Plesk Web control panel software from SW-Soft 
>doesn't seem to have any support for IPv6.  The CPanel Web Host Manager 
>at least lets me create  records in zone files, so roughly 1/3 of my 
>customers *could* have IPv6 capability.
>
>Lurkers:  tutorials welcome.

Re: Interesting new dns failures

[Mark Andrews]

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 mailbox. (Not on NANOG
>mailing list archives.) What was the issue?
>
>> The data returned by root (gtld) nameservers is not changing
>> rapidly.
>
>Now, I understand nothing. Is there a problem with the root
>nameservers or with some gTLD nameservers???
>

There isn't a problem with the root or tld servers.

There is a problem with the server for these zones.
They don't speak RFC 1034, hence the error messages
about garbage responses.

Note the answer doesn't match the question.

; <<>> DiG 9.5.0a2 <<>> @76.183.141.203 ns6.loptran.com +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36800
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns6.loptran.com.   IN  A

;; ANSWER SECTION:
loptran.com.0   IN  A   24.218.122.218

;; Query time: 212 msec
;; SERVER: 76.183.141.203#53(76.183.141.203)
;; WHEN: Mon May 21 19:05:58 2007
;; MSG SIZE  rcvd: 60

There is a problem with the whole delegation process in
that no one involved in the delegation seems to care that
absolute garbage is being injected into the DNS.  A few
simple checks, like above, would have show that the servers
were not RFC 1034 compliant.  That the glue was not a copy
of the records in the child zone.  The parent *is* required
by RFC 1034 to check this.

RFC 1034, 4.2.2. Administrative considerations, paragraph 3.

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

These zones should be pulled.

Mark

Re: today's Wash Post Business section

[Mark Andrews]

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 anything other than a web-browser/
>> mail-client for Internet access?
>
>And what percent of our operational issues are caused by that mindset?
>
>(Hint - how much smaller would the spam problem be if end users actually
>looked at their cable or DSL modem and wondered why the Tx/Rx lights were
>on steady even though nothing was apparently happening?)

Given the amount of noise on a cable modem flickering lights
mean nothing.

Mark

bsdi# tcpdump -n -p -i sis0 -c 100
tcpdump: listening on sis0
11:32:41.454256 arp who-has 211.30.229.109 tell 211.30.229.1
11:32:41.562115 arp who-has 211.30.199.18 tell 211.30.199.1
11:32:41.642079 arp who-has 220.239.251.63 tell 220.239.251.1
11:32:41.643525 arp who-has 220.239.250.171 tell 220.239.250.1
11:32:41.677633 arp who-has 211.30.216.48 tell 211.30.216.1
11:32:41.794968 arp who-has 211.30.226.166 tell 211.30.226.1
11:32:41.874214 arp who-has 211.30.217.144 tell 211.30.217.1
11:32:41.940124 arp who-has 220.239.250.110 tell 220.239.250.1
11:32:42.061169 arp who-has 220.239.251.238 tell 220.239.251.1
11:32:42.068020 arp who-has 211.30.226.41 tell 211.30.226.1
11:32:42.112271 arp who-has 211.30.199.140 tell 211.30.199.1
11:32:42.172243 arp who-has 211.30.230.189 tell 211.30.230.1
11:32:42.202287 arp who-has 211.30.229.12 tell 211.30.229.1
11:32:42.427869 arp who-has 211.30.218.25 tell 211.30.218.1
11:32:42.547276 arp who-has 211.30.229.88 tell 211.30.229.1
11:32:42.608796 arp who-has 211.30.219.100 tell 211.30.219.1
11:32:42.657183 arp who-has 220.239.249.187 tell 220.239.249.1
11:32:42.850833 arp who-has 211.30.226.203 tell 211.30.226.1
11:32:42.950771 arp who-has 211.30.225.26 tell 211.30.225.1
11:32:43.020825 arp who-has 211.30.231.221 tell 211.30.231.1
11:32:43.189058 arp who-has 220.239.249.8 tell 220.239.249.1
11:32:43.292814 arp who-has 220.239.251.44 tell 220.239.251.1
11:32:43.299346 arp who-has 211.30.231.71 tell 211.30.231.1
11:32:43.513540 arp who-has 211.30.197.89 tell 211.30.197.1
11:32:43.691250 arp who-has 211.30.200.132 tell 211.30.200.1
11:32:43.704822 arp who-has 211.30.231.203 tell 211.30.231.1
11:32:43.735968 arp who-has 211.30.216.48 tell 211.30.216.1
11:32:43.884020 arp who-has 220.239.235.111 tell 220.239.235.1
11:32:43.960083 arp who-has 211.30.231.194 tell 211.30.231.1
11:32:44.125446 arp who-has 220.239.251.63 tell 220.239.251.1
11:32:44.153568 arp who-has 211.30.219.144 tell 211.30.219.1
11:32:44.236524 arp who-has 211.30.231.159 tell 211.30.231.1
11:32:44.407126 arp who-has 211.30.230.185 tell 211.30.230.1
11:32:44.477931 arp who-has 220.239.251.238 tell 220.239.251.1
11:32:44.550663 arp who-has 211.30.229.109 tell 211.30.229.1
11:32:44.672468 220.239.253.18.5060 > 204.152.184.238.5060: udp 397 [tos 0x70] 
11:32:44.752201 arp who-has 211.30.226.166 tell 211.30.226.1
11:32:44.763455 arp who-has 211.30.84.48 tell 211.30.84.1
11:32:44.810355 arp who-has 211.30.231.208 tell 211.30.231.1
11:32:44.822101 arp who-has 211.30.197.207 tell 211.30.197.1
11:32:44.834843 arp who-has 211.30.202.153 tell 211.30.202.1
11:32:44.835241 arp who-has 220.239.249.194 tell 220.239.249.1
11:32:44.869841 arp who-has 211.30.199.33 tell 211.30.199.1
11:32:44.876458 204.152.184.238.5060 > 220.239.253.18.5060: udp 421 (DF)
11:32:44.876678 204.152.184.238.5060 > 220.239.253.18.5060: udp 503 (DF)
11:32:44.909326 arp who-has 211.30.220.214 tell 211.30.220.1
11:32:44.925528 arp who-has 211.30.197.180 tell 211.30.197.1
11:32:44.988148 220.239.253.18.5060 > 204.152.184.238.5060: udp 569 [tos 0x70] 
11:32:45.054125 arp who-has 211.30.227.157 tell 211.30.227.1
11:32:45.084153 arp who-has 211.30.199.140 tell 211.30.199.1
11:32:45.110233 arp who-has 220.239.251.205 tell 220.239.251.1
11:32:45.183978 arp who-has 211.30.197.15 tell 211.30.197.1
11:32:45.229915 arp who-has 211.30.229.171 tell 211.30.229.1
11:32:45.249146 arp who-has 220.239.250.110 tell 220.239.250.1
11:32:45.294907 arp who-has 220.239.251.44 tell 220.239.251.1
11:32:45.306706 arp who-has 211.30.229.155 tell 211.30.229.1
11:32:45.424483 204.152.184.238.5060 > 220.239.253.18.5060: udp 421 (DF)
11:32:45.454086 204.152.184.238.5060 > 220.239.253.18.5060: udp 499 (DF)
11:32:45.498507 arp who-has 211.30.227.66 tell 211.30.227.1
11:32:45.741632 arp who-has 220.239.235.161 tell 220.239.235.1
11:32:45.789663 arp who-has 211.30.200.133 tell 211.30.200.1
11:32:45.833490 arp who-has 211.30.197.118 tell 211.30.197.1
11:32:45.963864 arp who-has 211.30.197.203 tell 211.30.197.1
11:32:46.008005 arp who-has 220.239.235.111 tell 220.239.235.1
11:32:46.079110 arp who-has 211.30.218.14 tell 211.30.218.1
11:32:46.104062 arp who-has 211.30.231.118 tell 211.30.231.1
11:32:46.191273 arp who-has 211.30.199.18 te

Re: DNS - connection limit (without any extra hardware)

[Mark Andrews]

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 directly (from the 120KB root zone file), rather than 
>> relying on negative caching, and a round trip to the root 
>> servers, for every new non-existant domain.
>
>That would require configuring my caching server with authoritative 
>zones, and it seems prevailing wisdom (at least with BIND 
>configurations?) is to keep the peanut butter seperate from the 
>chocolate, no matter how great they taste together, to the best
>of my knowledge.
>
>matto

No.  The wisdom is to not make your authoritative servers
caches.  This is not the same as not making your caches
authoritative for certain zones.  Just don't have the caches
listed in the NS RRsets.  Note:  You will need to configure
your master server(s) to notify the caches for the zone
that slave as the automatic mechanisms won't discover them.

Mark

>[EMAIL PROTECTED]<
>   Moral indignation is a technique to endow the idiot with dignity.
> - Marshall McLuhan

Re: SORBS Contact

[Mark Andrews]

> 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 allows email to be sent.
> >   
> Actually that's debatable - the SORBS DUHL is about IPs assigned to 
> hosts/people/machines dynamically.  We do not list addresses where the 
> ISP have sent the list explictitly saying 'these are static hosts, but 
> they are not allowed to send mail' - similarly we do list hosts in the 
> DUHL where the ISP has said 'these are dynamic but we allow them to send 
> mail' - it's about the people using the SORBS DUHL for their purposes, 
> not for helping ISPs getting around the issue of whether to use SORBS as 
> a replacement to port 25 blocking.

I wasn't thinking about SORBS.  It was a general warning to
only put blocks on lists where the usage matches the policy
of the list.

I was thinking about a Australian cable provider that doesn't
do the right thing.  I'm sure there will be other ISP's that
also fail to check the list policy before nominating the
address blocks for the lists.

In reality there shouldn't be the need for dialup lists.

Also most people don't really use the "dialup" lists correctly.
They really should not be a absolute blocker.  They should
    also turn off "dialup" pattern matching tests otherwise you
are getting a double penalty for the same thing.

Mark
 
> Regards,
> 
> Mat
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: SORBS Contact

[Mark Andrews]

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 to be sent.

They have a default port 25 filter that will
be turned off on request. i.e. they allow
direct out going email on request.

The said ISP *thinks* they are doing the
right thing by listing the block when in
reality they are lying by listing the block.

Mark

Re: How to handle AAAA query for v4 only host

[Mark Andrews]

>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 to, but, we are seeing a
>significant delay before we get an A query back from the resolver, which,
>we believe represents a significant delay for the end user in getting to
>the web page in question.

Both NAME ERROR and NOERROR NODATA responses can include the SOA
record in the authority section (RFC 1034, RFC 2308).  You don't
give enough information to determine which of the abore responses
you are talking about.

>Is there a better way to answer an  query for a v4 only host?  Is it
>permitted and/or desirable to return a 6to4 or IPv4-Mapped address?
>Is there some other preferable thing to return?
>
>Thanks,
>
>Owen

NOERROR NODATA is the correct response.

As for why there is a delay between the  and A queries there
are lots of possible reason.

Non RFC1535 aware resolvers.
Not looking for /A in parallel when walking the search list.
Firewalls block EDNS queries so you only see plain DNS queries.
Sending NAME ERROR not NOERROR NODATA.

Mark

Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet

[Mark Andrews]

> 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, but that is the antithesis of traditional scanning
> (which is often at least partly stochastic).  To a worm, the benefit of
> stochastic scanning is that no collaboration between infected hosts is
> needed; but with a walking traversal, you have to have some kind of
> statekeeping if the walk search is not intended to take ~forever.
> 
> I can see this vector as being useful for scanning within some specific
> organization's subnet, but even then, you'll need some kind of collaboration
> with NDP solicitations for most internal setups.  Stateless autoconfig, for
> instance, is unscannable without listening for NDP at the same time -- and
> from a remote network, you can basically forget it.

And I expect that machines using stateless autoconfig will
update their forward and reverse records in the DNS.  The
reasons for doing this are independent of the mechanism of
address assignment.  Too many services will not work unless
there is a valid PTR / address combination.
 
> You're also assuming that there will be PTR records for the most commonly
> infectable OS ([vendor product elided]) in the most commonly used
> configuration (desktop).  It's highly likely that such systems will use some
> sort of autoconfiguration, and stateless form as above presents a fairly
> large address space to scan.  If there are PTRs assigned for such hosts at
> all, the attack vector is actually somewhat simple to minimize:  have the
> DNS product in use return empty NOERROR, rather than NXDOMAIN, for any
> unassigned addresses in the /64.
>
> Don't get me wrong, I'm not one for security through obscurity in the
> primary case.  But attack vector minimization is still useful for this
> particular angle.
> 
> -- 
> -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet

[Mark Andrews]

> 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 than one hex digit's worth of randomness in the scan in
> order to find a next-level delegation, increasing the cost of scanning that
> namespace quite a bit.
> 
> (Having delegations at every nybble level would be ... alarming at best,
> given the amount of PTR redirection that implies.  :)
> 
> -- 
> -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

A simple demonstation program.   Don't run it for too long
as we don't really want to beat on WIDE's servers.

Mark

#!/bin/sh
qname=1.0.0.2.ip6.arpa
depth=4
try() {
local newqname
local oldqname
local l
oldqname=$qname
for l in 0 1 2 3 4 5 6 7 8 9 a b c d e f
do
newqname=$l.$oldqname
echo trying $newqname
dig +noques ptr $newqname > /tmp/$$xxx
grep PTR /tmp/$$xxx
if grep NOERROR /tmp/$$xxx > /dev/null
then
qname=$newqname
if test $depth -lt 31
then
depth=`expr $depth + 1`
try
depth=`expr $depth - 1`
    fi
fi
done
qname=$oldqname
}

try
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet

[Mark Andrews]

> 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 than one hex digit's worth of randomness in the scan in
> order to find a next-level delegation, increasing the cost of scanning that
> namespace quite a bit.
> 
> (Having delegations at every nybble level would be ... alarming at best,
> given the amount of PTR redirection that implies.  :)
> 
> -- 
> -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

I suggest that you re-read RFC 1034 and RFC 1035.  A empty
node returns NOERROR.  A non-existant node returns NXDOMAIN
(Name Error).

e.a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa PTR 
drugs.dv.isc.org

causes all of the following to exist.

a.e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
e.e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
e.f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
f.9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
9.e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
e.f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
f.f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
f.f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
f.4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
4.7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
7.8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
8.0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
2.0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
2.8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
8.0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
f.1.0.7.4.0.1.0.0.2.ip6.arpa
1.0.7.4.0.1.0.0.2.ip6.arpa
0.7.4.0.1.0.0.2.ip6.arpa
7.4.0.1.0.0.2.ip6.arpa
4.0.1.0.0.2.ip6.arpa
0.1.0.0.2.ip6.arpa
1.0.0.2.ip6.arpa
0.0.2.ip6.arpa
0.2.ip6.arpa
2.ip6.arpa
ip6.arpa
arpa
.

A query for any of them regardless of type should return something
other than NXDOMAIN.

Also wildcards won't save you as it is possible to detect them.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Interesting paper by Steve Bellovin - Worm propagation in a v6 internet

[Mark Andrews]

One of method missing is doing top down random walks of ip6.arpa.

Mark

Re: DOS attack against DNS?

[Mark Andrews]

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 is required to
>>> re-establish connectivity.  It is in everyones interests
>>> to do the right thing here.
>>
>> people inside one of the largest networks have told me that they have
>> customers who require the ability to bypass BCP38 restrictions, and that
>> they will therefore never be fully BCP38 compliant.  i've asked for BCP38
>> to become the default on all their other present and future customers but
>> then there was whining about bankruptcy, old outdated equipment, and so on.
>> sadly, there's no way to de-peer this network, or any other multinational,
>> and so there will be no "peer pressure" on them to implement BCP38.
>
>Consider people in the rest of the world who may purchase simplex 
>satellite links. By definition they inject traffic in places they aren't 
>announcing their route from.

But they don't need to be able to source all of 0/0.  They
need to be able to source particular addresses which they
have.  If the end point of the satellite link is dynamic
then they need to souce netblocks.  The satellite company
should be able to supply a complete list so filters can be
setup appropriately.

BCP 38 isn't all or nothing.  You do the best you can.  You
limit the exposure.

In this case if you get spoofed traffic from the satellite
company's addresses you still talk to the satellite company
to address the problem.  If they have static address
assignment it should be a easy job to trace the offending
traffic back.  If they have dynamic assignment then things
get harder.

It should be possible to prevent any "owned" box (other
than a router) spewing out spoofed traffic to the net as a
whole.  "owned" routers are a different kettle of fish.

This is not a new problem.  Sooner or later goverments will
mandate this sort of filtering if the networking community
as a whole don't do it and they may not leave room to support
satellite down links.  Think manditory strict unicast reverse
path filtering everywhere.

>> so, it's either not in everyone's interests to do the right thing, or there
>> is still a huge variance in what's considered "the right thing".  either
>> way, we're (the internet is) SCREWED until we (that's "we all") fix this.
>>
>> (if you're not seeing spoofed-source attacks, bully for you!  i didn't see
>> one today, either, but leaving this tool in the bad-guy toolbox makes us all
>> unsafe, no matter how much or how little they may be using it this day/year.)
>>
>
>-- 
>--
>Joel Jaeggli  Unix Consulting [EMAIL PROTECTED]
>GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
>

Re: DOS attack against DNS?

[Mark Andrews]

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 guess that is true, although the DNS does work for 
>#  things other than IP based networks...  dispite our respective
>#  best efforts to cripple it.
>
>i'm not trying to cripple it.  i'm saying RFC 1034/1035 was wrong about class
>"ANY".  all answer/authority/additional data where OP=QUERY and QR=1 will have
>the same class as the QCLASS (of which, in spite of the QDCOUNT field, there
>can be only one).  nodes do not have classes.  not even zones have classes.
>each class has a hierarchy of NS RRs making a "namespace".  each class needs
>its own root name servers.  there are less-coherent / more-useful ways to
>interpret "the spec", and one such way could give meaning to class "ANY", but
>no dns implementation i'm aware of follows those alternate interpretations.
>
>since nanog isn't a protocol-fine-points mailing list, at least for the DNS
>protocol, one could ask "why are we discussing this?" and my answer is, there
>is an operational tie-in.  if you see QCLASS=ANY in a firewall, that is prima
>facie evidence of malfeasance, not merely misconfiguration or
>misinterpretation.

And if you want to refuse class ANY queries in BIND 9 create a view
like the following.

view "blackhole" any {
allow-query { none; };
};

Note: all zones have to be in a view once you start using views.

Again this really is only a stop gap measure as the attack
can quite easily morph into something this won't catch.

Mark

Re: DOS attack against DNS?

[Mark Andrews]

> 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 of DNS queries that look like some sor=
> t=20
> >> 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 else seeing this attack or am I the lucky one?  Is this a=20
> >> known attack?
> >>
> >> Roy
> >=20
> > You are being used as a DoS amplifier.  The queries will be
> > spoofed.  Someone needs to learn about BCP 38.
> 
> Next to not running a $world recursive/caching service ;)
> Which is where the OP can actually do something about this problem.
> Folks who don't do ingress filtering will not be bothered to get it
> going unfortunately...
> 
> Greets,
>  Jeroen

Configure the server to serve z.tn.co.za and set
"allow-query { none; };".  This will stop the server
amplifying the attack.

Black-hole the spoofed address.  This works fine for purely
recursive servers as they shouldn't be getting queries from
the given address anyway.

On could hack the servers to identify particular tuples and
black-hole them.  This however is a not a long term solution
to the problem and requires a lot of maintenance.

Trace the spoofed traffic streams and get the offending
sites turned off recommending that BCP 38 be depoloyed.  

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 is required to
re-establish connectivity.  It is in everyones interests
to do the right thing here.

Shunning works if you have the collective gumption to do it.

Alternatively create a list of networks that agree to
implement BCP 38 and don't carry traffic from anyone else.
    Advertise that you are BCP 38 compliant.

Either way, lack of BCP 38 compliance is a collective problem
and needs to dealt with in a collective manner.
 
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: DOS attack against DNS?

[Mark Andrews]

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 else seeing this attack or am I the lucky one?  Is this a 
>known attack?
>
>Roy

You are being used as a DoS amplifier.  The queries will be
spoofed.  Someone needs to learn about BCP 38.

Mark

Re: Weird DNS issues for domains

[Mark Andrews]

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 it doesn't really matter as the bandwidth and the web server  
>will also be down.  Having a live DNS server in another part of the  
>country won't help if the access routers handling the traffic for the  
>T1 to the school is also down.
>
>Geographically diverse name servers sounds great in theory but for  
>this application it won't gain any redundancy.

People say this but then they don't see the impact of not
having DNS servers available.

The DNS was designed with the idea that atleast one of the
nameservers for a zone would always be reachable.  A zone
that is unreachable results in the caching servers using
up resouces at 1000 times the normal rate.  Milli-seconds
to tens of seconds.

Mark

Re: IPv6 Address Planning

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On 10-aug-2005, at 18:03, Leo Bicknell wrote:
>
>> IPv6 allocations in the host portion (with /64 boundaries) are
>> sparce, even for the largest networks.  The number of hosts becomes
>> unimportant.  The question we need to ask is how many independant
>> subnets will they need.
>
>> This is why many people are proposing a /56 for home users, as it
>> gives you 256 subnets.  Still more than most people will need.
>
>> Others have proposed /52 and /60, since many want to claim DNS is
>> easier if done in nibbles.
>
>And the extra precision offered by the intermediate values isn't  
>really required at this point in the discussion.  :-)
>
>I'm very much oppossed to /56 because it's still more than most users  
>need. In and of itself that doesn't matter, but it's also less than  
>what some users need. This creates the situation where people try to  
>make do with a /56, find out that they need a /48 after all (all  
>those /64 ptps...) and have to renumber. I.e., /56 provides too much  
>potential for shooting yourself in the foot.

So they need to renumber.  This really should not be a big
deal.  IPv6 nodes should all support multiple prefixes,
unlike the IPv4 world, so they should be able to transition
gracefully from one prefix to the next.

Add the new address to the DNS, withdraw the old one after
a short period.  Similarly for PTR records.  With DNAME they
don't even need to update the PTR's.  The routers just need
to add new DNAME records.

This still leaves firewall and other products which use raw
IPv6 addresses.  However if the vendors of these products
were to go through the exercise of renumbering I'm sure the
most/all of the gotchas would disappear.

>I think we should go for /60 for (presumably) one-router networks.  
>That's still 3 to 5 times as many subnets as most of those will need.  
>Anyone else should get a /48.

Re: Enable BIND cache server to resolve chinese domain name?

[Mark Andrews]

> Hi,
> 
> Some of our customer complaint they could not visit
> back to their web site, which use chinese domain name.
> I google the net and found some one recommend to use
> public-root.com servers in hint file.
> 
> I found domain name like xn--8pru44h.xn--55qx5d could
> not be resolved either. 
> 
> Our cache server runs BIND9.3.1 with root server list
> from rs.internic.net. 
> 
> Do I need to modify our cache server configuration to
> enable it?
> 
> regards
> 
> Joe

Only if you wish to do all your other customers a disfavour
by configuring your caching servers to support a private
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 4742 INTERNET: [EMAIL PROTECTED]

Re: Is my BIND Server's Cache Poisioned ?

[Mark Andrews]

> 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
> > that are IPv6 aware.  Nameservers that are not IPv6 aware
> > are not likely to make the queries that make these
> > misconfigurations visible.
> 
> Why would these dns misconfigurations be visible only to IPV6-aware servers?

Because IPv6 aware nameservers make  queries for the
IPv6 addresses of the nameservers and as a result see the
NXDOMAIN / CNAME.  The IPv4 only nameservers don't make
these queries, as a matter of practice, and only see the
problems if some client of the nameserver makes a query
for some records with the same name as that of the nameservers.

Mark
 
> -- 
> William Leibzon
> Elan Networks
> [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Is my BIND Server's Cache Poisioned ?

[Mark Andrews]

cn/A)): created
> 24-Jun-2005 19:02:00.026 fctx
> 37ad318(www.hangzhou.gov.cn/A'): start
> 24-Jun-2005 19:02:00.026 fctx
> 37ad318(www.hangzhou.gov.cn/A'): try
> 24-Jun-2005 19:02:00.026 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 24-Jun-2005 19:02:00.026 fctx
> 37ad318(www.hangzhou.gov.cn/A'): getaddresses
> 24-Jun-2005 19:02:00.027 fctx
> 37ad318(www.hangzhou.gov.cn/A'): query
> 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): send
> 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): sent
> 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): senddone
> 24-Jun-2005 19:02:00.049 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): response
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): noanswer_response
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cache_message
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelquery
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): try
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 24-Jun-2005 19:02:00.049 fctx
> 37ad318(www.hangzhou.gov.cn/A'): getaddresses
> 24-Jun-2005 19:02:00.050 fctx
> 37ad318(www.hangzhou.gov.cn/A'): query
> 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): send
> 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): sent
> 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): senddone
> 36  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): noanswer_response
> 37  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cache_message
> 38  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelquery
> 39  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 40  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): try
> 41  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 42  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): getaddresses
> 43  24-Jun-2005 19:02:00.052 fctx
> 37ad318(www.hangzhou.gov.cn/A'): query
> 44  24-Jun-2005 19:02:00.052 resquery 74b4870
> (fctx 37ad318(www.hangzhou.gov.cn/A)): send
> 45  24-Jun-2005 19:02:00.053 resquery 74b4870
> (fctx 37ad318(www.hangzhou.gov.cn/A)): sent
> 46  24-Jun-2005 19:02:00.053 resquery 74b4870
> (fctx 37ad318(www.hangzhou.gov.cn/A)): senddone
> 47  24-Jun-2005 19:02:00.054 resquery 74b4870
> (fctx 37ad318(www.hangzhou.gov.cn/A)): response
> 48  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): answer_response
> 49  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cache_message
> 50  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): clone_results
> 51  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelquery
> 52  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): done
> 53  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): stopeverything
> 54  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): cancelqueries
> 55  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): sendevents
> 56  24-Jun-2005 19:02:00.054 fetch 2739250 (fctx
> 37ad318(www.hangzhou.gov.cn/A)): destroyfetch
> 57  24-Jun-2005 19:02:00.054 fctx
> 37ad318(www.hangzhou.gov.cn/A'): shutdown
> 
> === 
> 
> 
> regards
> 
> Joe
> 
> 
> 
>   
>   
>   
> __ 
> Do you Yahoo!? 
> New and Improved Yahoo! Mail - 1GB free storage! 
> http://sg.info.mail.yahoo.com
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Underscores in host names

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>
>
>> 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 reason it has not been discussed more actively is that no TLD
>> operator has yet come forward and said that they are going to use
>> TLD host for emails, but as soon as one does this would have to be
>> accommodated and quickly (otherwise it will remain as an open issue for
>> future update to SMTP - probably RFC4821 if this numbering continues :)
>>
>
>.ws has an MX record.
>host -t mx ws. ==> mail.worldsite.ws
>
>Most MUA's (unix ones tended to work, not surprisingly) complain or break
>on "send" but technically it works. :)
>
>Thanks,
>David Ulevitch
>
>
>   David A. Ulevitch - Founder, EveryDNS.Net
>   http://david.ulevitch.com -- http://everydns.net
>

Any tld that thinks this will ever work reliably need their
heads read.  There was a good reason all the unqualified
hosts got moved into .ARPA.  Single label hosts do not work
well on a global scale.

Mark

Re: Underscores in host names

[Mark Andrews]

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 about a mail domain or the name of
>a mail host, but if it was the former I would be surprised if the customer
>could claim that it works most of the time.

Hostnames can't have a dot at the end either.  The dot at the
end is a local resolver indication to not use the search list.

Mark

Re: Underscores in host names

[Mark Andrews]

> Mark,
> 
> Grump.
> 
> I used to be in the 952/1123 sect, but I have since reformed and  
> continue to do penance for my sins.
> 
> The "hostname is not a domain name" dodge is simply wrong.  If you  
> like, I can get a signed affadavit from the author of the DNS  
> specifications (assuming he's in the office tomorrow) to the effect  
> that it was always his intent that domain names be composed of any 8- 
> bit value.  That's the whole reason for length encoding the labels.   
> RFC 2181, for all its other warts, explicitly clarified this  
> particular issue.

No one is saying that a domain name can't be any 8 bit value.

A hostname is not a domainname.  It's all through RFC's 1033,
RFC 1034 and RFC 1035.  There are references that make it clear
that a domain name is not the same as a hostname.

I quoted one of them.  I can find other references.

Proctor&Gamble.com anyone?  That is the logical concusion of
saying hostnames are arbitary 8 bit strings.
 
> The whole reason for check-names was because of very seriously broken  
> software that would allow shell meta-characters in in-addr.arpa  
> labels to do bad things.  I have come to the opinion that if such  
> software still exists, then the people who run that software deserve  
> what they get. Check-names was a bad idea that might have been  
> justified at the time, but pretending it remains justified by  
> 952/1123 has got to stop sometime.

We tried hard to kill check-names.  The only reason it still
exists is that people wouldn't move from BIND 8 without it.

I havn't run with "check-names answer" enabled in years.
 
> However, that rant was mostly irrelevant.  Can you point to _ANY_  
> application, operating system, or anything else that has any issues  
> whatsoever with an "_" of all characters?

The original query was about a OS / application that had
problems with underscores.

The point of RFC's is to promote interoperability.  People
who attempt to name there machines with underscores either
don't know better or don't care about interoperability or
both.

The simplest way to fix this is for application that
configure hostnames, real or virtual, to reject by default
illegal hostnames.  Apache should not allow virtual sites
with illegal hostnames without explicit overrides.  Similarly
for your favourite MTA, DNS server etc.  If people want to
use them they need to know they are stepping out of the
area where interoperability should occur.

Note: SRV and Active Directory *both* depend on underscore
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 and RFC 1123 describe what is currently legal
> > in hostnames.
> >
> > Underscore is NOT a legal character in a hostname.
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Underscores in host names

[Mark Andrews]

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.

Re: Underscores in host names

[Mark Andrews]

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 be a problem he's "going to take
>his business elsewhere"!
>
>I understand it's a violation of the standard, but does it pose a
>security hole to the email server to allow this sort of mail?
>
>Thanks
>

RFC 952 and RFC 1123 describe what is currently legal
in hostnames.

Underscore is NOT a legal character in a hostname.

Before anyone says that domain names allow underscore which
they do.

RFC 1034 Section 3.3

For hosts, the mapping depends on the existing syntax for host names
which is a subset of the usual text representation for domain names,  
together with RR formats for describing host addresses, etc.  Because we
need a reliable inverse mapping from address to host name, a special
mapping for addresses into the IN-ADDR.ARPA domain is also defined.

Mail domains follow the same rules as for hostnames.  RFC
821 and its replacement RFC 2821 havn't extended the syntax
to include underscores.

Mark

Re: Verisign broke GTLDs again?

[Mark Andrews]

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, status: NOERROR, id: 64471, size: 42
>;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>;; QUERY SECTION (1):
>;microsoft.net. IN  MX
>
>;; ADDITIONAL section (1):
>;EDNS0 OPT record (UDPsize: 4096): 0 bytes
>
>Note the EDNS0 stuff (numar=1).  And here's the reply to this query:
>
>;; received 12 bytes response from 192.5.6.30 port 53
>;; unexpected number of entries in QUERY section: 0
>;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64471, size: 12
>;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUERY SECTION (0):
>; invalid query section
>
>
>They're returning FORMERR (which is wrong), *and* don't return the
>original query (numqd=0).
>
>Without EDNS0 extensions, it works like expected.
>
>/mjt

This is the expected response from a server that doesn't
understand EDNS.  If you can't parse the original query,
which is what FORMERR indicates, then the only thing you
can safely send back is the DNS header.

Mark

Re: Schneier: ISPs should bear security burden

[Mark Andrews]

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 with legitimate needs to operate MTA's, who
>> have been given (let us say) static addresses by their providers which
>> fall within a range you understand to be dialup?
>> 
>> (I'm assuming you include cable and DSL end-user address pools; this is
>> the sort of thing I'm asking about.)
>
>Of course, Jay.
>
>First off, static addresses don't belong on the DUL (unless the ISP
>chooses to list them).  
>
>Second, any address can be removed by the ISP (even if it is a /32 in
>the middle of an otherwise all dynamic /16).  End-users are directed
>to have their ISP contact us, as we *do not* take the end-users word
>for it.
>
>A quick note to [EMAIL PROTECTED] will get it handled.

Actually I think there are multiple classes in DUL.

1.  unfilter addresses dynamic
2.  unfilter addresses static
3.  ISP filtered addresses dynamic
4.  ISP filtered addresses static

Most people using DUL for blocking want to detect the
unfiltered addresses.  Filtered address space poses no more
risk than any space not on the DUL and may infact pose less
risk as you know that requires a deliberate act by the ISP
to allow outgoing SMTP connections.

Whats needed is two lists.  One for the unfiltered and a
second for the filtered addresses.  The second one can be
used as a white list for those who insist on using name-patterns
to block addresses.

We already have evidence in this thread of one person using DUL
as a white list.

By continuing to lump filtered and unfiltered addresses together
you are throwing out the baby with the bath water.

I don't see the need to distinguish between static and dynamic
address.  All address space can be classes as static / dynamic
depending upon the time frame the address use is measured over.

Mark

Re: Schneier: ISPs should bear security burden

[Mark Andrews]

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
>> those are almost always stale.
>
> That's
>because the ILECs, especially, don't feel the need to separate IPs on
>which servers are allowed, and IPs on which they aren't. SBC is the worst
>in this regard. No separation, no custom reverse DNS for DSL customers, no
>way to be absolutely certain if sending mail from a specific IP is a
>violation of SBC's TOS. 
>
>I've noticed that you work for Qwest. If the people designing your network
>DO have enough clue to separate IPs, bravo... but my experience is that
>many ISPs, especially ILECs/RBOCs, don't.
>
>-- 
>JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638)
>Steven J. Sobol, Geek In Charge / [EMAIL PROTECTED] / PGP: 0xE3AE35ED
>
>"The wisdom of a fool won't set you free"   
>--New Order, "Bizarre Love Triangle"
>

Well OptusNet's cable ranges are in the DUL despite OptusNet
filtering outbound 25 by default.  You can get port 25
outbound opened on request but it doesn't do you any good
when you are listed in the DUL.

It doesn't matter if the address belongs to a business or
a residential user.  Everyone has the right to send email
directly.

As far as I can see the only reason for DUL existing is
that ISP's are too slow at reacting to abuse reports and /
or fail to send messages to say what action they took.
People got feed up with [EMAIL PROTECTED] being a blackhole from which
they if they were lucky got an automatic acknowledgement
of the messages.

In the end people reacted the way you would expect them to
react when that perceive that they are being ignored.  They
stopped reporting and turned to other means (DUL, SpamAssassin,
etc.).

Mark

Re: The power of default configurations

[Mark Andrews]

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 eventually maybe a BCP) to block
>PTR queries for 1918 space from going to the roots and TLD servers.
>
>-- 
>Eric A. Hallhttp://www.ehsco.com/
>Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

The first step in getting these sorts queries stomped on
in the right places is coming with the rewording of the ULA
draft DNS Issues section which allows nameservers to default
to returning rcode 3 (NXDOMAIN/Name Error).

The next step is to do this as a general draft which covers
all the different suffixes.

Mark

4.4 DNS Issues


At the present time  and PTR records for locally assigned local
IPv6 addresses are not recommended to be installed in the global
DNS.

For background on this recommendation, one of the concerns about
adding  and PTR records to the global DNS for locally assigned
Local IPv6 addresses stems from the lack of complete assurance that
the prefixes are unique. There is a small possibility that the same
locally assigned IPv6 Local addresses will be used by two different
organizations both claiming to be authoritative with different
contents. In this scenario, it is likely there will be a connection
attempt to the closest host with the corresponding locally assigned
IPv6 Local address. This may result in connection timeouts, connection
failures indicated by ICMP Destination Unreachable messages, or
successful connections to the wrong host. Due to this concern,
adding  records for these addresses to the global DNS is thought
to be unwise.

Reverse (address-to-name) queries for locally assigned IPv6 Local
addresses MUST NOT be sent to name servers for the global DNS, due
to the load that such queries would create for the authoritative
name servers for the ip6.arpa zone. This form of query load is not
specific to locally assigned Local IPv6 addresses; any current form
of local addressing creates additional load of this kind, due to
reverse queries leaking out of the site. However, since allowing
such queries to escape from the site serves no useful purpose, there
is no good reason to make the existing load problems worse.

The recommended way to avoid sending such queries to nameservers
for the global DNS is for recursive name server implementations to
act as if they were authoritative for an empty d.f.ip6.arpa zone
and return RCODE 3 for any such query. Implementations that choose
this strategy should allow it to be overridden, but returning an
RCODE 3 response for such queries should be the default, both because
this will reduce the query load problem and also because, if the
site administrator has not set up the reverse tree corresponding
to the locally assigned IPv6 Local addresses in use, returning RCODE
3 is in fact the correct answer.

Re: Vonage Hits ISP Resistance

[Mark Andrews]

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 don't let you drive
>it. Basic SMTP lacks safety features that are needed, ergo,
>retrictions were placed on it.

Basic SMTP is fine.  You all use it today.  I will use it
to send this message.  SMTP is not better or worse than
the postal service in identifying the sender and we have
lived with the possability of fraudulent mail for centuries.

People have this idiotic expectation that because the mail
is being delivered by a computer rather than a postie that
the identity of the sender is somehow magically authenticated.

The real issue is that it is hard to police customer machines
and it is cheeper to turn off SMTP than it is to identify,
inform and help fix customer machines.  Sooner or later
ISPs will have to start doing this as the people compromising
machines have shown a long history of getting around all
the blocks put in their way.  Spam is just a minor annoyance
compared to what they could potentially be doing with the
compromised machines.

>As was mentioned, my point was just that the question posited was
>flawed. SMTP isn't restricted for competition and money-making
>reasons, but because to not restrict it can have quite undesired
>implications. The question was why was one ok, and the other not. The
>answer is because of spam.
>
>Jamie

Re: Delegating /24's from a /19

[Mark Andrews]

> 2) Use DNAME, RFC 2672.  Good luck.
> 
> (http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html)
> 
> 3) Use RFC 2317.  "I encourage my competitors to operate this way."

Note: DNAME is equivalent to RFC 2317.  In both cases this
will break the customers expectation 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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Delegating /24's from a /19

[Mark Andrews]

> >> Um, why?
> >
> > Firstly he does NOT have authority for the /16 reverse.  Lots
> > of latent problems there.
> 
> Nor is he claiming it.  Nowhere on the internet is there anything saying
> that the entire /16 should be looked up against his nameserver.  No=20
> reference
> should exist pointing to his nameserver as authoritative for the /16.
> The convenience of having a zone file that is based on a /16 that he owns
> part of does not create authority out of thin air, nor does it make any
> meaningful claim to authority except to a system which (mistakenly) =
> attempts
> to use those nameservers as resolvers.  Yes, if you are going to do this, =
> it
> is a prerequisite that your nameserver _NOT_ be anyone's resolver.
> 
> > Secondly sideways delegations don't work.
> 
> Huh?  I'm not sure what you mean by "sideways delegations".  It is
> perfectly acceptable, for example, for:
> 
> a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net.
> ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com.
> ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com.
> ns1.subsidiary.com. returns 5.124.16.172.in-addr.arpa. IN PTR=20
> foo.subsidiary.com.

Actually it isn't.  Nameservers can and do detect this as it
looks like a classic lame delegation.  It also a sideways
delgation, the zone depth didn't impove between ns1.foobar.com
and ns1.subsidiary.com.

> This does work.  This is what is being proposed.
> 
> > Thirdly I'm sick and tired of having to debug stupid
> > schemes ISP's come up with to try to avoid SWIPing the
> > nameservers in situations like this.  They don't work
> > or they don't meet the customers expectations (i.e.
> > they have a /24 and should just be able to use x.y.z.in-addr.arpa
> > and have it work reliably).
> >
> So don't debug them.  As long as ARIN has all of the /24s within the /19
> pointing as NS records to the nameserver which contains the partially
> populated /16 zone file (or which secondaries each of the relevant /24 =
> zones
> from their true owners), things work just fine.  Nothing really to debug.

Well when you have a bug report saying that your nameserver
doesn't work because someone tried to do a sideways delegation
you have to go in there and show what is broken.

This is not expected to work.
 
> > Delegation is the DNS is strictly hierachical.
> >
> I don't see where the above breaks this.
> 
> > You either SWIP the new servers or you slave the zones
> > from the customer.  In both cases you are following the
> > delegation heirarchy.  Note even if you slave the zones
> > you still have to ensure the delegation is correct.
> >
> I guess we will have to agree to disagree on this.  I will point out that
> the above solution is working in a number of networks without problem.
> Sure, if you screw it up, it doesn't work.  That's true of DNS generally.
> 
> Owen
> 
> P.S.  Learn to trim quotations.
> 
> 
> --=20
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
> 
> --==63ACF217CA8F895998F9==
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (Darwin)
> 
> iD8DBQFCN7SEn5zKWQ/iqj0RAtK5AJ4pagTb5Ei+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]

Re: Delegating /24's from a /19

[Mark Andrews]

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 by SWIP'ing
 > the  space to the other company.

 You can SWIP it yes, but that won't help DNS on small blocks like =
>/24's.

>SWIPping the large block won't help.  SWIPping the /24s will.
>
>>> OK, what am I missing?
>>>
>>> *ASSUMPTION*:
>>>  The holder of the /16 _has_ delegated rDNS for the 32  /24s to the /19
>>>  owner.
>>>
>>> The /19 owner can, on it's nameserver, run an "authoritative" zone for
>>> the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing
>>> back to the rDNS nameserver of the /16 owner.
>>>
>Absolutely.
>
>[SNIP DNS Resolution 101 tutorial]
>
>>>
>>> _AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it
>>> pointing back to the 'parent' nameserver, this seems to work just fine.
>>> Admittedly, if the upstream block owner changes the _name_ of it's
>>> nameserver(s), the 'delegated to' nameserver  requires manual tweaking,
>>> but, realistically, "how often" does _that_ happen?
>>
>
>Seems perfectly reasonable to me.
>
>>  This is the worst piece of "advice" I have ever seen.
>>
>Um, why?

Firstly he does NOT have authority for the /16 reverse.  Lots
of latent problems there.
Secondly sideways delegations don't work.
Thirdly I'm sick and tired of having to debug stupid
schemes ISP's come up with to try to avoid SWIPing the
nameservers in situations like this.  They don't work
or they don't meet the customers expectations (i.e.
they have a /24 and should just be able to use x.y.z.in-addr.arpa
and have it work reliably).

Delegation is the DNS is strictly hierachical.

You either SWIP the new servers or you slave the zones
from the customer.  In both cases you are following the
delegation heirarchy.  Note even if you slave the zones
you still have to ensure the delegation is correct.

Mark

>>  SWIP the nameservers.  The OP customers will be expecting to
>>  be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name.  It
>>  also reduces the number of nameservers involved.  It is also
>>  the clean solution.  The RIR's are all setup to handle this.
>
>That's another alternative, but, not the only one, and, in many cases,
>not the most effective.
>
>>  For those advising RFC 2317 please read the first sentence of
>>  the introduction.  RFC 2317 was NOT written to cover this
>>  situation.  Go put it back in the filing cabinet and bring
>>  it out when you have a situation that it does cover (/25-/32
>>  sub-delegation).
>>
>While it doesn't inherently cover it, I see no reason it couldn't be
>used, although it seems unnecessarily complicated for the task.  Using
>a /16 zone with a wildcard backreference seems to me the cleanest solution,
>with SWIP coming in a close second.  In reality, the wildcard backreference
>is only needed _IF_ the nameserver is a resolver or forwarder, otherwise,
>it's useless anyway, as the nameserver in question should not be receiving
>queries outside of the space delegated to it.
>
>Owen
>
>
>--=20
>If it wasn't crypto-signed, it probably didn't come from me.
>
>--==D714B409A8D84E671065==
>Content-Type: application/pgp-signature
>Content-Transfer-Encoding: 7bit
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.2.2 (Darwin)
>
>iD8DBQFCN3X1n5zKWQ/iqj0RAja3AKCMu6gl3QfPOUVlNRfNS2oulMwWHQCfeN9g
>0aDxJs9OXpzyVVqavnPNJ4s=
>=Ja+n
>-END PGP SIGNATURE-
>
>--==D714B409A8D84E671065==--
>

Re: Delegating /24's from a /19

[Mark Andrews]

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 PROTECTED] wrote:
>> > Either by doing DNS delegation on the zone boundary or by SWIP'ing the 
>> > space to the other company.
>>
>> You can SWIP it yes, but that won't help DNS on small blocks like /24's.
>>
>> > It is very easy to do DNS delegation, say if you have 128.0.0.0/19, and 
>> > you want to delegate 128.0.1.0/24, in your zone file for 
>> > 0.128.in-addr.arpa zone put 
>> > 
>> > 1 IN   NS  ns1.othercompany.com
>> > 1 IN   NS  ns2.othercompany.com
>>
>> The only way it will work is to use RFC2317 or slave the zones from the
>> other name server.  Because he does not have the entire /16 you can't
>> just delegate like that.
>
>OK, what am I missing?
>
>*ASSUMPTION*:
>  The holder of the /16 _has_ delegated rDNS for the 32  /24s to the /19 owner.
>
>The /19 owner can, on it's nameserver, run an "authoritative" zone for
>the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing 
>back to the rDNS nameserver of the /16 owner.
>
>"He who" queries from the outside world will work their way down from the
>.arpa zone, to the  X.W.in-addr.arpa  zone, get referred to the nameserver
>at "thiscompany", and get referred to the NS listed for Y.X.W.in-addr.arpa.
>which will resolve  Z.Y.X.W.in-addr.arpa.
>
>"He who" queries the /19 owner nameserver directly for a Y.X.W.in-addr.arpa 
>address that lies within the /19 owner's addresses will get answered by
>that nameserver, *or* be referred to the client's server. If they ask for
>something *outside* the  /19 owner's space, the wildcard -- referring to
>the 'upstream' (the /16 owner) nameserver kicks in.
>
>_AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it pointing
>back to the 'parent' nameserver, this seems to work just fine. Admittedly,
>if the upstream block owner changes the _name_ of it's nameserver(s), the
>'delegated to' nameserver  requires manual tweaking, but, realistically,
>"how often" does _that_ happen?

This is the worst piece of "advice" I have ever seen.

SWIP the nameservers.  The OP customers will be expecting to
be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name.  It
also reduces the number of nameservers involved.  It is also
the clean solution.  The RIR's are all setup to handle this.

For those advising RFC 2317 please read the first sentence of
the introduction.  RFC 2317 was NOT written to cover this
situation.  Go put it back in the filing cabinet and bring
it out when you have a situation that it does cover (/25-/32
sub-delegation).

Mark

Re: An open letter to Mike Delany, mdelany@databasecity.com

[Mark Andrews]

Mike has claimed this was a hostest mistake.  I'll take him at
his word and apologise for this.

Mark
 
>   To: "Mike Delany" <[EMAIL PROTECTED]>
> 
>   Thank you for spaming me.  You have just been reported to
>   federal authorities ([EMAIL PROTECTED]) that may or
>   may not persue the matter further.  You are in clear violation
>   of Australian law, "Spam Act 2003",
>   http://scaleplus.law.gov.au/html/comact/11/6735/top.htm.
> 
>   I should also report you to the US authorities because you
>   were also in violation of the US CAN-SPAM act.
> 
> Received: from mail.databasecity.com (mail.databasecity.com [208.2.76.101])
> by sf1.isc.org (Postfix) with ESMTP id C8D4C2862F
> for <[EMAIL PROTECTED]>; Wed, 26 Jan 2005 15:15:28 + (UTC)
> (envelope-from [EMAIL PROTECTED])
> 
>   I posted this here because you clearly 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]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

An open letter to Mike Delany, mdelany@databasecity.com

[Mark Andrews]

To: "Mike Delany" <[EMAIL PROTECTED]>

Thank you for spaming me.  You have just been reported to
federal authorities ([EMAIL PROTECTED]) that may or
may not persue the matter further.  You are in clear violation
of Australian law, "Spam Act 2003",
http://scaleplus.law.gov.au/html/comact/11/6735/top.htm.

I should also report you to the US authorities because you
were also in violation of the US CAN-SPAM act.

Received: from mail.databasecity.com (mail.databasecity.com [208.2.76.101])
by sf1.isc.org (Postfix) with ESMTP id C8D4C2862F
for <[EMAIL PROTECTED]>; Wed, 26 Jan 2005 15:15:28 + (UTC)
(envelope-from [EMAIL PROTECTED])

I posted this here because you clearly 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]

Re: fixing insecure email infrastructure (was: Re: [eweek article]

[Mark Andrews]

> On Wed, Jan 26, 2005 at 07:31:44AM +1100, Mark Andrews wrote:
> > Does it really matter?
> 
> Yes it does.
> (As we all know at least since the Godzilla movie "size does matter" ;-)
> It has direct influence on the deployment.

Well someone has to stand up for the small shops.  Size has nothing
to do with compentance.  I don't know how many times I've had to
complain to some large ISP that they don't know how to delegate a
/24 correctly let alone do a RFC 2317 style delegation.

> > Even if it was only one site the problem
> > would still have to be addressed.  I know that it is lots more
> > than one because I've had to help lots of sites debug their RFC 3217
> > style delegation.
> 
> I have adressed and solved the problem in my last posting.
> 
> > Stablility has nothing to do with whether a site can just go
> > and add the records or not without having to talk to their
> > address provider.
> 
> Sure it has. If it never happens you try to solve a problem that does not
> exist. But, see below why this "problem" is even a good thing.
> 
> > RFC 2317 CNAMES the well known name.
> > MTAMARK wants to add a prefix to the well known name.
> > What happens when someone else decides to add yet another scheme
> > and another and another.
> 
> A man is in the desert for a week without water, dying with thirst.
> A van passes by with 10 bottles of water. The man is begging the
> driver to give him a bottle and the driver replies: "I can't give one
> to you because if there are 9 others I would have none left".
> There is no one else and there is no other scheme. We'll solve that issue
> when there is and maybe then DNAME is widely deployed and it isn't an
> issue at all.
> What happens if someone wants to add a new record type and another and
> yet another? This is even more complicated to deploy and it happens all
> the time.

You are adding a prefix not a type.  If you added a type there
would be no issue.  It would work with existing RFC 2317 sytle
delegations.
 
> > The point of RFC 2317 style delegations was to give control.
> > You don't get control without switching to using DNAMES.
> 
> So you say RFC 2317 failed miserably in its goal?

No.  I'm saying that by unnecessarily using a prefix for
MTAMARK it is introducing complications.

RFC 2317 has been a success.   RFC 2317 is also old and
need to be re-written to take into account what people
are wanting to do.
 
> > You are still at the mercy of your address supplier when
> > you want to make changes in your reverse in-addr.arpa space
> > otherwise.
> 
> You are at the mercy of your address supplier
> - to do RFC 2317 delegation at all (a lot don't)
> - to get the delegation right
> - to not fsck the delegation some point later
> - to not fsck the zone, so it will expire
> - to not fsck the dns server config
> - to not fsck the routing
> - to not fsck the routing filters
> - to not block port 25 or any other
> - ...

Yes there are lots of ways that things can go wrong however
doubling the configuration is alway asking for trouble
especially when there is no need to do it.
 
> But - this is the main advantage of MTAMARK: spammers cannot easily
> mark an IP address as a valid mailservers without support by the
> address provider.

So you are not going to delegate /24s?  Are you going to remove
the existing /24 that have been delegated?  They fact that customer
needs a /24 doesn't magically make them compentant.  I repeat size
is no indictation of compentance. 

> Cracking hosts or abusing them through viruses/worms doesn't help, as
> they can't set the labels giving them good reputation. With other
> methods they can easily turn an 0wned host into a valid mailserver
> for a (vanity) domain, with MTAMARK they can't set the "I'm a mailserver"
> flag by themselves.

Well for this to be effective you have to own the DNS server.
Then again for really small shops this box will already be the
mail server and will already have a MTAMARK or are you going
to ban your customers from running mail servers on their
bussiness class accounts.

Nothing will magically stop spam.  One can reduce / channel
/ identify it by applying a number measures.  None of those
measures is 100% effective.

>   \Maex
> 
> -- 
> SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
> Research & Development |   D-80807 Muenchen| Fax: +49 (89) 32356-299
> "The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: fixing insecure email infrastructure (was: Re: [eweek article]

[Mark Andrews]

> 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
would still have to be addressed.  I know that it is lots more
than one because I've had to help lots of sites debug their RFC 3217
style delegation.

> And how often do the IP addresses of (outgoing) Mailservers change within
> a subnet? None of ours has changed in the last 10 years and our
> customers (mainly business customers) usually never change them, either.

Stablility has nothing to do with whether a site can just go
and add the records or not without having to talk to their
address provider.
 
> > Every one of them would need to upgrade their servers to
> > support DNAME.  Their clients would also need to upgrade
> > their servers to support DNAME as they should be stealth
> > servers of the parent zone, to allow local lookups to work
> > when the external link is down.
> 
> If MTAMARK requires DNAME then RFC 2317 style delegations would require
> them, too. None of which is true.
>   1  CNAME   1.0/25.2.0.192.in-addr.arpa.
> works exactly the same way
>  _send._smtp._srv.1  CNAME  _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa.
> does. No special magic required. One can even use BINDs $GENERATE
> statement for that.
> Unless I am missing something I don't know of any RFC that prohibits that.

RFC 2317 CNAMES the well known name.
MTAMARK wants to add a prefix to the well known name.
What happens when someone else decides to add yet another scheme
and another and another.

The point of RFC 2317 style delegations was to give control.
You don't get control without switching to using DNAMES.
You are still at the mercy of your address supplier when
you want to make changes in your reverse in-addr.arpa space
otherwise.

Mark
 
>   \Maex
> 
> -- 
> SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
> Research & Development |   D-80807 Muenchen| Fax: +49 (89) 32356-299
> "The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: fixing insecure email infrastructure (was: Re: [eweek article]

[Mark Andrews]

> 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
> > servers to be upgraded to support DNAME.
> 
> How many legit mailservers get their revDNS from RFC 2317 style
> delegations?

Lots.  I'm sure that there are lots of ISPs/IAPs on NANOG
that do RFC 2317 style delegations for their customers.
Every one of them would need to upgrade their servers to
support DNAME.  Their clients would also need to upgrade
their servers to support DNAME as they should be stealth
servers of the parent zone, to allow local lookups to work
when the external link is down.

If you hace a RFC 2317 style delegation then you are almost
certainly doing your own mail support in addition to your own
DNS support.

> Marking hosts "MTA=no" is an addon for an explicit block.
>
> I'd assume most ISPs cannot simply mark their revDNS with "MTA=no"
> without changing contracts, but even adding "MTA=yes" would be of
> a lot of help.
> 
> And it is really easy and doesn't have any negative side effects ;-)
> 
>   \Maex
> 
> -- 
> SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
> Research & Development |   D-80807 Muenchen| Fax: +49 (89) 32356-299
> "The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: fixing insecure email infrastructure (was: Re: [eweek article]

[Mark Andrews]

> That's bad sincd DNAME is deprecated and has been removed from BIND.
> 
> Owen

Really?  Thats news to me. 

RFC 2672, Non-Terminal DNS Name Redirection, is still
a proposed standard <http://www.ietf.org/iesg/1rfc_index.txt>.

If you are thinking about RFC 3363, Representing Internet
Protocol version 6 (IPv6) Addresses in the Domain Name
System (DNS).  It does NOT deprecate DNAME.  There is no
UPDATES RFC 2672 at the top.  I was well aware that it
didn't deprecate DNAME when it passed through the WG.  I
would have complained long and loudly if it did.

Mind you, in hind site, I should have a strongly argued
that section 4 of RFC 3363 just be deleted.  All it has
done is generate confusion about the status of DNAME and
to top that the opening sentence contains assertions which
don't hold water once you think about them a little bit.

DNAME is just as useful with nibbles in the reverse tree as
it was with bitlabels.

Take RFC 2874, DNS Extensions to Support IPv6 Address Aggregation
and Renumbering, and redo the examples with nibbles.  Everything
just works.

To renumber the reverse you need to get the appropriate
DNAME records updated.  You don't need to re-establish several
levels of delegation under IP6.INT.  Yes I expect the RIRs to
add DNAMES not NS records at some point in the future for IP6.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]

Re: fixing insecure email infrastructure (was: Re: [eweek article]

[Mark Andrews]

>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 other issues but hear is not the correct place
to debate them.

Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

[Mark Andrews]

> On Mon, 10 Jan 2005 22:42:28 +1100, Mark Andrews <[EMAIL PROTECTED]> wrote
> :
> > > I receive DNS responses > 500 bytes every day (reported by PIX firewall).
>  So
> > > it is an issue, no matter wgat is recomended in RFC.
> > 
> > The correct thing to do is to fix your firewall to handle the
> > EDNS responses.
> 
> It is a cisco pix, right?  Maybe just replacing the thing with a 1U
> openbsd box will work wonders.

A PIX firewall can handle EDNS fine.  It just has to be told
what is the maximum EDNS size being advertised by the internal
    clients.  The defaults assume there is no EDNS (e.g. 512).
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

[Mark Andrews]

> I receive DNS responses > 500 bytes every day (reported by PIX firewall). So
> it is an issue, no matter wgat is recomended in RFC.

And you most probable have EDNS clients (nameservers) inside
your firewall making EDNS queries which return EDNS responses
that are bigger than 512 bytes.  EDNS has been standards
track for over 5 years now.  The majority of the nameservers
in the world talk EDNS between themselves and have been for
several years now.  Only a few queries caused the EDNS
response to exceed 512 bytes.

With the introduction of the  records for A.GTLD-SERVERS.NET
and B.GTLD-SERVERS.NET any EDNS referral from the root
servers for COM/NET now exceeds 512 bytes (520 minimum).
A plain DNS referral to COM/NET is 509 bytes so any referal
for an name longer than xx.com is dropping 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 4742 INTERNET: [EMAIL PROTECTED]

Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

[Mark Andrews]

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 answers from 
>(a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and 
>some lesser-known ccTLD servers.
>
>I would have thought this impossible, but seeing is believing...
>
>Fortunately, this problem won't present itself with regular smaller 
>MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested 
>whether these servers also suffer from the "regular" PMTUD problem 
>where the ICMP messages are ignored, but I'm assuming they don't, so 
>doing all of this over TCP should still work.

Well DNS (not EDNS) is limited to 512 octets so you unless there
are real links (not ones artificially constrained to demonstrate
a issue) this should not be a issue in practice.  The default link
mtus for slip/ppp/ethernet are all large enought for a DNS/UDP
response to get through without needing fragmentation.

For EDNS which will send up to 4k UDP datagrams (current recommended
size) this could be a issue in that the clients would have to fall
back to DNS after timing out on the EDNS query.

e.g.
EDNS query
EDNS response (dropped due to DF)
timeout
DNS query
DNS response gets through.

Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this
should be a non-issue there.

Mark

Re: is reverse dns required? (policy question)

[Mark Andrews]

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.  Sure your reverse zone scripts need some
>changes but it's only two or three lines.
>
>Ideally you could tell your DNS server in the zone file this:
>
>  _send._smtp._srv.*.*.173.128.in-addr.arpa.   IN TXT   "0"
>  _send._smtp._srv.*.*.82.198.in-addr.arpa.   IN TXT   "0"
>
>being overidden by more specific information on single IP addresses.

You obviouly do not know how wildcard work in the DNS or you
would not have made this suggestion.  Please read RFC 1034
and work though Section 4.3.2. Algorithm with a QNAME of
_send._smtp._srv.1.1.173.128.in-addr.arpa.

Re: BCP38 making it work, solving problems

[Mark Andrews]

>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: 4707582841, Bytes: 227001949225
>  RPF Failures: Packets: 11291931, Bytes: 643099278
>  RPF Failures: Packets: 291592413, Bytes: 20642951232
>  RPF Failures: Packets: 380355, Bytes: 22616137
>  RPF Failures: Packets: 607543, Bytes: 31687907
>  RPF Failures: Packets: 0, Bytes: 0
>  RPF Failures: Packets: 91, Bytes: 6978
>  RPF Failures: Packets: 0, Bytes: 0
>  RPF Failures: Packets: 0, Bytes: 0
>  RPF Failures: Packets: 2, Bytes: 80
>  RPF Failures: Packets: 13904, Bytes: 1093686
>
>   this means the junk isn't reaching root servers, peers, or
>our customers.  mitigating the need to carry this traffic when it
>is of (virtually) no use.
>
And those you do see it indicates a misconfigured / compromised
system.

A compromised system that is sending spoofed traffic can
also launch attacks using regular traffic.  Think of this
as a early warning system.

The same with those ISP's that block outbound port 25.
Think of it as a early warning system.  The customer is
misconfigured or compromised.  You need to find out which.
[This is not to say that I agree with the practice of blocking
port 25]

Apply the same logic to anything else you filter outbound.

Re: IPv6 support for com/net zones on October 19, 2004

[Mark Andrews]

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 problems resulting from this change, but
>because these zones are widely used and closely watched, we want to
>let the Internet community know about the changes in advance.
>
>Matt
>--
>Matt Larson <[EMAIL PROTECTED]>
>VeriSign Naming and Directory Services

So does this mean A and B will now support EDNS?

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-11.txt
Section 5?

I know it's only a day's work to add support if
you havn't already done it.

Mark

Re: Recent changes to UltraDNS, problems?

[Mark Andrews]

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 last week, suddenly starts reporting that the query is 
>returning an empty answer.
>
>If I change it to any other TLD servers/domains, it works fine.  What is 
>even more strange is that when I use dig, the lookups are just fine. 
>(most of the time)  Can anyone at UltraDNS (or anyone else for that 
>matter) shed some light on what might have changed/broken?

There is nothing wrong.  The real NS records for the zone
can be found in the child zone.  The UltraDNS servers are
returning a referral to them.

Also when you are querying authoritative only servers it
is a good idea to disable recursion.

Mark

; <<>> DiG 8.3 <<>> ns isc.org @TLD1.ULTRADNS.NET 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51679
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;;  isc.org, type = NS, class = IN

;; AUTHORITY SECTION:
isc.org.1D IN NSns1.gnac.com.
isc.org.1D IN NSns-ext.isc.org.

;; ADDITIONAL SECTION:
ns-ext.isc.org. 1D IN A 204.152.184.64

;; Total query time: 431 msec
;; FROM: drugs.dv.isc.org to SERVER: 204.74.112.1
;; WHEN: Tue Aug 24 11:28:40 2004
;; MSG SIZE  sent: 25  rcvd: 95


>#!/usr/bin/perl
>
>use strict;
>use Net::DNS;#version 0.48
>
>my @tld = ("tld1.ultradns.net", "tld2.ultradns.net");
>my $res = Net::DNS::Resolver->new;
>$res->nameservers(@tld);
>
>my $query = $res->query("adaconline.org", "NS");
>if($query) {
> print "It worked!\n";
>} else {
> print "It failed!\n";
>}
>
>exit;
>
>
>
>In the above case the query always returns undef and the errorstring 
>returned is no error.  My initial thought was a bug in Net::DNS, but 
>I've also heard from others they've started noticing strange lookup 
>problems when asking UltraDNS directly for answers.
>
>-- 
>Robert Blayzor, BOFH
>INOC, LLC
>[EMAIL PROTECTED]
>PGP: http://www.inoc.net/~dev/
>Key fingerprint = 1E02 DABE F989 BC03 3DF5  0E93 8D02 9D0B CB1A A7B0
>
>Profanity is the one language all programmers know best.
>

Re: Charter blocking Port 25

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On 06/09/04, Arman <[EMAIL PROTECTED]> wrote: 
>
>> Does anybody else know of other cable/DSL providers that simply block 
>> outbound port 25?
>
>   Many of 'em do.  If your contract says you can run servers on
>   your connection, then you should call and complain.
>
>   On the other hand, if Charter prohibits running servers on your
>   connection...well, you get what you pay for.

What does whether you can run a server have to do with
*initiating* SMTP traffic.

As for the original question.  Optus blocks but if you call
customer support they will remove the block with a warning
"if you spam we will block it" which is reasonable based
on the published AUP.  Yes they also added the block w/o
informing anyone.  I would be calling Charter and asking
for the block to be removed.

>   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 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: [EMAIL PROTECTED]

Re: IPv6 reverse lookup - lame delegation?

[Mark . Andrews]

> Having been present at the meeting that gave rise to the document (at 
> the IETF meetings held in London, August 2001), I'd say that the 
> material quoted in the document is at fault.  (There was quite a lot 
> of controversy at the meeting, perhaps my recollection isn't shared 
> with all others.  But this is my story and I'm sticking to it.)
> 
> The changes in status of bit labels, the A6, and DNAME were discussed 
> in the context of DNS's support of IPv6.  At the time the main debate 
> was whether or not DNS records ought to be defined to support 
> renumbering (among other features, but renumbering was the star).  A6 
> and bit sting labels (forward and reverse) proved to be too much for 
> the DNS to handle, the new thought was that such functionality ought 
> to be pulled out of DNS and into tools the pre-processed zone 
> definitions.  E.g., something that generated  records from a 
> database, etc.
> 
> DNAME was kind of the "third record in."  The change in it's "status" 
> pertained to the role it played in supporting bit sting labels - 
> which is why the "reverse tree" is mentioned in the deprecation. 
> Looking at the document now, the document ought to have read "the use 
> of DNAME RRs in the support of bit string labels is deprecated" - 
> based on my memory.
> 
> PS - Note that DNAMEs are defined in RFC 2672, not in 2874.  If you 
> want to get all "IETF document lawyerish" about it (;)), the quoted 
> material is referencing a discussion of DNAME in the context of 
> supporting renumbering, not the definition DNAME itself.
> 
> RFC 2672: Non-Terminal DNS Name Redirection
> RFC 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering

Also neither RFC 3363 nor RFC 3364 update RFC 2672.

Note the second paragraph quated from RFC 2672.  DNAME is
still very much alive.


DNAME RRs

   [RFC2874] also proposes using DNAME RRs as a way of providing the
   equivalent of A6's fragmented addresses in the reverse mapping tree.
   That is, by using DNAME RRs, one can write zone files for the reverse
   mapping tree that have the same ability to cope with rapid
   renumbering or GSE-style routing that the A6 RR offers in the main
   portion of the DNS tree.  Consequently, the need to use DNAME in the
   reverse mapping tree appears to be closely tied to the need to use
   fragmented A6 in the main tree: if one is necessary, so is the other,
   and if one isn't necessary, the other isn't either.

   Other uses have also been proposed for the DNAME RR, but since they
   are outside the scope of the IPv6 address discussion, they will not
   be addressed here.

 
> At 14:45 +0200 2/11/04, Pekka Savola wrote:
> >On Wed, 11 Feb 2004, 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 of this document is that use of DNAME RRs in the reverse
> >tree be deprecated.
> >
> >do you difficulties in parsing?
> >
> >--
> >Pekka Savola "You each name yourselves king, yet the
> >Netcore Oykingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis+1-703-227-9854
> ARIN Research Engineer
> 
> History repeats, therefore my life is a rerun.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On Wed, Feb 11, 2004 at 00:36:19 +, Paul Vixie wrote:
>
>> or just put  into effect.
>
>I am confused. Are DNAMEs deprecated or not (RFC3363, section 4)?
>
>   rvdp

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.

isc-tn-2002-1.txt describes renaming.  DNAME is still very
much standards track.

If you actually think about renumbering you still need what
DNAME gave you, the ability to renumber high (close to the root)
in the delegation tree without having to redelegate every subzone.

Mark

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

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*.  This will allow the legacy
>>  resolvers to get a answer and allow vendors to stop shipping
>>  legacy aware resolver in the vague hope that they will get
>>  a answer from IP6.INT that they didn't get from IP6.ARPA.
>
>From RFC3363:
>8<
>4.  DNAME in IPv6 Reverse Tree
>
>The issues for DNAME in the reverse mapping tree appears to be
>closely tied to the need to use fragmented A6 in the main tree: if
>one is necessary, so is the other, and if one isn't necessary, the
>other isn't either.  Therefore, in moving RFC 2874 to experimental,
>the intent of this document is that use of DNAME RRs in the reverse
>tree be deprecated.
>- >8

This is was for *supporting* RENUMBERING not RENAMING. 

The whole section should just be excised from this RFC.  It
is just wrong to say you can't use DNAME in a part of the
tree.  It also gives the wrong impression that DNAME is
deprecated when it is most definitely not.  As part of the
working group at the time this went through I apologise for
dropping the ball by letting this section stay.

If you talk to others in the WG you will find similar
opinions.

>It will indeed work, but not work everywhere. Redhat boxes for
>instance apparently croak on it. Legacy resolvers might quite
>possibly include support for it though so one might be on the
>safe side there.

Well DNAME is not going away.  Broken resolvers need to
be fixed.

>I guess DNAME is getting used more for a purpose for which it
>wasn't intended at first ;)

No.  RENAMING was a explicitly intended use.

Mark

Re: IPv6 reverse lookup - lame delegation?

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>   if i try to log into my machines back in tokyo by IPv6 SSH, it takes
>   very long time.  i guess i found the reason - (possible) lame delegation
>   of blah.ip6.int.  ip6.arpa. query returns instantly.
>   how could we fix it?
>
>itojun
>
>
>% dig
>e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int.
>ptr
>
>; <<>> DiG 9.2.3 <<>>
>e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.int.
>ptr
>;; global options:  printcmd
>;; connection timed out; no servers could be reached
>
>% dig
>e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa.
>ptr
>
>; <<>> DiG 9.2.3 <<>>
>e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa.
>ptr
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19137
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;e.5.5.e.2.4.e.f.f.f.e.4.5.0.2.0.0.0.0.0.0.0.0.1.0.0.7.3.e.f.f.3.ip6.arpa.
>IN PTR
>
>;; AUTHORITY SECTION:
>ip6.arpa.   10569   IN  SOA dns1.icann.org.
>hostmaster.icann.org. 2003080400 3600 1800 604800 10800
>
>;; Query time: 1 msec
>;; SERVER: 127.0.0.1#53(0.0.0.0)
>;; WHEN: Tue Feb 10 21:57:17 2004
>;; MSG SIZE  rcvd: 151

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*.  This will allow the legacy
resolvers to get a answer and allow vendors to stop shipping
legacy aware resolver in the vague hope that they will get
a answer from IP6.INT that they didn't get from IP6.ARPA.

Mark