[dns-operations] latest bind, EDNS & TCP

[Simon Munton]

Recently, some servers seems to be only using bufsize=512 and so, for 
signed zones, always falling back to TCP. This seemed to start about 
11th Sep, but got significantly worse after the 6th Oct.


I seem to remember someone saying that the latest version of bind starts 
with bufsize=512, but presumably it will learn a larger bufsize 
capability, if declared by the responding server?


Despite us replying with bufsize=4096, all queries from certain hosts 
always come with bufsize=512 and so, if the zone is signed (as are most 
ccTLDs we carry), the query is always immediately re-issued over TCP.


The consequence is that this has vastly increased the number of TCP 
queries we now get.


I have tried unsuccessfully to reproduce this behaviour, but the fact 
remains that very recently a number of EDNS0/DNSSEC capable servers have 
started always using bufsize=512 and so repeating every single query (to 
any signed zone) over TCP.



Obviously this has the potential to vastly increase the load on TLD name 
servers over time.




Is anyone else seeing this?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] latest bind, EDNS & TCP

[Roland Dobbins]

On Oct 10, 2014, at 8:53 PM, Simon Munton  wrote:

> I have tried unsuccessfully to reproduce this behaviour, but the fact remains 
> that very recently a number of EDNS0/DNSSEC capable servers have started 
> always using bufsize=512 and so repeating every single query (to any signed 
> zone) over TCP.

Is it possible that some folks have overzealously misinterpreted Geoff Huston's 
article in the latest IPJ?



--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] latest bind, EDNS & TCP

[Simon Munton]

I suspect you were slightly joking, but my guy feeling is that this 
phenomenon is too common to be caused by an unusual configuration, but 
must be a change in the default behaviour and the resolver s/w.




On 10/10/14 15:08, Roland Dobbins wrote:


On Oct 10, 2014, at 8:53 PM, Simon Munton  wrote:


I have tried unsuccessfully to reproduce this behaviour, but the fact remains 
that very recently a number of EDNS0/DNSSEC capable servers have started always 
using bufsize=512 and so repeating every single query (to any signed zone) over 
TCP.


Is it possible that some folks have overzealously misinterpreted Geoff Huston's 
article in the latest IPJ?



--
Roland Dobbins  // 

Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] latest bind, EDNS & TCP

[Stephane Bortzmeyer]

On Fri, Oct 10, 2014 at 02:53:38PM +0100,
 Simon Munton  wrote 
 a message of 33 lines which said:

> Is anyone else seeing this?

No, not really. On one server, I see an increase of no-EDNS from
Oct. 6th. On the others, I see nothing. For instance, here is the DSC
graph for d.nic.fr.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] latest bind, EDNS & TCP

[Roland Dobbins]

On Oct 10, 2014, at 9:37 PM, Simon Munton  wrote:

> but must be a change in the default behaviour and the resolver s/w.

Which one(s) have been recently updated and are suspect?  Would they really 
have overwritten previously-configured options, or blithely added new ones 
which were enabled by default?

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] latest bind, EDNS & TCP

[Peter Koch]

On Fri, Oct 10, 2014 at 02:53:38PM +0100, Simon Munton wrote:

> I seem to remember someone saying that the latest version of bind starts 
> with bufsize=512, but presumably it will learn a larger bufsize 
> capability, if declared by the responding server?

the decreased buffer size is in response to issues with the path,
so an "ecouragement" by the responding authoritative server
won't help.  In fact, that part is mostly useless unless and until
queries (maybe with additional sugar) exceeed 512 octets.
 
> Obviously this has the potential to vastly increase the load on TLD name 
> servers over time.

> Is anyone else seeing this?

Our data shows "something" that needs a bit further investigation to
eventually declare it as noise, but it's not drastic enough to call
me to the drill instantly.

-Peter
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Is this valid edns0 query?

[Mohamed Lrhazi]

Hello,

We have an appliance generating DNS requests that our F5 DNS server is
silently dropping... We are working with both vendors to try and figure out
whose fault it is

Could someone please tell me if this request is valid?

User Datagram Protocol, Src Port: 18646 (18646), Dst Port: domain (53)
Domain Name System (query)
Transaction ID: 0x9b89
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
compliance.georgetown.edu: type A, class IN
Name: compliance.georgetown.edu
Type: A (Host address)
Class: IN (0x0001)
Additional records
: type OPT
Name: 
Type: OPT (EDNS0 option)
UDP payload size: 1280
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x0
Data length: 31
Option: Unknown (20732)
Option Code: Unknown (20732)
Option Length: 27
Option Data:
020248f204656e74310d73757065726773615f6d...
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 12:14 AM, Mohamed Lrhazi  
wrote:

>  Option: Unknown (20732)
> Option Code: Unknown (20732)
> Option Length: 27
> Option Data: 
> 020248f204656e74310d73757065726773615f6d...

I don't know what to make of this - perhaps someone with more clue can weigh in 
. . .

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Wessels, Duane]

Mohamed,

I'd say it is valid.

RFC 6891 says (section 6.1.2) that a client or server should simply ignore 
OPTION-CODE values
that it doesn't know about.  The request should be processed as though that 
funny option
code were not even there.

DW


On Oct 10, 2014, at 10:14 AM, Mohamed Lrhazi  
wrote:

> Hello,
> 
> We have an appliance generating DNS requests that our F5 DNS server is 
> silently dropping... We are working with both vendors to try and figure out 
> whose fault it is 
> 
> Could someone please tell me if this request is valid? 
> 
> User Datagram Protocol, Src Port: 18646 (18646), Dst Port: domain (53)
> Domain Name System (query)
> Transaction ID: 0x9b89
> Flags: 0x0100 Standard query
> Questions: 1
> Answer RRs: 0
> Authority RRs: 0
> Additional RRs: 1
> Queries
> compliance.georgetown.edu: type A, class IN
> Name: compliance.georgetown.edu
> Type: A (Host address)
> Class: IN (0x0001)
> Additional records
> : type OPT
> Name: 
> Type: OPT (EDNS0 option)
> UDP payload size: 1280
> Higher bits in extended RCODE: 0x0
> EDNS0 version: 0
> Z: 0x0
> Data length: 31
> Option: Unknown (20732)
> Option Code: Unknown (20732)
> Option Length: 27
> Option Data: 
> 020248f204656e74310d73757065726773615f6d...
> 
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 12:52 AM, Wessels, Duane  wrote:

> The request should be processed as though that funny option code were not 
> even there.

Maybe the F5 has some kind of 'Invalid DNS Query' filtering function?

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Miek Gieben]

20730 is the old edns client subnet code...
On 10 Oct 2014 19:01, "Roland Dobbins"  wrote:

>
> On Oct 11, 2014, at 12:14 AM, Mohamed Lrhazi <
> mohamed.lrh...@georgetown.edu> wrote:
>
> >  Option: Unknown (20732)
> > Option Code: Unknown (20732)
> > Option Length: 27
> > Option Data:
> 020248f204656e74310d73757065726773615f6d...
>
> I don't know what to make of this - perhaps someone with more clue can
> weigh in . . .
>
> --
> Roland Dobbins  // 
>
>Equo ne credite, Teucri.
>
>   -- Laocoön
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mohamed Lrhazi]

Yes, it clearly thinks these queries are malformed somehow... but are they
actually malformed or otherwise invalid?

I also cant figure out how to reproduce them with dig... The appliance
vendor, Google, tells me that edns0 opt code 20732 must be "the service
name", whatever that means

Thanks a lot,
Mohamed.


On Fri, Oct 10, 2014 at 1:58 PM, Roland Dobbins  wrote:

>
> On Oct 11, 2014, at 12:52 AM, Wessels, Duane 
> wrote:
>
> > The request should be processed as though that funny option code were
> not even there.
>
> Maybe the F5 has some kind of 'Invalid DNS Query' filtering function?
>
> --
> Roland Dobbins  // 
>
>Equo ne credite, Teucri.
>
>   -- Laocoön
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi  
wrote:

> I also cant figure out how to reproduce them with dig...

tcpreplay can be useful for situations like this . . .



--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mukund Sivaraman]

On Fri, Oct 10, 2014 at 05:52:21PM +, Wessels, Duane wrote:
> Mohamed,
> 
> I'd say it is valid.
> 
> RFC 6891 says (section 6.1.2) that a client or server should simply
> ignore OPTION-CODE values that it doesn't know about.  The request
> should be processed as though that funny option code were not even
> there.

There's more to it. Mark has written it up here:

http://tools.ietf.org/html/draft-andrews-edns1-01

Mukund


pgp3uOfi0EKwI.pgp
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi  
wrote:

> The appliance vendor, Google, tells me that edns0 opt code 20732 must be "the 
> service name", whatever that means

I don't know what that means in the context of a non-SRV query . . . can you 
turn off the F5's 'malformed DNS query' scrubbing and see what happens?

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mohamed Lrhazi]

Unfortunately that is not a documented feature. I am waiting on their
support to figure out that they can do... it just silently drops the
packets, even when "query logging" is enabled, it does not even log them!

am very curious as to what this option even means... Who implements it?
BIND?

Mohamed.

On Fri, Oct 10, 2014 at 2:24 PM, Roland Dobbins  wrote:

>
> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi 
> wrote:
>
> > The appliance vendor, Google, tells me that edns0 opt code 20732 must be
> "the service name", whatever that means
>
> I don't know what that means in the context of a non-SRV query . . . can
> you turn off the F5's 'malformed DNS query' scrubbing and see what happens?
>
> --
> Roland Dobbins  // 
>
>Equo ne credite, Teucri.
>
>   -- Laocoön
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 1:33 AM, Mohamed Lrhazi  
wrote:

> I am very curious as to what this option even means... Who implements it? 
> BIND?

It's being generated by whatever the app or stub resolver code is in the Google 
box.

They should know what their own box is doing, heh.

The option code they're using is unassigned, AFAICT.

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Roland Dobbins]

On Oct 11, 2014, at 1:06 AM, Miek Gieben  wrote:

> 20730 is the old edns client subnet code...

This query is using 20732, though . . .

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Hugo Salgado]

On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> 
> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi  
> wrote:
> 
>> The appliance vendor, Google, tells me that edns0 opt code 20732 must be 
>> "the service name", whatever that means
> 
> I don't know what that means in the context of a non-SRV query . . . can you 
> turn off the F5's 'malformed DNS query' scrubbing and see what happens?
> 

Well... F5 is known of misbehavior with its aggressive filtering,
even with  records some time ago:
  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns

Hugo

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Miek Gieben]

[ Quoting  in "Re: [dns-operations] Is this valid ..." ]


On Oct 11, 2014, at 1:06 AM, Miek Gieben  wrote:


20730 is the old edns client subnet code...


This query is using 20732, though . . .


True. Also the rdata of the OPT does not parse a edns client subnet, as the
address family shoud be encoded in the first 2 octets.

/Miek

--
Miek Gieben
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Jared Mauch]

> On Oct 10, 2014, at 2:54 PM, Hugo Salgado  wrote:
> 
> 
> On 10/10/2014 03:24 PM, Roland Dobbins wrote:
>> 
>> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi  
>> wrote:
>> 
>>> The appliance vendor, Google, tells me that edns0 opt code 20732 must be 
>>> "the service name", whatever that means
>> 
>> I don't know what that means in the context of a non-SRV query . . . can you 
>> turn off the F5's 'malformed DNS query' scrubbing and see what happens?
>> 
> 
> Well... F5 is known of misbehavior with its aggressive filtering,
> even with  records some time ago:
>  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns

I’ve never had success with F5 and DNS packet handling properly going all the 
way back to Nov 1998 timeframe.  One of their engineers was troubleshooting it 
in our offices of my employer at the time and ended up upset and saying “why 
doesn’t this work” when it was broken vs being able to properly triage it.

I’m expecting someone from F5 to email me because at the time when I posted 
about the issue on NANOG they were aggressive in trying to defend a public view 
of their product and legitimate technical problems.

- Jared
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mohamed Lrhazi]

F5 are asking me for time to debug.. while Google is saying "All our
appliances do this, nobody else is complaining...".. Just saying, I prefer
the former response so far.

Thanks,
Mohamed.

On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch  wrote:

>
> > On Oct 10, 2014, at 2:54 PM, Hugo Salgado  wrote:
> >
> >
> > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> >>
> >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi <
> mohamed.lrh...@georgetown.edu> wrote:
> >>
> >>> The appliance vendor, Google, tells me that edns0 opt code 20732 must
> be "the service name", whatever that means
> >>
> >> I don't know what that means in the context of a non-SRV query . . .
> can you turn off the F5's 'malformed DNS query' scrubbing and see what
> happens?
> >>
> >
> > Well... F5 is known of misbehavior with its aggressive filtering,
> > even with  records some time ago:
> >  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns
>
> I’ve never had success with F5 and DNS packet handling properly going all
> the way back to Nov 1998 timeframe.  One of their engineers was
> troubleshooting it in our offices of my employer at the time and ended up
> upset and saying “why doesn’t this work” when it was broken vs being able
> to properly triage it.
>
> I’m expecting someone from F5 to email me because at the time when I
> posted about the issue on NANOG they were aggressive in trying to defend a
> public view of their product and legitimate technical problems.
>
> - Jared
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] FW: [IP] Sonic.net implements DNSSEC, performs MITM

[Livingood, Jason]

Noticed this on another list. It made me wonder if it was worth resurrecting & 
trying to publish this old individual I-D, which contained recommendations for 
opt-in and opt-out, among other things that would have been useful in this case.

Old drafts:
http://tools.ietf.org/html/draft-livingood-dns-malwareprotect-02
http://tools.ietf.org/html/draft-livingood-dns-redirect-03

- Jason Livingood


On 10/10/14, 2:33 PM, "Dave Farber via ip" 
mailto:i...@listbox.com>> wrote:

-- Forwarded message --
From: "Lauren Weinstein" mailto:lau...@vortex.com>>
Date: Oct 10, 2014 2:04 PM
Subject: [ NNSquad ] "Sonic.net implements DNSSEC, performs MITM against 
customers. Are they legally liable?"
To: mailto:nnsq...@nnsquad.org>>
Cc:


"Sonic.net implements DNSSEC, performs MITM against customers. Are they
legally liable?"

(Gname): http://permalink.gmane.org/gmane.comp.encryption.general/21150

> Sonic implemented and deployed DNSSEC - and put it on their shiny
> new servers along with an 'RBZ service' that censors supposed malware
> and phishing sites.  And while they told their customers about
> DNSSEC, they didn't mention the 'RBZ service.'
>
> They didn't get prior informed consent from their customers.  In fact
> they didn't inform their customers, beyond quietly putting up a few
> mentions on webpages their customers normally have no reason to look
> at.
>
> They didn't provide a click-through link enabling customers to get the
> content anyway.
>
> And they diverted traffic to a page that does not mention who is doing
> the diversion, how, or why, or how to opt out.
...
> Black hats immediately found a way to get sites they dislike onto
> the list of supposed malware and phishing sites.
>
> Among the blocked sites:
>   Local democratic party campaigners (first post).
>
>   Financial services and markets - at a crucial time. (page 4).
>
>   Software development sites (apparently some devs use the same
>  utility network libraries used by malware devs, so the
>  unknown-because-todays-compilation executables have code
>  in common with known malware and aren't on the whitelist...)

 - - -

--Lauren--
Lauren Weinstein (lau...@vortex.com): 
http://www.vortex.com/lauren
Founder:
 - Network Neutrality Squad: http://www.nnsquad.org
 - PRIVACY Forum: http://www.vortex.com/privacy-info
Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info
Member: ACM Committee on Computers and Public Policy
I am a consultant to Google -- I speak only for myself, not for them.
Lauren's Blog: http://lauren.vortex.com
Google+: http://google.com/+LaurenWeinstein
Twitter: http://twitter.com/laurenweinstein
Tel: +1 (818) 225-2800 / Skype: 
vortex.com
___
nnsquad mailing list
http://lists.nnsquad.org/mailman/listinfo/nnsquad
Archives[https://www.listbox.com/images/feed-icon-10x10.jpg]
 | 
Modify
 Your Subscription | Unsubscribe 
Now
   [https://www.listbox.com/images/listbox-logo-small.png] 

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] 2014 Fall DNS-OARC Workshop PGP Keysigning

[Matthew Pounsett]

I've heard a couple reports that attendees at the meeting this weekend did not 
receive an email I sent through Indico about the PGP keysigning at the meeting. 
 Apologies for that.. I'm using this email to dns-operations to compensate.

The keysigning party will be during the second half of lunch on Sunday.   If 
you wish to participate, please email your key(s) to 
matt.pounsett+keypa...@rightside.co and I'll compile a keyring.  

Please bring a trusted source to read your fingerprint from (such as your PGP 
keyring on your laptop) and ID suitable for identifying yourself to people from 
other countries.

Thanks all.  Apologies for the noise to those of you not attending.
- Matt



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Comments welcome : draft-song-dnsop-ipv6only-dns-00

[Davey Song]

Hi everyone,

I have recently proposed a draft on the IPv6-only DNS deployment. Here is
the abstract of this draft:

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

It is still an early version of a simple idea. I'm writing this letter to
collect the comments and feedback from the community, pro or con, which
will help us to better understand this issue and better preparation for a
IETF draft.

Anyone who will contribute this discussion, thank you in advance.

Best regards,
Davey




DNSOP Working Group  L. Song
Internet-Draft   BII
Intended status: Standards TrackP. Vixie
Expires: April 13, 2015  Farsight Security, Inc.
D. Ma
ZDNS
October 10, 2014


Considerations on IPv6-only DNS
draft-song-dnsop-IPv6only-DNS-00

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 13, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Song, et al. Expires April 13, 2015 [Page 1]

Internet-DraftIPv6-only DNS October 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Revisit to current situation  . . . . . . . . . . . . . . . .   4
 3.1.  DNS Referral Response Size limitation . . . . . . . . . .   4
 3.2.  Additional section in IPv4/IPv6 Environments  . . . . . .   4
 3.3.  DNS proxy . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  An additional DNS architecture  . . . . . . . . . . . . . . .   6
 4.1.  IANA function and operation . . . . . . . . . . . . . . .   6
 4.2.  IPv6-only Root server . . . . . . . . . . . . . . . . . .   8
 4.3.  IPv6-only Recursive Resolver  . . . . . . . . . . . . . .   9
 4.4.  Relations with Existing 13 root . . . . . . . . . . . . .   9
   5.  Risk and Impact Considerations  . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
 9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
 9.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   It's commonly believed that the dual-stack model is the best practice
   for IPv6 transition in which IPv4 and IPv6 function can work in
   parallel without mutual interfe

Re: [dns-operations] latest bind, EDNS & TCP

[Franck Martin]

On Oct 10, 2014, at 9:43 AM, Peter Koch  wrote:

> On Fri, Oct 10, 2014 at 02:53:38PM +0100, Simon Munton wrote:
> 
>> I seem to remember someone saying that the latest version of bind starts 
>> with bufsize=512, but presumably it will learn a larger bufsize 
>> capability, if declared by the responding server?
> 
What I have noticed from my logs, is that bind will fall back to resend the 
query with EDNS size=512 if it does not get an answer, then the answer it gets 
is likely to request to switch to TCP.

This may prove troublesome when fetching some TXT records with low TTL, 
especially the SPF kind… TXT at the organizational level can be overloaded with 
“prove its you” strings.

Set the EDNS advertised size if you are in this situation, to skip one step.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] How to tell bind to ignore DNSSEC for a domain/zone

[Franck Martin]

I see that unbound has a statement to tell, this domain dnssec does not work, 
ignore dnssec validation for it.

How do you do the same with bind?


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Comments welcome : draft-song-dnsop-ipv6only-dns-00

[Franck Martin]

On Oct 10, 2014, at 2:11 PM, Davey Song  wrote:

> Hi everyone,
> 
> I have recently proposed a draft on the IPv6-only DNS deployment. Here is the 
> abstract of this draft:
> 



Can we suppress fragments for DNS on IPv6? At least the document should mention 
more about fragments.

It appeared to me that some software on IPV4 behave in weird ways when a 
hostname has only an  record (and no A). Instead of discarding the hostname 
from the possible solutions, it keeps it and fail in odd ways because of 
“unreachability”. I don’t know if this is true with DNS software, but worth to 
verify.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mark Andrews]

20732 is a little small for a experimental option code but the server
should be ignoring it anyway if it doesn't understand it.

Firewalls are just too picky over DNS queries.  It is well formed
it should be passed.  Let the nameserver behind deal with it.  About
5-6% of nameserver / firewall combinations get this wrong.  There
are well defined behaviours specified in RFC 6891 for how to handle
unknown EDNS options, versions and flags.  The firewall doesn't
need to scrub queries setting any of these.

If your nameserver / firewall is not doing the right thing then
you need to FIX IT!

I'm going to be talking about EDNS compliance at IETF but if you
want to see some pretty graphs http://users.isc.org/~marka/ts.html.

Look for the Firewalls by Type graphs.

The kinks in the AU graphs at the end are due to the graphs being
done on partial datasets.  The run takes a little over 24 hour to
complete and the properties are not uniform over the dataset so
disregard the last data point.

Mark


In message 
, Mohamed Lrhazi writes:
> --===6806851822810879355==
> Content-Type: multipart/alternative; boundary=001a1134e054e208f305051714c1
> 
> --001a1134e054e208f305051714c1
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> F5 are asking me for time to debug.. while Google is saying "All our
> appliances do this, nobody else is complaining...".. Just saying, I prefer
> the former response so far.
> 
> Thanks,
> Mohamed.
> 
> On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch  wrote:
> 
> >
> > > On Oct 10, 2014, at 2:54 PM, Hugo Salgado  wrote:
> > >
> > >
> > > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> > >>
> > >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi <
> > mohamed.lrh...@georgetown.edu> wrote:
> > >>
> > >>> The appliance vendor, Google, tells me that edns0 opt code 20732 must
> > be "the service name", whatever that means
> > >>
> > >> I don't know what that means in the context of a non-SRV query . . .
> > can you turn off the F5's 'malformed DNS query' scrubbing and see what
> > happens?
> > >>
> > >
> > > Well... F5 is known of misbehavior with its aggressive filtering,
> > > even with  records some time ago:
> > >  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns
> >
> > I=E2=80=99ve never had success with F5 and DNS packet handling properly g=
> oing all
> > the way back to Nov 1998 timeframe.  One of their engineers was
> > troubleshooting it in our offices of my employer at the time and ended up
> > upset and saying =E2=80=9Cwhy doesn=E2=80=99t this work=E2=80=9D when it =
> was broken vs being able
> > to properly triage it.
> >
> > I=E2=80=99m expecting someone from F5 to email me because at the time whe=
> n I
> > posted about the issue on NANOG they were aggressive in trying to defend =
> a
> > public view of their product and legitimate technical problems.
> >
> > - Jared
> > ___
> > dns-operations mailing list
> > dns-operations@lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> >
> 
> --001a1134e054e208f305051714c1
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> F5 are asking me for time to debug.. while Google is sayin=
> g "All our appliances do this, nobody else is complaining...".. J=
> ust saying, I prefer the former response so far.Thanks,=
> Mohamed. "gmail_quote">On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch  ">jared@puck=
> .nether.net> wrote: e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> lass=3D"">
> > On Oct 10, 2014, at 2:54 PM, Hugo Salgado  d...@nic.cl">hsalg...@nic.cl> wrote:
> >
> >
> > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> >>
> >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi < mohamed.lrh...@georgetown.edu">mohamed.lrh...@georgetown.edu> wrote:=
> 
> >>
> >>> The appliance vendor, Google, tells me that edns0 opt code 207=
> 32 must be "the service name", whatever that means
> >>
> >> I don't know what that means in the context of a non-SRV query=
>  . . . can you turn off the F5's 'malformed DNS query' scrubbin=
> g and see what happens?
> >>
> >
> > Well... F5 is known of misbehavior with its aggressive filtering,
> > even with  records some time ago:
> >=C2=A0 http://hugo.salga.do/post/50030273426/quad-a-blocking=
> -in-dns" target=3D"_blank">http://hugo.salga.do/post/50030273426/quad-a-blo=
> cking-in-dns
> 
> I=E2=80=99ve never had success with F5 and DNS packet handling prope=
> rly going all the way back to Nov 1998 timeframe.=C2=A0 One of their engine=
> ers was troubleshooting it in our offices of my employer at the time and en=
> ded up upset and saying =E2=80=9Cwhy doesn=E2=80=99t this work=E2=80=9D whe=
> n it was broken vs being able to properly triage it.
> 
> I=E2=80=99m expecting someone

Re: [dns-operations] How to tell bind to ignore DNSSEC for a domain/zone

[Livingood, Jason]

Ah! A Negative Trust Anchor. :-)

>From an upcoming draft on the subject. Let me know if you think this does
the trick or not.

You can achive this functionality by disabling all DNSSEC algorithms
   for a zone.  The operator can see which algorithms the zone is using,
   or simply disable all supported algorithms.

   This gets placed in the "global options" section of the config file.

   disable-algorithms "foo.example.com." {"RSAMD5", "RSA", "DH",
 "DSA", "NSEC3DSA", "ECC", "RSASHA1", "NSEC3RSASHA1",
 "RSASHA256", "RSASHA512", "ECCGOST", "ECDSAP256SHA256",
 "ECDSAP384SHA384"; };



- Jason

On 10/10/14, 5:56 PM, "Franck Martin"  wrote:

>I see that unbound has a statement to tell, this domain dnssec does not
>work, ignore dnssec validation for it.
>
>How do you do the same with bind?


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] FW: [IP] Sonic.net implements DNSSEC, performs MITM

[Mark Andrews]

Assign a couple of EDNS option code points and if the response
should potentially be filtered return those code points with a
filter code and a optional url as the payload which lands on a page
describing why the response should be filtered along with the normal
response.  Supporting servers would return the empty option code
if there is not data so that direct request could be avoided.

The clients can then make a sensible decision based on the returned
code points. 

e.g.
Adult Only  - added by authoritative servers and/or rpz
  like mechanism
15+ - added by authoritative servers
12+ - added by authoritative servers
Gambling- added by authoritative servers and/or rpz 
  like mechanism
Malware - added by a rpz like mechanism and authoritative
  servers for sites which are host malware for
  research purposes.

Some of the above are subjective and would be set based on the rules
of the juristiction the primary server is located in.

Add to that a new DNS data type (FILTER) which allows operators to tell
servers to add this code to responses.  An authoratitive server would
look for a FILTER RRset when responding and extract the matching
QTYPE to populate the EDNS response.

FILTER QTYPE CODE [ URL ]

The records could also be directly queried for when you don't get
a response with the option code set.

I suspect most Adult Only sites would add support for this.  They
really don't want under age users and this is a way for them to be
pro-active about stopping under age users using the site.

Web browers can add support for this without requiring the resolver
library to be updated.

In message , "Livingood, 
Jason" writes:
> 
> Noticed this on another list. It made me wonder if it was worth resurrectin=
> g & trying to publish this old individual I-D, which contained recommendati=
> ons for opt-in and opt-out, among other things that would have been useful =
> in this case.
> 
> Old drafts:
> http://tools.ietf.org/html/draft-livingood-dns-malwareprotect-02
> http://tools.ietf.org/html/draft-livingood-dns-redirect-03
> 
> - Jason Livingood
> 
> 
> On 10/10/14, 2:33 PM, "Dave Farber via ip" mailto:ip@listbo=
> x.com>> wrote:
> 
> -- Forwarded message --
> From: "Lauren Weinstein" mailto:lau...@vortex.com>>
> Date: Oct 10, 2014 2:04 PM
> Subject: [ NNSquad ] "Sonic.net implements DNSSEC, performs MITM against cu=
> stomers. Are they legally liable?"
> To: mailto:nnsq...@nnsquad.org>>
> Cc:
> 
> 
> "Sonic.net implements DNSSEC, performs MITM against customers. Are they
> legally liable?"
> 
> (Gname): http://permalink.gmane.org/gmane.comp.encryption.general/21150
> 
> > Sonic implemented and deployed DNSSEC - and put it on their shiny
> > new servers along with an 'RBZ service' that censors supposed malware
> > and phishing sites.  And while they told their customers about
> > DNSSEC, they didn't mention the 'RBZ service.'
> >
> > They didn't get prior informed consent from their customers.  In fact
> > they didn't inform their customers, beyond quietly putting up a few
> > mentions on webpages their customers normally have no reason to look
> > at.
> >
> > They didn't provide a click-through link enabling customers to get th=
> e
> > content anyway.
> >
> > And they diverted traffic to a page that does not mention who is doin=
> g
> > the diversion, how, or why, or how to opt out.
> ...
> > Black hats immediately found a way to get sites they dislike onto
> > the list of supposed malware and phishing sites.
> >
> > Among the blocked sites:
> >   Local democratic party campaigners (first post).
> >
> >   Financial services and markets - at a crucial time. (page 4).
> >
> >   Software development sites (apparently some devs use the same
> >  utility network libraries used by malware devs, so the
> >  unknown-because-todays-compilation executables have code
> >  in common with known malware and aren't on the whitelist...)
> 
>  - - -
> 
> --Lauren--
> Lauren Weinstein (lau...@vortex.com): http://www.=
> vortex.com/lauren
> Founder:
>  - Network Neutrality Squad: http://www.nnsquad.org
>  - PRIVACY Forum: http://www.vortex.com/privacy-info
> Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-in=
> fo
> Member: ACM Committee on Computers and Public Policy
> I am a consultant to Google -- I speak only for myself, not for them.
> Lauren's Blog: http://lauren.vortex.com
> Google+: http://google.com/+LaurenWeinstein
> Twitter: http://twitter.com/laurenweinstein
> Tel: +1 (818) 225-2800 / Skype: vortex.com=
> 
> ___
> nnsquad mailing list
> http://lists.nnsquad.org/mailman/listinfo/nnsquad
> Archives

Re: [dns-operations] Is this valid edns0 query?

[Mohamed Lrhazi]

Thanks Mark. Where do I get the dig with +ednsopt ?

root@5df5dd95aeae:/# dig -v
DiG 9.10.1
root@5df5dd95aeae:/# dig -h|grep edns
 +subnet=addr(Set edns-client-subnet option)
 +[no]edns[=###] (Set EDNS version) [0]
root@5df5dd95aeae:/#
root@5df5dd95aeae:/# dig +ednsopt=100
Invalid option: +ednsopt=100



On Fri, Oct 10, 2014 at 6:10 PM, Mark Andrews  wrote:

>
> 20732 is a little small for a experimental option code but the server
> should be ignoring it anyway if it doesn't understand it.
>
> Firewalls are just too picky over DNS queries.  It is well formed
> it should be passed.  Let the nameserver behind deal with it.  About
> 5-6% of nameserver / firewall combinations get this wrong.  There
> are well defined behaviours specified in RFC 6891 for how to handle
> unknown EDNS options, versions and flags.  The firewall doesn't
> need to scrub queries setting any of these.
>
> If your nameserver / firewall is not doing the right thing then
> you need to FIX IT!
>
> I'm going to be talking about EDNS compliance at IETF but if you
> want to see some pretty graphs http://users.isc.org/~marka/ts.html.
>
> Look for the Firewalls by Type graphs.
>
> The kinks in the AU graphs at the end are due to the graphs being
> done on partial datasets.  The run takes a little over 24 hour to
> complete and the properties are not uniform over the dataset so
> disregard the last data point.
>
> Mark
>
>
> In message <
> caeu_gmez8jcgw8adkir8cdp0ackivvfwuyvy1rpv4jkd9dt...@mail.gmail.com>
> , Mohamed Lrhazi writes:
> > --===6806851822810879355==
> > Content-Type: multipart/alternative;
> boundary=001a1134e054e208f305051714c1
> >
> > --001a1134e054e208f305051714c1
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> >
> > F5 are asking me for time to debug.. while Google is saying "All our
> > appliances do this, nobody else is complaining...".. Just saying, I
> prefer
> > the former response so far.
> >
> > Thanks,
> > Mohamed.
> >
> > On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch 
> wrote:
> >
> > >
> > > > On Oct 10, 2014, at 2:54 PM, Hugo Salgado  wrote:
> > > >
> > > >
> > > > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> > > >>
> > > >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi <
> > > mohamed.lrh...@georgetown.edu> wrote:
> > > >>
> > > >>> The appliance vendor, Google, tells me that edns0 opt code 20732
> must
> > > be "the service name", whatever that means
> > > >>
> > > >> I don't know what that means in the context of a non-SRV query . . .
> > > can you turn off the F5's 'malformed DNS query' scrubbing and see what
> > > happens?
> > > >>
> > > >
> > > > Well... F5 is known of misbehavior with its aggressive filtering,
> > > > even with  records some time ago:
> > > >  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns
> > >
> > > I=E2=80=99ve never had success with F5 and DNS packet handling
> properly g=
> > oing all
> > > the way back to Nov 1998 timeframe.  One of their engineers was
> > > troubleshooting it in our offices of my employer at the time and ended
> up
> > > upset and saying =E2=80=9Cwhy doesn=E2=80=99t this work=E2=80=9D when
> it =
> > was broken vs being able
> > > to properly triage it.
> > >
> > > I=E2=80=99m expecting someone from F5 to email me because at the time
> whe=
> > n I
> > > posted about the issue on NANOG they were aggressive in trying to
> defend =
> > a
> > > public view of their product and legitimate technical problems.
> > >
> > > - Jared
> > > ___
> > > dns-operations mailing list
> > > dns-operations@lists.dns-oarc.net
> > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > > dns-jobs mailing list
> > > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> > >
> >
> > --001a1134e054e208f305051714c1
> > Content-Type: text/html; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> >
> > F5 are asking me for time to debug.. while Google is
> sayin=
> > g "All our appliances do this, nobody else is
> complaining...".. J=
> > ust saying, I prefer the former response so
> far.Thanks,=
> > Mohamed. class=3D=
> > "gmail_quote">On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch  dir=3D"ltr=
> > "> target=3D"_blank">jared@puck=
> > .nether.net> wrote: styl=
> > e=3D"margin:0 0 0 .8ex;border-left:1px #ccc
> solid;padding-left:1ex"> > lass=3D"">
> > > On Oct 10, 2014, at 2:54 PM, Hugo Salgado < hsalga=
> > d...@nic.cl">hsalg...@nic.cl> wrote:
> > >
> > >
> > > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> > >>
> > >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi < href=3D"mailto:=
> > mohamed.lrh...@georgetown.edu">mohamed.lrh...@georgetown.edu>
> wrote:=
> > 
> > >>
> > >>> The appliance vendor, Google, tells me that edns0 opt code
> 207=
> > 32 must be "the service name", whatever that means
> > >>
> > >> I don't know what that means in the context of a non-SRV
> query=
>

Re: [dns-operations] DNS BoF@DNS OARC 2014 Fall LA

[Keith Mitchell]

On 10/11/2014 01:43 AM, han feng wrote:

> We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we 
> wanted to  
> share the test report regarding to DNS dynamic update and xfr (please refer 
> to the 
> attachment), and ask your opinions on the topics that we should cover on this 
> BoF.

I'd just like to make it clear that this proposed event is not part of
the OARC workshop programme.

Keith


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNS BoF@DNS OARC 2014 Fall LA

[han feng]

Yes, this is not official. It’s a “bar BOF”.

> On 10/11/2014 01:43 AM, han feng wrote:
> 
>> We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we 
>> wanted to  
>> share the test report regarding to DNS dynamic update and xfr (please refer 
>> to the 
>> attachment), and ask your opinions on the topics that we should cover on 
>> this BoF.
> 
> I'd just like to make it clear that this proposed event is not part of
> the OARC workshop programme.
> 
> Keith
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNS BoF@DNS OARC 2014 Fall LA

[Mehmet Akcin]

thank you for clarification Keith, i was confused.



> On Oct 10, 2014, at 10:49 PM, Keith Mitchell  wrote:
> 
>> On 10/11/2014 01:43 AM, han feng wrote:
>> 
>> We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we 
>> wanted to  
>> share the test report regarding to DNS dynamic update and xfr (please refer 
>> to the 
>> attachment), and ask your opinions on the topics that we should cover on 
>> this BoF.
> 
> I'd just like to make it clear that this proposed event is not part of
> the OARC workshop programme.
> 
> Keith
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Is this valid edns0 query?

[Mark Andrews]

In message 
, Mohamed 
Lrhazi writes:
> 
> Thanks Mark. Where do I get the dig with +ednsopt ?

https://source.isc.org  You will need the master branch +ednsopt
will be in BIND 9.11.

dig +sit / +nsid / +expire all add edns options to the query and are
available in BIND 9.10

> root@5df5dd95aeae:/# dig -v
> DiG 9.10.1
> root@5df5dd95aeae:/# dig -h|grep edns
>  +subnet=addr(Set edns-client-subnet option)
>  +[no]edns[=###] (Set EDNS version) [0]
> root@5df5dd95aeae:/#
> root@5df5dd95aeae:/# dig +ednsopt=100
> Invalid option: +ednsopt=100
> 
> 
> 
> On Fri, Oct 10, 2014 at 6:10 PM, Mark Andrews  wrote:
> 
> >
> > 20732 is a little small for a experimental option code but the server
> > should be ignoring it anyway if it doesn't understand it.
> >
> > Firewalls are just too picky over DNS queries.  It is well formed
> > it should be passed.  Let the nameserver behind deal with it.  About
> > 5-6% of nameserver / firewall combinations get this wrong.  There
> > are well defined behaviours specified in RFC 6891 for how to handle
> > unknown EDNS options, versions and flags.  The firewall doesn't
> > need to scrub queries setting any of these.
> >
> > If your nameserver / firewall is not doing the right thing then
> > you need to FIX IT!
> >
> > I'm going to be talking about EDNS compliance at IETF but if you
> > want to see some pretty graphs http://users.isc.org/~marka/ts.html.
> >
> > Look for the Firewalls by Type graphs.
> >
> > The kinks in the AU graphs at the end are due to the graphs being
> > done on partial datasets.  The run takes a little over 24 hour to
> > complete and the properties are not uniform over the dataset so
> > disregard the last data point.
> >
> > Mark
> >
> >
> > In message <
> > caeu_gmez8jcgw8adkir8cdp0ackivvfwuyvy1rpv4jkd9dt...@mail.gmail.com>
> > , Mohamed Lrhazi writes:
> > > --===6806851822810879355==
> > > Content-Type: multipart/alternative;
> > boundary=001a1134e054e208f305051714c1
> > >
> > > --001a1134e054e208f305051714c1
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > F5 are asking me for time to debug.. while Google is saying "All our
> > > appliances do this, nobody else is complaining...".. Just saying, I
> > prefer
> > > the former response so far.
> > >
> > > Thanks,
> > > Mohamed.
> > >
> > > On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch 
> > wrote:
> > >
> > > >
> > > > > On Oct 10, 2014, at 2:54 PM, Hugo Salgado  wrote:
> > > > >
> > > > >
> > > > > On 10/10/2014 03:24 PM, Roland Dobbins wrote:
> > > > >>
> > > > >> On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi <
> > > > mohamed.lrh...@georgetown.edu> wrote:
> > > > >>
> > > > >>> The appliance vendor, Google, tells me that edns0 opt code 20732
> > must
> > > > be "the service name", whatever that means
> > > > >>
> > > > >> I don't know what that means in the context of a non-SRV query . . .
> > > > can you turn off the F5's 'malformed DNS query' scrubbing and see what
> > > > happens?
> > > > >>
> > > > >
> > > > > Well... F5 is known of misbehavior with its aggressive filtering,
> > > > > even with  records some time ago:
> > > > >  http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns
> > > >
> > > > I=E2=80=99ve never had success with F5 and DNS packet handling
> > properly g=
> > > oing all
> > > > the way back to Nov 1998 timeframe.  One of their engineers was
> > > > troubleshooting it in our offices of my employer at the time and ended
> > up
> > > > upset and saying =E2=80=9Cwhy doesn=E2=80=99t this work=E2=80=9D when
> > it =
> > > was broken vs being able
> > > > to properly triage it.
> > > >
> > > > I=E2=80=99m expecting someone from F5 to email me because at the time
> > whe=
> > > n I
> > > > posted about the issue on NANOG they were aggressive in trying to
> > defend =
> > > a
> > > > public view of their product and legitimate technical problems.
> > > >
> > > > - Jared
> > > > ___
> > > > dns-operations mailing list
> > > > dns-operations@lists.dns-oarc.net
> > > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > > > dns-jobs mailing list
> > > > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> > > >
> > >
> > > --001a1134e054e208f305051714c1
> > > Content-Type: text/html; charset=UTF-8
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > F5 are asking me for time to debug.. while Google is
> > sayin=
> > > g "All our appliances do this, nobody else is
> > complaining...".. J=
> > > ust saying, I prefer the former response so
> > far.Thanks,=
> > > Mohamed. > class=3D=
> > > "gmail_quote">On Fri, Oct 10, 2014 at 3:20 PM, Jared Mauch  > dir=3D"ltr=
> > > "> > target=3D"_blank">jared@puck=
> > > .nether.net> wrote: > styl=
> > > e=3D"margin:0 0 0 .8ex;border-left:1px #ccc
> > solid;padding-left:1ex"> > > lass=3D"">
> > > > On Oct 10, 2014, at 2:54 PM, Hugo Salgado <