Re: QWEST.NET can you fix your nameservers

[Mark Andrews]

In message 
, William Herrin writes:
> On Thu, Sep 15, 2016 at 7:30 PM, Mark Andrews  wrote:
> > Then there is SPF.  A fare portion of the reason why the SPF record
> > failed, despite it being architectually cleaner than using TXT
> > records, is that some nameservers gave bad responses to SPF queries.
> 
> Hi Mark,
> 
> I'm going to stop you there. The SPF record type failed because
> resolvers can't pass requests between clients and authoritative
> servers unless they can parse them. New DNS record types essentially
> require a universal software upgrade before they work. And universal
> software upgrades do not happen well or in anything approaching a
> timely manner. The next new DNS record type will fail for the same
> reason. And the one after that.

Again lack of DNS compliance.  Go read STD 13 then tell me that
Microsoft ships a standards compliant resolver.  They still don't
last time I checked.

Libresolv could look up any  tuple from back
when the UCB developed it.

You *never* needed universal support for new types. It is a myth.
You just need the authoritative servers to support the type and the
client to support the type.  Everything else treated it as a opaque
blob.  That is why compression pointers were only allowed for well
known types.  That is why records have a length field.  What STD
13 missed was a presentation format for unknown types.

There were implementations that got that wrong, including named,
but we fixed that well before SPF ever became a issue.

We have RFC 3597 which allows authoritative servers to load and
save records they don't know the internal structure of.  This was
published in September 2003.  All the major DNS vendors support it.
This addressed the oversight in STD 13.

You have lazy operators that haven't designed their web tools to
support RFC 3597.

Mark

> TXT is the DNS record type that's extensible without a software
> upgrade. Like it or lump it.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Lawsuits for falsyfying DNS responses ?

[Jean-Francois Mezei]

On 2016-09-15 16:03, Owen DeLong wrote:

> Please explain to me how one modifies a request or response without
> managing to “control the content” or “influence the meaning or purpose”?
> 
> Blocking a request or simply failing to answer MIGHT be within the law,
> but returning a false record certainly seems to me that it would run afoul
> of the law cited.

Blocking would also be a form of control.  Because Section 36 has a
"unless authorized by CRTC" escape clause, one has to show to the CRTC
that granting permission would be bad.

Since court proceedings have already begun, it is likely the CRTC will
be involved in court, at which point, the more evidence they have, the
more chances they have of arguing against the QC loterry censorship.

Re: QWEST.NET can you fix your nameservers

[Mark Andrews]

In message <9442fcb1-e039-4edd-8a0f-f5f351bc9...@truenet.com>, Eric Tykwinski w
rites:
> Ironically,  I always wondered why I was told not to publish SPF records,
> since it did make more sense to have both, and slowly remove the TXT
> records later.  Thanks for the heads up…
>
> What do you think really is best practice now?

For SPF the decision was made to stay with TXT. 

The IAB wrote RFC 5507 - Design Choices When Expanding the DNS.

As for testing there is:

https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-04

There is general consensus that the tests are correct to the level
that they cover.  There can always be more tests added.  There is
less consensus on how we get from where we are now to where we need
to be.

The EDNS tests tool was the starting point for this draft.

Mark
 
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
>
> > On Sep 15, 2016, at 7:30 PM, Mark Andrews  wrote:
> >
> > So your helpdesks don't get problem reports when people can't look
> > up domain names?  Recursive DNS vendors don't get bug reports when
> > domain names can't be looked up.  We don't get fixes developed
> > because there are too many broken servers out there.
> >
> > Because some servers don't answer EDNS requests this leads to false
> > positives on servers not support EDNS when they do.  This in turn
> > leads to DNSSEC validation failures as you don't get DNSSEC answers
> > without EDNS.
> >
> > IPv6 deployment was put back years because  DNS lookups got
> > wrong answers.
> >
> > DANE deployment is slow because DNS servers give bad answers to
> > _._tcp./TLSA.
> >
> > Then there is SPF.  A fare portion of the reason why the SPF record
> > failed, despite it being architectually cleaner than using TXT
> > records, is that some nameservers gave bad responses to SPF queries.
> >
> > I could go find more examples of the cost of non DNS protocol
> > compliance.
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: QWEST.NET can you fix your nameservers

[William Herrin]

On Thu, Sep 15, 2016 at 7:30 PM, Mark Andrews  wrote:
> Then there is SPF.  A fare portion of the reason why the SPF record
> failed, despite it being architectually cleaner than using TXT
> records, is that some nameservers gave bad responses to SPF queries.

Hi Mark,

I'm going to stop you there. The SPF record type failed because
resolvers can't pass requests between clients and authoritative
servers unless they can parse them. New DNS record types essentially
require a universal software upgrade before they work. And universal
software upgrades do not happen well or in anything approaching a
timely manner. The next new DNS record type will fail for the same
reason. And the one after that.

TXT is the DNS record type that's extensible without a software
upgrade. Like it or lump it.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: QWEST.NET can you fix your nameservers

[Eric Tykwinski]

Ironically,  I always wondered why I was told not to publish SPF records, since 
it did make more sense to have both, and slowly remove the TXT records later.  
Thanks for the heads up…

What do you think really is best practice now?

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Sep 15, 2016, at 7:30 PM, Mark Andrews  wrote:
> 
> So your helpdesks don't get problem reports when people can't look
> up domain names?  Recursive DNS vendors don't get bug reports when
> domain names can't be looked up.  We don't get fixes developed
> because there are too many broken servers out there.
> 
> Because some servers don't answer EDNS requests this leads to false
> positives on servers not support EDNS when they do.  This in turn
> leads to DNSSEC validation failures as you don't get DNSSEC answers
> without EDNS.
> 
> IPv6 deployment was put back years because  DNS lookups got
> wrong answers.
> 
> DANE deployment is slow because DNS servers give bad answers to
> _._tcp./TLSA.
> 
> Then there is SPF.  A fare portion of the reason why the SPF record
> failed, despite it being architectually cleaner than using TXT
> records, is that some nameservers gave bad responses to SPF queries.
> 
> I could go find more examples of the cost of non DNS protocol
> compliance.
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org 
> 

Re: QWEST.NET can you fix your nameservers

[Mark Andrews]

In message 
, "Aaron C. de Bruyn" writes:
> 
> On Thu, Sep 15, 2016 at 2:45 PM, Mark Andrews  wrote:
> >
> > Aaron,
> >How am I supposed to know which DNS vendor to contact?  DNS
> >
> 
> Sorry--I should have added a /sarcasm tag.  :)
> 
> 
> > The best way to get this fixed would be for nameservers to be checked
> > for protocol compliance, by the parent zone operators or their
> > proxies regularly.  That the child zone operator be given a short
> > (< 3 months) to fix it then all zones with that server get removed
> > from the parent zone until the server is fixed (apply the final
> > step in the complaints proceedures from RFC 1033) which forces the
> > owner of the zone to fix the server or to move to someone who follows
> > the protocol.  The servers for new delegations be checked immediately
> > and the delegation not proceed unless the delegated servers are
> > protocol compliant.
> >
> 
> Seems a bit harsh, but I'm new to the conversation.  What is being out of
> compliance actually hurting other than the nameserver operator and the
> zones they host?

So your helpdesks don't get problem reports when people can't look
up domain names?  Recursive DNS vendors don't get bug reports when
domain names can't be looked up.  We don't get fixes developed
because there are too many broken servers out there.

Because some servers don't answer EDNS requests this leads to false
positives on servers not support EDNS when they do.  This in turn
leads to DNSSEC validation failures as you don't get DNSSEC answers
without EDNS.

IPv6 deployment was put back years because  DNS lookups got
wrong answers.

DANE deployment is slow because DNS servers give bad answers to
_._tcp./TLSA.

Then there is SPF.  A fare portion of the reason why the SPF record
failed, despite it being architectually cleaner than using TXT
records, is that some nameservers gave bad responses to SPF queries.

I could go find more examples of the cost of non DNS protocol
compliance.

> > My bet is the DNS vendor has issued a update already and that it
> > hasn't been applied.  If not Qwest can inform them that their product
> > is broken.  Fixing this should be about 10 minutes for the DNS
> > vendor then QA.
> >
> 
> Yeah, but the business upgrade cycles are the killer.
> Why dedicate resources to fix it unless there's a pretty clear
> line-of-sight to lost profits?
> That's why so many of my clients refuse to upgrade away from XP.  It still
> works for what they basically need, and it's not really impacting their
> profit in a way the CFO can directly see.  (i.e. he doesn't see people like
> me who will walk out of a dental office and never come back when I see a
> 2-plus-year-out-of-date XP machine handling patient information.)
> 
> I'm sure the same is happening in a large bureaucracy like Qwest.
> 
> Maybe you're right with a harsher penalty.  Be standards compliant or
> you'll get a warning, then be cut off.
> 
> 
> 
> > If you (collectively) haven't already checked your servers go to
> > https://ednscomp.isc.org and check your servers.  While you are
> > there look at some of the reports.
> >
> 
> Tested.  I'm compliant.  I definitely think more comprehensive tools that
> are easily accessible to admins and CFOs would help.
> 
> For example, when I explain various zone-related things to CFOs, I'll use
> http://intodns.com/.  It's sorta flashy, and contains some sorta helpful
> information that a CFO can sorta understand.
> 
> And a big red 'X' when someone is wrong.
> 
> Unfortunately it doesn't do DNSSEC.  For that, there's another tool.
> ...and if you want EDNS testing, there's your tool.
> 
> A tool that tests compliance for everything and spits out errors, warnings,
> and recommendations might go a long ways towards getting people to solve
> the problem.
> 
> Just my $0.02.
> 
> Nice graphs by the way.
> 
> -A
> 
> --001a11394e2c845079053c9314bd
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> On T=
> hu, Sep 15, 2016 at 2:45 PM, Mark Andrews < mailto:ma...@isc.org"; target=3D"_blank">ma...@isc.org> wrote:=
>  x #ccc solid;padding-left:1ex">Aaron,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0How am I supposed to know which DNS vendor to co=
> ntact?=C2=A0 DNSSorry--I should have a=
> dded a /sarcasm tag. =C2=A0:)=C2=A0 ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
> ft:1ex">The best way to get this fixed would be for nameservers to be check=
> ed
> for protocol compliance, by the parent zone operators or their
> proxies regularly.=C2=A0 That the child zone operator be given a short
> (< 3 months) to fix it then all zones with that server get removed
> from the parent zone until the server is fixed (apply the final
> step in the complaints proceedures from RFC 1033) which forces the
> owner of the zone to fix the server or to move to someone who follows
> the protocol.=C2=A0 The servers for new delegations be checked immediately<=
> br>
> and the delegation not proc

Re: ___Your___$ __l O O O Walmart___GiftCard

[Aaron C. de Bruyn]

That's interesting.

heyaaron.com is one big huge catch-all that funnels into my Google Apps for
Domains mailbox.

There's one account, it has a good password, and it's protected by a Ubikey.

I'd be interested in seeing a copy of the headers from that e-mail.

-A


On Thu, Sep 15, 2016 at 3:15 PM, Brian majors  wrote:

> I am reporting you to the Fed scammer
>
> On Sep 15, 2016 6:10 PM, "__WLM__"  wrote:
> >
> > CongartsThis__is Your$ l O O O GiftCard
>

Re: QWEST.NET can you fix your nameservers

[Aaron C. de Bruyn]

On Thu, Sep 15, 2016 at 2:45 PM, Mark Andrews  wrote:
>
> Aaron,
>How am I supposed to know which DNS vendor to contact?  DNS
>

Sorry--I should have added a /sarcasm tag.  :)


> The best way to get this fixed would be for nameservers to be checked
> for protocol compliance, by the parent zone operators or their
> proxies regularly.  That the child zone operator be given a short
> (< 3 months) to fix it then all zones with that server get removed
> from the parent zone until the server is fixed (apply the final
> step in the complaints proceedures from RFC 1033) which forces the
> owner of the zone to fix the server or to move to someone who follows
> the protocol.  The servers for new delegations be checked immediately
> and the delegation not proceed unless the delegated servers are
> protocol compliant.
>

Seems a bit harsh, but I'm new to the conversation.  What is being out of
compliance actually hurting other than the nameserver operator and the
zones they host?



> My bet is the DNS vendor has issued a update already and that it
> hasn't been applied.  If not Qwest can inform them that their product
> is broken.  Fixing this should be about 10 minutes for the DNS
> vendor then QA.
>

Yeah, but the business upgrade cycles are the killer.
Why dedicate resources to fix it unless there's a pretty clear
line-of-sight to lost profits?
That's why so many of my clients refuse to upgrade away from XP.  It still
works for what they basically need, and it's not really impacting their
profit in a way the CFO can directly see.  (i.e. he doesn't see people like
me who will walk out of a dental office and never come back when I see a
2-plus-year-out-of-date XP machine handling patient information.)

I'm sure the same is happening in a large bureaucracy like Qwest.

Maybe you're right with a harsher penalty.  Be standards compliant or
you'll get a warning, then be cut off.



> If you (collectively) haven't already checked your servers go to
> https://ednscomp.isc.org and check your servers.  While you are
> there look at some of the reports.
>

Tested.  I'm compliant.  I definitely think more comprehensive tools that
are easily accessible to admins and CFOs would help.

For example, when I explain various zone-related things to CFOs, I'll use
http://intodns.com/.  It's sorta flashy, and contains some sorta helpful
information that a CFO can sorta understand.

And a big red 'X' when someone is wrong.

Unfortunately it doesn't do DNSSEC.  For that, there's another tool.
...and if you want EDNS testing, there's your tool.

A tool that tests compliance for everything and spits out errors, warnings,
and recommendations might go a long ways towards getting people to solve
the problem.

Just my $0.02.

Nice graphs by the way.

-A

Re: QWEST.NET can you fix your nameservers

[Mark Andrews]

In message 

, William Herrin writes:
> On Thu, Sep 15, 2016 at 12:22 PM, Aaron C. de Bruyn  wrot
> e:
> > On Thu, Sep 15, 2016 at 12:31 AM, Mark Andrews  wrote:
> >> QWEST isn't the only DNS provider that has broken nameservers.  One
> >> shouldn't have to try and contact every DNS operator to get them to
> >> use protocol compliant servers.
> >
> > Save yourself some time.  Contact the DNS software vendors. ;)
> 
> I'd bet he already has. This looks like a name-and-shame to me, and
> probably deserved.
> 
> -Bill

Aaron,
   How am I supposed to know which DNS vendor to contact?  DNS
server fingerprinting is not a exact science.  After that I then
still need to work out how to contact every operator of a broken
server and get them to contact the DNS vendor to get a fix.  And
by the way the SOA RNAME is often a blackhole or it bounces or it
is syntactically invalid.

The best way to get this fixed would be for nameservers to be checked
for protocol compliance, by the parent zone operators or their
proxies regularly.  That the child zone operator be given a short
(< 3 months) to fix it then all zones with that server get removed
from the parent zone until the server is fixed (apply the final
step in the complaints proceedures from RFC 1033) which forces the
owner of the zone to fix the server or to move to someone who follows
the protocol.  The servers for new delegations be checked immediately
and the delegation not proceed unless the delegated servers are
protocol compliant.

Everybody seems to think they know how to write a DNS server.  The
problem is that most people don't test anything other than simple
queries and that includes many of the DNS vendors.  Think about all
the load balancer vendors that don't handle anything but a A query
or only handle A and  queries don't handle DNSKEY queries.
There really is no excuse to not handle non-meta qtypes properly
(no error not data or name error depending upon whether the name
exists or not).

My bet is the DNS vendor has issued a update already and that it
hasn't been applied.  If not Qwest can inform them that their product
is broken.  Fixing this should be about 10 minutes for the DNS
vendor then QA.

If you (collectively) haven't already checked your servers go to
https://ednscomp.isc.org and check your servers.  While you are
there look at some of the reports.

If there are any tech reporters out there can you report on the
issue of non compliance in DNS servers and that it can lead to
lookups failing.  This issue affects everybody.

Mark

> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Any ISPs using AS852 for IP Transit?

[Theodore Baschak]

I don't think this is standard across the board with Telus.

I've also heard (rumours?) of a similar $250 prefix change free associated with 
Shaw/AS6327 changes before, and also a much larger $750 change prefix change 
fee with BELL-GT/AS6539, but the customers I know who use them definitely don't 
get charged these types of fees.


Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/

> On Sep 15, 2016, at 2:21 PM, Jason Lixfeld  wrote:
> 
> Sure.  My question was whether every TELUS BGP customer was being charged for 
> these too, or if I’m the only one.  If I’m the only one, then I’m obviously 
> caught in some administrative black hole there that I would like to get 
> myself out of.  This is something that has only started happening in the last 
> 6 months or so.  Prior to that, we were never charged by them for these 
> requests.  Unfortunately, my sales rep has been less than helpful in trying 
> to understand what changed to make us susceptible to these new charges.
> 
>> On Sep 15, 2016, at 3:15 PM, Hugo Slabbert  wrote:
>> 
>> So, to be blunt, I would cast this as their charging you NRC for manual work 
>> because of their failure to automate this.
>> 
>> -- 
>> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
>> pgp key: B178313E   | also on Signal
>> 
>> On Thu 2016-Sep-15 15:09:33 -0400, Jason Lixfeld  
>> wrote:
>> 
>>> Last time I asked, that wasn’t something that they had implemented, and had 
>>> no definite plans to do so within any timeframe that was on their radar.
>>> 
 On Sep 15, 2016, at 2:50 PM, Steven Schecter  wrote:
 
 I question their motivation here and would follow up by asking if they 
 support filtering by IRRdb and are merely trying to encourage the practice?
 
 
 /Steve
 
 On Thu, Sep 15, 2016 at 2:07 PM, Jason Lixfeld  
 wrote:
 If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be 
 interested in hearing from you.
 
 I’d like to compare notes to see if you are also paying $250 for each BGP 
 prefix filter updated request, or if we’re the only ones…
 
 Thanks in advance!
 
 
 
 --
 Steven J. Schecter
 (m) 917.676.1646
>>> 
> 

Re: Lawsuits for falsyfying DNS responses ?

[Owen DeLong]

> On Sep 14, 2016, at 12:14 AM, Jean-Francois Mezei 
>  wrote:
> 
> On 2016-09-13 03:42, LHC wrote:
>> I believe that the CRTC has rules against censorship - meaning that 
>> Videotron, Bell etcetera have a choice between following the CRTC code or 
>> the provincial law (following one = sanctions from the other), rendering 
>> internet service provision to Québec impossible without being a dialup 
>> provider from out-of-province.
> 
> 
> Canada's Telecom Act (*) dates from 1993, which predates the Internet
> being a primary transporter that drives the economy.
> 
> The clause being looked at by the CRTC is 36:
> 
> Content of Messages
> 
> 36 Except where the Commission approves otherwise, a Canadian carrier
> shall not control the content or influence the meaning or purpose of
> telecommunications carried by it for the public.
> 
> There is not explicit clause about a carrier not modyfying content or
> blocking access, so one has to frame an issue to fit existing clauses.

Please explain to me how one modifies a request or response without
managing to “control the content” or “influence the meaning or purpose”?

Blocking a request or simply failing to answer MIGHT be within the law,
but returning a false record certainly seems to me that it would run afoul
of the law cited.

Owen

Re: Any ISPs using AS852 for IP Transit?

[Jason Lixfeld]

Sure.  My question was whether every TELUS BGP customer was being charged for 
these too, or if I’m the only one.  If I’m the only one, then I’m obviously 
caught in some administrative black hole there that I would like to get myself 
out of.  This is something that has only started happening in the last 6 months 
or so.  Prior to that, we were never charged by them for these requests.  
Unfortunately, my sales rep has been less than helpful in trying to understand 
what changed to make us susceptible to these new charges.

> On Sep 15, 2016, at 3:15 PM, Hugo Slabbert  wrote:
> 
> So, to be blunt, I would cast this as their charging you NRC for manual work 
> because of their failure to automate this.
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
> 
> On Thu 2016-Sep-15 15:09:33 -0400, Jason Lixfeld  
> wrote:
> 
>> Last time I asked, that wasn’t something that they had implemented, and had 
>> no definite plans to do so within any timeframe that was on their radar.
>> 
>>> On Sep 15, 2016, at 2:50 PM, Steven Schecter  wrote:
>>> 
>>> I question their motivation here and would follow up by asking if they 
>>> support filtering by IRRdb and are merely trying to encourage the practice?
>>> 
>>> 
>>> /Steve
>>> 
>>> On Thu, Sep 15, 2016 at 2:07 PM, Jason Lixfeld  
>>> wrote:
>>> If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be 
>>> interested in hearing from you.
>>> 
>>> I’d like to compare notes to see if you are also paying $250 for each BGP 
>>> prefix filter updated request, or if we’re the only ones…
>>> 
>>> Thanks in advance!
>>> 
>>> 
>>> 
>>> --
>>> Steven J. Schecter
>>> (m) 917.676.1646
>> 

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Mel,

If you are speaking of RPKI based origin validation, I am not sure
"automated / global enforcement system" is a useful description.   It does
provide a consistent means for address holders to declare AS's authorized
to announce prefixes, and a means for remote ASs to compare received
updates vs such declarations.   What the receiving AS does with the
validation information is strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than
IRR-based route filtering has been for 20 years.  The only difference is
that there is a consistent security model across all 5 RIRs as to who can
make such declarations and it is tightly tied to the address allocation
business process.

I have seen a lot of FUD about the specter of interference, but not a lot
of serious thought / discussion.  Having a serious technical discussion of
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman  wrote:

> Scott and Doug,
>
> The problem with a new automated enforcement system is that it hobbles
> both agility and innovation. ISPs have enjoyed simple BGP management,
> entirely self-regulated, for decades. A global enforcement system, besides
> being dang hard to do correctly, brings the specter of government
> interference, since such a system could be overtaken by government entities
> to manhandle free speech.
>
> In my opinion, the community hasn't spent nearly enough time discussing
> the danger aspect. Being engineers, we focus on technical means, ignoring
> the fact that we're designing our own guillotine.
>
>  -mel beckman
>
> > On Sep 14, 2016, at 12:10 AM, Scott Weeks 
> wrote:
> >
> >
> >
> > --- dougm.w...@gmail.com wrote:
> > From: Doug Montgomery 
> >
> > If only there were a global system, with consistent and verifiable
> security
> > properties, to permit address holders to declare the set of AS's
> authorized
> > to announce their prefixes, and routers anywhere on the Internet to
> > independently verify the corresponding validity of received
> announcements.
> >
> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> > 
> >
> >
> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
> > a real discussion... ;-)
> >
> > scott
>



-- 
DougM at Work

Re: Any ISPs using AS852 for IP Transit?

[Hugo Slabbert]

So, to be blunt, I would cast this as their charging you NRC for manual 
work because of their failure to automate this.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-Sep-15 15:09:33 -0400, Jason Lixfeld  wrote:


Last time I asked, that wasn’t something that they had implemented, and had no 
definite plans to do so within any timeframe that was on their radar.


On Sep 15, 2016, at 2:50 PM, Steven Schecter  wrote:

I question their motivation here and would follow up by asking if they support 
filtering by IRRdb and are merely trying to encourage the practice?


/Steve

On Thu, Sep 15, 2016 at 2:07 PM, Jason Lixfeld  wrote:
If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be 
interested in hearing from you.

I’d like to compare notes to see if you are also paying $250 for each BGP 
prefix filter updated request, or if we’re the only ones…

Thanks in advance!



--
Steven J. Schecter
(m) 917.676.1646




signature.asc
Description: Digital signature

Re: Any ISPs using AS852 for IP Transit?

[Jason Lixfeld]

Last time I asked, that wasn’t something that they had implemented, and had no 
definite plans to do so within any timeframe that was on their radar.

> On Sep 15, 2016, at 2:50 PM, Steven Schecter  wrote:
> 
> I question their motivation here and would follow up by asking if they 
> support filtering by IRRdb and are merely trying to encourage the practice?
> 
> 
> /Steve
> 
> On Thu, Sep 15, 2016 at 2:07 PM, Jason Lixfeld  wrote:
> If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be 
> interested in hearing from you.
> 
> I’d like to compare notes to see if you are also paying $250 for each BGP 
> prefix filter updated request, or if we’re the only ones…
> 
> Thanks in advance!
> 
> 
> 
> -- 
> Steven J. Schecter
> (m) 917.676.1646

Re: QWEST.NET can you fix your nameservers

[Aaron C. de Bruyn]

On Thu, Sep 15, 2016 at 10:19 AM,  wrote:

> Remember that Windows XP didn't enable IPv6 by default, and *still* has
> some 10%
> market share.
>

Yeah, I'm still fighting that battle.

https://goo.gl/photos/xFguK4FL2iydnLhE7

-A

Re: Any ISPs using AS852 for IP Transit?

[Steven Schecter]

I question their motivation here and would follow up by asking if they
support filtering by IRRdb and are merely trying to encourage the practice?


/Steve

On Thu, Sep 15, 2016 at 2:07 PM, Jason Lixfeld 
wrote:

> If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be
> interested in hearing from you.
>
> I’d like to compare notes to see if you are also paying $250 for each BGP
> prefix filter updated request, or if we’re the only ones…
>
> Thanks in advance!




-- 
Steven J. Schecter
(m) 917.676.1646

Re: charges for prefix filter updates (was Re: Any ISPs using AS852 for IP Transit?)

[joel jaeggli]

On 9/15/16 11:28 AM, Ken Chase wrote:
> I feel this can be a public topic:
>
> Rogers just charged us that for an update (one update, multiple entries).
> We had to go through their quotation machinery too, took like 4-5 days. 
> Additional
> time was wasted because we contacted their tech dept directly at the start. 
> (which
> is what I do for all my other upstreams...)
>
> Kinda brutal.
Coordination problems are a point of high friction and cost for low
margin products. I generally prefer that my providers be able to
generate prefix filters on the basis of route objects, If it's not part
of their service offering; how costs are assigned for service requests
is going to be part of contract negotiions.

joel

> Cogent and HE nor NAC or Yipes or Tata ever did that to us.
>
> Nickle and diming -- why, cuz transit is a cheap commodity now, gotta make the
> cash somewhere?
>
> That said Cogent offered us a static /26 along side our BGP years ago then 
> warned
> us it'd be $50/mo or something for that # of ips going forward. We didnt need 
> it
> so dispensed with it.
>
> /kc
>
>
> On Thu, Sep 15, 2016 at 02:07:01PM -0400, Jason Lixfeld said:
>   >If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I???d 
> be interested in hearing from you.
>   >
>   >I???d like to compare notes to see if you are also paying $250 for each 
> BGP prefix filter updated request, or if we???re the only ones???
>   >
>   >Thanks in advance!
>




signature.asc
Description: OpenPGP digital signature

charges for prefix filter updates (was Re: Any ISPs using AS852 for IP Transit?)

[Ken Chase]

I feel this can be a public topic:

Rogers just charged us that for an update (one update, multiple entries).
We had to go through their quotation machinery too, took like 4-5 days. 
Additional
time was wasted because we contacted their tech dept directly at the start. 
(which
is what I do for all my other upstreams...)

Kinda brutal.

Cogent and HE nor NAC or Yipes or Tata ever did that to us.

Nickle and diming -- why, cuz transit is a cheap commodity now, gotta make the
cash somewhere?

That said Cogent offered us a static /26 along side our BGP years ago then 
warned
us it'd be $50/mo or something for that # of ips going forward. We didnt need it
so dispensed with it.

/kc


On Thu, Sep 15, 2016 at 02:07:01PM -0400, Jason Lixfeld said:
  >If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I???d be 
interested in hearing from you.
  >
  >I???d like to compare notes to see if you are also paying $250 for each BGP 
prefix filter updated request, or if we???re the only ones???
  >
  >Thanks in advance!

-- 
Ken Chase - m...@sizone.org Toronto Canada

Any ISPs using AS852 for IP Transit?

[Jason Lixfeld]

If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I’d be 
interested in hearing from you.

I’d like to compare notes to see if you are also paying $250 for each BGP 
prefix filter updated request, or if we’re the only ones…

Thanks in advance!

Re: QWEST.NET can you fix your nameservers

[Valdis . Kletnieks]

On Thu, 15 Sep 2016 09:22:10 -0700, "Aaron C. de Bruyn" said:
> On Thu, Sep 15, 2016 at 12:31 AM, Mark Andrews  wrote:
>
> > QWEST isn't the only DNS provider that has broken nameservers.  One
> > shouldn't have to try and contact every DNS operator to get them to
> > use protocol compliant servers.

> Save yourself some time.  Contact the DNS software vendors. ;)

Often, the vendor *is* on the ball, but the customer isn't.

Remember that Windows XP didn't enable IPv6 by default, and *still* has some 10%
market share.





pgp5Gwr_CpDdR.pgp
Description: PGP signature

Re: QWEST.NET can you fix your nameservers

[William Herrin]

On Thu, Sep 15, 2016 at 12:22 PM, Aaron C. de Bruyn  wrote:
> On Thu, Sep 15, 2016 at 12:31 AM, Mark Andrews  wrote:
>> QWEST isn't the only DNS provider that has broken nameservers.  One
>> shouldn't have to try and contact every DNS operator to get them to
>> use protocol compliant servers.
>
> Save yourself some time.  Contact the DNS software vendors. ;)

I'd bet he already has. This looks like a name-and-shame to me, and
probably deserved.

-Bill




-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: QWEST.NET can you fix your nameservers

[Aaron C. de Bruyn]

On Thu, Sep 15, 2016 at 12:31 AM, Mark Andrews  wrote:

> QWEST isn't the only DNS provider that has broken nameservers.  One
> shouldn't have to try and contact every DNS operator to get them to
> use protocol compliant servers.
>

Save yourself some time.  Contact the DNS software vendors. ;)

-A

QWEST.NET can you fix your nameservers

[Mark Andrews]

In case anyone is wondering why I've been harping on about EDNS
compliance this is why.  Failure to follow the protocol can result
in DNS lookup failures.  nara.gov is signed and the recursive server
performs DNSSEC validation and sends queries with DNS COOKIEs.

BADVERS is NOT a valid response to a EDNS version 0 query.

Can you please contact your DNS vendor for a fix.

QWEST isn't the only DNS provider that has broken nameservers.  One
shouldn't have to try and contact every DNS operator to get them to
use protocol compliant servers.

Mark

;; BADCOOKIE, retrying.

; <<>> DiG 9.11.0rc1 <<>> nara.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5744
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 85faf1e39a1a6a149bebd00a57da4b266b8546c1b75015db (good)
;; QUESTION SECTION:
;nara.gov.  IN  A

;; Query time: 5000 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 15 17:17:58 EST 2016
;; MSG SIZE  rcvd: 65



Checking: 'nara.gov' as at 2016-09-15T07:16:32Z

nara.gov @63.150.72.5 (sauthns1.qwest.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok 
edns@512tcp=ok optlist=badvers,nosoa
nara.gov @2001:428::7 (sauthns1.qwest.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok 
edns@512tcp=ok optlist=badvers,nosoa
nara.gov @208.44.130.121 (sauthns2.qwest.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok 
edns@512tcp=ok optlist=badvers,nosoa
nara.gov @2001:428::8 (sauthns2.qwest.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok 
edns@512tcp=ok optlist=badvers,nosoa
The Following Tests Failed

EDNS - Unknown Option Handling (ednsopt)

dig +nocookie +norec +noad +ednsopt=100 soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: that the option will not be present in response
See RFC6891, 6.1.2 Wire Format

EDNS - DO=1 (do)

dig +nocookie +norec +noad +dnssec soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: DO flag in response if RRSIG is present in response
See RFC3225

EDNS - Supported Options Probe (optlist)

dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie -q zone @server
expect: NOERROR
expect: OPT record with version set to 0
See RFC6891

Codes

ok - test passed.
nodo - EDNS DO flag not echoed.
nosoa - SOA record not found when expected.
badvers - BADVERS returned.
To retrieve this report in the future: 
https://ednscomp.isc.org/ednscomp/25f2ebe619


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: ma...@isc.org