Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

* Daisuke HIGASHI: > draft-fujiwara-dnsop-fragment-attack-01: > >> 3. Current status >> >> [Brandt2018] showed that Linux version 3.13 and older versions are >> vulnerable to crafted ICMP fragmentation needed and DF set packet and >> off-path attackers can set some of authoritative

Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

* Tim Wicinski: > For the ZONEMD RR Type, where in the registry do the authors think it > should go? While some of that falls on the Expert Review process, I think > the document authors should capture their rationale in the document. If > the proposed RR Type is greater than 256 (which I

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

* John R. Levine: > On Sat, 28 Jul 2018, Florian Weimer wrote: >> A malicious server might never stop sending data, or claim that the >> transfer is ridiculously large. If the zone digest does not include >> information about the amount of data, this can only be detecte

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

* Paul Wouters: > Another reason for an rr count number in the rrtype. The typical RR size is perhaps 1/300 of the protocol maximum (much less without DNSSEC), so this is only sufficient for small zones. ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

* John R. Levine: that the served zone is too large. Otherwise, the receiver has to download the entire zone before it can determine that the hash does not match. ... > >> On the other hand, clients will likely have a pretty good idea for the >> size of the zone, so they could

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

* John Levine: > In article <87h8kp7sqf@mid.deneb.enyo.de> you write: >>The ZONEMD record should contain a size indicator for the zone, >>something that allows a receiver to stop downloading if it is clear >>that the served zone is too large. Otherwise, the receiver has to >>download the

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

* Duane Wessels: > I wouldn't be opposed to this in principle -- say an RR count field. That doesn't really bound the amount of transferred data, I think, because RR size can still vary widely. I believe something that counts the hashed bytes would be more helpful and about as easy to

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

The ZONEMD record should contain a size indicator for the zone, something that allows a receiver to stop downloading if it is clear that the served zone is too large. Otherwise, the receiver has to download the entire zone before it can determine that the hash does not match.

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

* Paul Vixie: > in other words we should re-order rrsets by default, so that very few > people or agents are ever prone to think their order is stable. the spec > says they are unordered, but human nature says, expect more of what > you're seeing. But the client has to sort them again based

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On 06/15/2018 05:45 PM, Erik Nygren wrote: I suspect starting assumptions are roughly in the range of: * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin in RRset responses. * There are a variety of ways to implement round-robin (randomize, permute, etc). *

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

On 04/13/2018 04:47 PM, bert hubert wrote: 2) Try: ping goes-via-embedded-nul.tdns.powerdns.org ping goes-via-embedded-space.tdns.powerdns.org. ping goes-via-embedded-dot.tdns.powerdns.org. None of these resolve when I try them, I wonder if that is because implementations want

Re: [DNSOP] Clarifying referrals (#35)

On 11/28/2017 08:50 PM, Andrew Sullivan wrote: That leaves the task of the referrals definition. I have some new text below: ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an

Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

On 09/21/2017 06:50 AM, Paul Vixie wrote: both ideas are wrong. what we have to do is arrange to fragment, using the ipv6 extension header, all ipv6 udp, for a period of not less than five years. noone who blocks ipv6 extension headers should be able to get reliable ipv6 udp services. we have

Re: [DNSOP] RCODE and CNAME chain

On 04/27/2017 11:31 AM, Mark Andrews wrote: If you want to advocate for changes to behaviour that is fine, but advocate for that. Just saying "shouldn't the rcode be NOERROR" isn't doing that. Then there is DNSSEC. If the target zone is signed and DO=1 is set in the query should you include

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/20/2017 08:36 AM, Evan Hunt wrote: On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote: ANAME could just be a regular RRTYPE without any special handling, meaning "go look there for up to date information on A/". It could come along A/ records using one of the existing

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 10:47 PM, Evan Hunt wrote: On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: And in order to accommodate them, we upgrade the DNS server infrastructure across the Internet? Them, and web browser implementers who just don't want to use SRV. SRV wouldn't work

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 10:16 PM, Evan Hunt wrote: On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: I don't see how you can detect loops without DNS protocol changes. The query that comes back will look like a completely fresh query. We can put a limit on the number of hops

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 10:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:39, Florian Weimer <fwei...@redhat.com> wrote: On 04/11/2017 09:15 PM, Tony Finch wrote: That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. I

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 09:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:09, Florian Weimer <fwei...@redhat.com> wrote: On 04/11/2017 08:42 PM, Tony Finch wrote: If you have a subdomain that needs to be a mail domain and a web site, you need an MX pointing at your mail server and address r

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/10/2017 12:04 PM, Peter van Dijk wrote: Section 3 is currently written in such a way that a recursive DNS lookup must be performed at the authoritative server side. I don't think it is necessary to require that. A recursive DNS lookup of the target is just one way to implement this.

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 08:42 PM, Tony Finch wrote: Paul Wouters wrote: Can you give me an example of deploying ANAME outside the zone APEX that is not solved by allowing a CNAME to point to a CNAME (which most code I think already allows anyway)

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/11/2017 05:45 PM, Tony Finch wrote: Florian Weimer <fwei...@redhat.com> wrote: I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. You can't replace an entire zone with a CNAME if

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

On 04/07/2017 08:11 PM, Evan Hunt wrote: Title: Address-specific DNS Name Redirection (ANAME) I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. Section 3 is currently written in such a way

Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?

* Mark Andrews: > In message <87bmz3p4lt@mid.deneb.enyo.de>, Florian Weimer writes: >> * Robert Edmonds: >> >> > I think there was already a thread on this topic recently on this list >> > ("Order of CNAME and A in Authoritative Reply" from

Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?

* Robert Edmonds: > I think there was already a thread on this topic recently on this list > ("Order of CNAME and A in Authoritative Reply" from August 2015). There > was some discussion over "adding" versus "appending" and it was pointed > out that a lot of existing code (e.g., the BSD stub

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On 03/23/2016 09:03 PM, Andrew Sullivan wrote: > I don't understand how it's a way to evaluate this claim. DNSSEC > includes a bit (DO) that says you're prepared to handle the additional > data in the answer section. Indeed, the unpreparedness of people for > this data was just exactly the

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On 03/22/2016 12:45 AM, Marek Vavruša wrote: > there was an interest in reducing latency for address record lookups. > Me and Olafur wrote a draft on adding records to A answers and > treating them as authoritative. This fixes latency issues with NS > A/ discovery in resolvers and

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On 03/22/2016 01:15 AM, Paul Vixie wrote: > > > Marek Vavruša wrote: >> ... >> >> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/ > > +1. we ought to have done this from the get-go. It did not work back then because unexpected RRsets in the answer broke resolvers. This is

Re: [DNSOP] Big reduction in the number of TLD zones blocking EDNS(1) queries

an unscheduled security update. If you were running BIND 9.3 before, you are essentially running it afterwards as well. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

* Stephane Bortzmeyer: On Wed, Jul 15, 2015 at 02:22:58PM -0700, Francisco Obispo fobi...@uniregistry.com wrote a message of 48 lines which said: Well, even worse, what happens if name-your-next-OS-vendor decides to create a new dns-like protocol that uses .foo, does that mean that we

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

* Olafur Gudmundsson: On Mar 18, 2015, at 11:55 AM, Paul Vixie p...@redbarn.org wrote: we need a document that says If you don't want to answer ANY, here's how to do it interoperably. we don't need to say you should not answer ANY, but we do need to say if you want to query for ANY, here's

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

” took more than a decade if I remember correctly, and it did not benefit just Apple. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CloudFlare policy on ANY records changing

* Evan Hunt: On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote: So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making

Re: [DNSOP] CloudFlare policy on ANY records changing

* Tony Finch: Evan Hunt e...@isc.org wrote: This could be a pretty brilliant solution, actually: If you're authoritative for a signed zone and you receive a query of type ANY, return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize a response containing a single RR

Re: [DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries

* Tim Wicinski: This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries The draft is available here: https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/ No real comments on adoptions below, just some technical issues. Is there are definition now what constitutes

Re: [DNSOP] CloudFlare policy on ANY records changing

* Evan Hunt: (It doesn't address qmail's problem, but that's a lost cause no matter which method is chosen.) I think it does. qmail already copes correctly with a partially cached ANY response (due to TTL mismatch between RRset), does it? The new behavior just looks like a partially cached

Re: [DNSOP] Definition of validating resolver

* Ted Lemon: On Mar 8, 2015, at 6:31 PM, Ralf Weber d...@fl1ger.de wrote: I was told that the difference is that a security aware resolver does not validate, but instead relies on the Validating Stub Resolver to protect the user. So it would handle all the DNSSEC processing to the

Re: [DNSOP] CloudFlare policy on ANY records changing

* Tony Finch: I also tried a stupid hack to send an ANY RR in the response. BIND's resolver treats this as a FORMERR and returns SERVFAIL to the client. What about introducing a new non-meta RR type for this purpose? It would not increase the response size by much.

Re: [DNSOP] Comments regarding the NSEC5

-term keys baked into software, but short/medium-term keys which are easily replaced. And does anyone actually use opt out with NSEC3? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo

Re: [DNSOP] Comments regarding the NSEC5

should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? You really need to make this explicit. I agree that the description is insufficient. We will fix that. Thanks. -- Florian

[DNSOP] Comments regarding the NSEC5

. As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Florian -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

* John Heidemann: DNS over TCP/53 is *already* persistent. No *protocol* changes are needed. If you want to make the connections full-duplex instead of half-duplex, you need to negotiate connection teardown at the DNS layer. Otherwise, the TCP connection teardown will result in loss of

Re: [DNSOP] Extended CNAME (ENAME)

* Mark Andrews: ENAME could be used immediately once the authoritative servers for the zone support it. It would just be insecure until validators catch up. Uhm. Why insecure and not bogus? ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] DNS privacy : now at least two drafts

* Mark Andrews: In message 87y50auqqf@mid.deneb.enyo.de, Florian Weimer writes: * Mark Andrews: Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has

Re: [DNSOP] DNS privacy : now at least two drafts

* Florian Weimer: There is another privacy-enhancing approach that is not mentioned in the draft: defensive delegations. For example, with current resolver behavior, the lack of a delegation for 1.E164.ARPA means that queries under that tree are sent to the E164.ARPA servers, which

Re: [DNSOP] An approach to DNS privacy

* Phillip Hallam-Baker: If your ordinary resolver operator is a carrier is somewhat questionable, but resolver operators generally comply with requests for cleartext copies of traffic transitioning through their networks. I have no doubts that these operators will ask implementors to add the

Re: [DNSOP] DNS privacy : now at least two drafts

* Mark Andrews: Another note is that the answer to the NS query, unlike the referral sent when the question is a full qname, is in the Answer section, not in the Authoritative section. It has probably no practical consequences. Most resolvers do not make NS queries, and some

Re: [DNSOP] An approach to DNS privacy

* Phillip Hallam-Baker: For a heavily trafficked resolver, the resolver-authoritative interaction can be addressed with caching and by pre-fetching the bulk of the requests. But this approach does not work so well for the lightly trafficked resolver and especially not a local resolver

Re: [DNSOP] An approach to DNS privacy

* Phillip Hallam-Baker: But first, cite actual legal authority because I don't believe your interpretation of the law is remotely correct. § 8 Abs. 3 TKÜV: | Wenn der Verpflichtete die ihm zur Übermittlung anvertraute | Telekommunikation netzseitig durch technische Maßnahmen gegen | unbefugte

Re: [DNSOP] DNS privacy : now at least two drafts

* Stephane Bortzmeyer: I just posted a new version of the DNS privacy draft, draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference is that it is now split in two, one pure problem statement, draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible solutions,

Re: [DNSOP] DNS privacy : now at least two drafts

* Stephane Bortzmeyer: On Sat, Mar 08, 2014 at 05:50:55PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 22 lines which said: The -sol draft mentions QNAME minimization without defining the term. It is. Section 2.2.2 Can you quote it here? It seems to be missing from

Re: [DNSOP] DNS privacy : now at least two drafts

* Stephane Bortzmeyer: On Sat, Mar 08, 2014 at 06:07:48PM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 17 lines which said: It is. Section 2.2.2 Can you quote it here? 2.2.2. In the authoritative name servers Ahhh, this section heading is wrong, the section

Re: [DNSOP] Data model and field names for DNS in JSON or XML

* Stephane Bortzmeyer: I'm aware of draft-mohan-dns-query-xml, which partially solves my problem (except I would like the RDATA to be structured as well, not a blob of hexadecimal data). In this area, draft-levine-dnsextlang-00 might be helpful. -- Florian Weimerfwei

Re: [DNSOP] DNS Server Selection document last call in MIF

? I can't see how this can be implemented on top of the BSD sockets API, especially not with the weak end system model. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe

Re: [DNSOP] Do negative cache entries have to be consistent ?

should receive longer TTLs. In the non-DNSSEC case, you can simply return a SOA record whose owner name is the full QNAME. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe

Re: [DNSOP] [dnsext] Fwd: Last Call: draft-cheshire-dnsext-special-names-01.txt (Special-Use Domain Names) to Proposed Standard

? Then you might be right in the sense that the IETF cannot set aside names for use at the protocol level. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

the DNSSEC deployment in the parent zone. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

completely (in the sense that you can register a crafted org domain name and get an RRSIG from org that fits example.org as well, with private key material known to you). -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100

Re: [DNSOP] Priming query transport selection

) if [4] fails DO is rather pointless because the priming response cannot be validated anyway (even if ROOT-SERVERS.NET were secure, which is currently not planned). -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel

Re: [DNSOP] Priming query transport selection

* Jim Reid: On 15 Jan 2010, at 13:20, Florian Weimer wrote: DO is rather pointless because the priming response cannot be validated anyway (even if ROOT-SERVERS.NET were secure, which is currently not planned). It's not pointless. Validating the priming response requires two operations

Re: [DNSOP] [dnsext] Computerworld apparently has changed DNS protocol

* Alfred Hönes: There must be a hidden trick to introduce DNS Jumbograms we just forgot to mention The claims about firewall issues seems dubious to me. It's certainly not the 512 byte limit which is a problem here---I think we've got pretty good empiric evidence that it's not a problem

Re: [DNSOP] Computerworld apparently has changed DNS protocol

* David Blacka: I actually researched this, and need to spend some time cleaning up the report before posting it to this list. But the bottom line is that yes, all responses save a few at the apex of root are below 1500b (actually, below 1100b). The responses that are larger are . rrsig

Re: [DNSOP] [dnsext] Re: Computerworld apparently has changed DNS protocol

* Nicholas Weaver: Also, has someone done a study what the major recursive resolvers do on response failures from a root? Do they go to another first or do they try a smaller EDNS MTU? Note that switching seems beneficial because six roots MTUs clearly support MTUs less than 1500, and seven

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

* Mark Andrews: For LOCAL.ARPA to be accepted you need a break in the DNSSEC trust chain. Mark, I din't think this is true given how the proposed protocol works. For a start, you often cannot fetch the DNSKEY RR for ARPA before running the protocol. -- Florian Weimerfwei

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

we need is agreement from both ICANN and IETF that LOCAL.ARPA is reserved and not to be delegated in the official tree. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

* Alex Bligh: --On 21 October 2009 08:34:39 + Florian Weimer fwei...@bfk.de wrote: Mark, I din't think this is true given how the proposed protocol works. For a start, you often cannot fetch the DNSKEY RR for ARPA before running the protocol. Indeed LOCAL.ARPA would need

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

of spoofing, unless the spoofing resolver has specific support for this protocol. It's not someone could do evil things and make it break, but someone already does (perhaps evil) things, and it breaks. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

this protocol due to widespread DNS poisoning. I wholeheartedly support the creation of LOCAL.ARPA, though. But you should mention that mDNS MUST NOT be used for LOCAL.ARPA (so that some people don't get funny ideas). -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

. If the powers that be finally agree to make NXDOMAIN/NODATA synthesis the default in the upcoming minor DNSSEC revision, this will also help to cut down the number of requests. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100

Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...

in the root, and world can check it with me, using dig. Have you already got this self-service capability for non-DS changes? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe

Re: [DNSOP] how DNS redirect works with empty response

* JINMEI Tatuya / 神明達哉: What does a recursive server that implements the DNS redirect service do in this case? Empty responses are typically rewritten. NXDOMAIN redirect is a misnomer. then I guess authoritative server implementors who don't like NXDOMAIN redirect could introduce a

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Alan Barrett: I think that this sort of lying recursive resolver is a bad idea. Instead, I suggest a new SUGGESTION RR type that could be returned in the additional section of an error message. For example, if you ask for www.example.invalid, you could get back an NXDOMAIN error, with

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Paul Hoffman: Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. Which ones? Currently, when a user enters mcrsoft in the address bar, many browsers will automatically send her to the Microsoft homepage. With spoofed answers, he

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Tony Finch: On Thu, 16 Jul 2009, Florian Weimer wrote: (But I agree that a clean solution requires protocol development.) No, it just requires browser user interface improvements. If you want to address the issue with hotspot doorway pages, you need protocol changes

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Jason Livingood: Actual consumer behavior doesn¹t really seem to work that way, but I¹m not a behavioral psychologist. ;-) FWIW, I think most ISPs that introduce such services see around a 0.1% opt-out rate. I would expect a higher rate of Dnschange/Zlob infections at a typical

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Tony Finch: On Thu, 16 Jul 2009, Florian Weimer wrote: If you want to address the issue with hotspot doorway pages, you need protocol changes. Better to use an intercepting proxy in that case, and for quarantining infected hosts. Doesn't work if the user uses the employer's filtering

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Ralf Weber: That really is an issue and could be addressed, there are a lot of case where a A record for a domain doesn't exists, but one for www.domain does exist. True, and some browser have code to deal with this. Question then would be how that rewrite should be presented. As a

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Jelte Jansen: Ralf Weber wrote: No redirection on SERVFAIL seems to be a strange recommendation. Wouldn't this be a very good reason to provide a diagnostics page, especially if there's been a DNSSEC validation failure? This sounds like an excellent idea to help DNSSEC adoption and is

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Stephane Bortzmeyer: Unless I'm wrong, the I-D about lying resolvers do not discuss the issue of zone cuts. If I type www.doesnotexistatall.com (the SLD does not exist and so I should get a NXDOMAIN), I get the IP address of the ad Web server. If I type .afnic.fr, I will get this IP

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

* Jason Livingood: If anyone is interested and has time before IETF 75, I¹m happy to take feedback before then obviously. Few players perform NXDOMAIN rewriting. Instead, ANCOUNT=0 rewriting is used. This causes all kinds of problems, including redirections for example.com when it hasn't got

Re: [DNSOP] Problems with DS change in registry/registrar environment

likely no way to make zone changes in a way that pleases all resolvers. So most operators don't even try to do it. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax

Re: [DNSOP] RFC4641bis Section 4.4.5 proposed new text

and its addresses, a registrar switch is indistinguishable from a previously unnoticed attack based on a spoofed referral. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe

Re: [DNSOP] Potential root impact of draft-wing-behave-learn-prefix-00

So they are aware that this is broken. Let's hope that this type of service discovery through a fraction DNS root doesn't make its way into the final standard. would they complain if the roots actually provided an authoritative answer (other than NXDOMAIN) at some point in the

Re: [DNSOP] draft-dickinson-dnsop-nameserver-control-00

* TS Glassey: Be advised that the IETF process REQUIRES ME TO NOTICE THE IETF EACH TIME SOMETHING IS PUBLISHED WHICH INFRINGES ON THE PATENT, per the direct words of BCP78 and its supporting documents. So if you object take it up with the IPR WG and the IESG for making it mandatory for me to

Re: [DNSOP] The sad fate of T/TCP

). -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. I strongly oppose this approach. Unsolicited TCP has its place. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de

Re: [DNSOP] A different question

it on the responder side as well.) -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP

Re: [DNSOP] A different question

are basically at stage 0: denial that the problem exists. Not good at all. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

* Joe Abley: 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

* 黄理灿: If total number of PTR records is smail, that is right. But if most of IPv6 address space is used, one zone can not keep many PTR records. This will leads to many hierarchical zones. I don't think this is true. Even standard DNS servers scale to millions of records in a single zone,

Re: [DNSOP] Services and top-level DNS names

* Andras Salamon: ftp://ftp.rfc-editor.org/in-notes/rfc1535.txt Have you noticed that this document calls for the implementation of a public suffix lis? 8-) I routinely dot-terminate domain names and disable search lists, This doesn't work reliably with HTTP as deployed, by the way. I

Re: [DNSOP] Public Suffix List

* Gervase Markham: Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk, mypetstore.co.uk to supply them with ads. adserver.co.uk can set the ad-tracking cookie for .co.uk and build up a cross-site profile of a particular user, perhaps augmented by information passed to them by

Re: [DNSOP] Public Suffix List

* Ted Lemon: It's kind of assumed that you would be aware of these issues, I guess. But hardly anybody seems to be. Lots of web sites use cookies to associate a session with a particular user. With cross-site cookie theft, a malicious web site can gain access to your session cookie even

Re: [DNSOP] Public Suffix List

* Gervase Markham: If www.flirble.co.zz and www.widget.co.zz wished to conspire to track users across the two sites, they would simply both say that they are happy to accept co.zz cookies. Right now, they're sharing that bit of information through one of Google's web bug services.

Re: [DNSOP] Public Suffix List

* Brian Dickson: If you want grouping, there is a simple-to-code, reliable, and authoritative way to do so. Zone cuts (in DNS). This is an bad idea because introducing a new zone at an existing name should really, really be transparent to the rest of the world. (Thanks to configuration

Re: [DNSOP] Public Suffix List

* Jamie Lokier: E.g. When evaluating online.myservice.free.fr, Firefox could look up DNS records for online.myservice.free.fr, myservice.free.fr, free.fr and .fr (in that order), and if there's a record use that. If not, use the hard-coded information you have gathered for that domain.

Re: [DNSOP] Public Suffix List

* Stephane Bortzmeyer: On Mon, Jun 09, 2008 at 10:29:27AM -0400, Andrew Sulli5Avan [EMAIL PROTECTED] wrote a message of 52 lines which said: Is there any way to turn this off in Firefox 3? Switch to a free software browser without this very bad policy? http://www.konqueror.org/ Have

Re: [DNSOP] AS112 for TLDs

* Mark Andrews: There really is only one solution to preventing bogus traffic reaching the root servers and that is to run a local copy of the root zone. Or sign the root and use aggressive negative caching (which is currently prohibited by the RFCs, I'm told). I agree that

Re: [DNSOP] AS112 for TLDs

* Joe Baptista: I agree that information leakage is a problem. Curiously enough, no root server or TLD operators that I know of has published some sort of privacy statement that underlines how they deal with this issue. They are not the ones generating this traffic. Its users as they cross

Re: [DNSOP] DNS text in Enumservices guide...

* Alexander Mayrhofer: As mentioned in the session today, the Enumservices Guide contains some text on DNS Considerations in section 5.7: http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide The original reason for this text was the unused Enumservice, which conveyed assumptions

  1   2   >