[dns-operations] latest bind, EDNS & TCP

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 pre

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

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) ove

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

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 wrot

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

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

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

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 d

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

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

[dns-operations] Is this valid edns0 query?

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

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

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 so

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

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 wro

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

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 Dob

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

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: 2

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

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

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

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 Dobb

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

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 w

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

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' scr

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

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? Mohame

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

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 the

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

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, Te

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

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 que

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

[ 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

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

> 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

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

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

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

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-dn

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

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

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

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 de

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

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 res

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

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-o

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

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

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

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 comb

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

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 supp

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

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

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

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:/

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

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 th

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

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

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

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 dyna

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

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:/