Re: [DNSOP] Proposal: Whois over DNS

you mean something like this? https://www.isi.edu/division7/publication_files/novel_use.htm On Mon, Jul 8, 2019 at 2:39 PM John Bambenek wrote: > All- > > In response to ICANN essentially removing most of the fields in WHOIS for > domain records, Richard Porter and myself created a draft of

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

Actually if a DNS operator is requesting that NS records pointing to them be removed then the TLD only need to look at the enclosing SOA of NS’s address records to find a valid contact. As was pointed out to ICANN, the DNS operator is a party that needs to be listened to, and yes they have

Re: [DNSOP] Proposal: Whois over DNS

Below — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 8, 2019, at 20:01, Paul Wouters wrote: > On Mon, 8 Jul 2019, John Bambenek wrote: > >

Re: [DNSOP] Fwd: HTTPSSVC record draft

Thanks for the feedback. I'll add the DNAME clarification in the next version, as well as better explain the FQDN separation motivation. The alt-svc ALPN values come from rfc7838 (Alt-Svc) and rfc7301 (ALPN).

Re: [DNSOP] Obsoleting DLV

On Tue, 2 Jul 2019, Matthijs Mekking wrote: Here's a draft with discussion why also the protocol should go away. We would like to hear what you think about it. No objection. I'm not aware of any active private use of DLV. Thank you for doing the detailed work of looking up the citations and

Re: [DNSOP] Proposal: Whois over DNS

On Mon, 8 Jul 2019, John Bambenek wrote: An interresting idea, but   Domain contact information over DNS provides a vehicle for   exchanging contact information in a programmatic and reliable   manner. DNS has a ubiquitous presence within the internet   infrastructure and will act as a

[DNSOP] I-D Action: draft-ietf-dnsop-multi-provider-dnssec-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Multi Signer DNSSEC models Authors : Shumon Huque Pallavi Aras

Re: [DNSOP] Fwd: HTTPSSVC record draft

Hi, Erik, One minor issue is that wherever CNAME is referenced, you probably want to also include a reference to DNAME, including any implied or explicit chaining of CNAMEs (which could be sequences of CNAME and/or DNAME modulo their respective behavior.) It might be a little clearer if the list

Re: [DNSOP] Proposal: Whois over DNS

If there is no auth NS there is no whois. Acceptable limitation. In short term, no incentives. My hope is to get consensus, make it an RFC, then start encouraging auditors and the like to flag on it. But yes, it needs some critical mass of adoption or its just another idea on paper.

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

There’s a reason people are ignoring them. There’s no mechanism for validating such change requests nor checking that they are authorized. RFC 1033 was written in a rather different time. Sent from my iPhone > On Jul 8, 2019, at 5:34 PM, Mark Andrews wrote: > > The problem here is that

Re: [DNSOP] Proposal: Whois over DNS

On 2019-07-08 17:05 -0500, John Bambenek wrote:> For domains with no NS records? Who cares, they aren’t in actual use. (Or if they are something is broken or more likely malicious so block it). They could be (in use), at some point. See past "fast flux" cases. WHOIS was invented to be able

Re: [DNSOP] Proposal: Whois over DNS

> On Jul 8, 2019, at 2:52 PM, Steve Crocker wrote: > I'm not immediately persuaded the proposed solution, i.e. allowing > registrants to publish what they want via DNS records, will result in a large > amount of incorrect data. What's the motivation to publish wrong information > as opposed

Re: [DNSOP] Proposal: Whois over DNS

Yes, bifurcation of whois is a problem. I’d rather it all be in one place, but that door was closed and not by me. — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact

Re: [DNSOP] Proposal: Whois over DNS

For domains with no NS records? Who cares, they aren’t in actual use. (Or if they are something is broken or more likely malicious so block it). Yes, the onus is on domain owners (and that requires consensus and adoption which are not given but why its being brought up here). The registrars

Re: [DNSOP] Proposal: Whois over DNS

> On Jul 8, 2019, at 2:47 PM, John Bambenek > wrote: > > That is the weakness but if the third party vetting (which let’s be honest > consisted of sending an email to any address and seeing if someone clicked a > link) won’t be done anymore because registrars and registries refuse to do it

Re: [DNSOP] Proposal: Whois over DNS

Like I said, I’m ok with someone lying to me. Its easy to detect and easy to deal with. For instance, in DNS a mailserver could query these records, see phone number is set to 00 and then just reject email from said domain. With existing whois that was never possible, due to rate

Re: [DNSOP] Proposal: Whois over DNS

On 2019-07-08 16:38 -0500, John Bambenek wrote: In response to ICANN essentially removing most of the fields in WHOIS for domain records, Richard Porter and myself created a draft of an implementation putting these records into DNS TXT records. Not all registered domains are published

Re: [DNSOP] Proposal: Whois over DNS

John and Bill, Let me offer a slightly different perspective. The proposal would provide a way for domain name owners to publish information that they want published, and it would, of course, be publicly available. The pre-GDPR whois system collected contact information from registrants

Re: [DNSOP] Proposal: Whois over DNS

That is the weakness but if the third party vetting (which let’s be honest consisted of sending an email to any address and seeing if someone clicked a link) won’t be done anymore because registrars and registries refuse to do it under the guise of “privacy”, where else can you go for vetting?

Re: [DNSOP] Proposal: Whois over DNS

> On Jul 8, 2019, at 2:38 PM, John Bambenek > wrote: > > All- > > In response to ICANN essentially removing most of the fields in WHOIS for > domain records, Richard Porter and myself created a draft of an > implementation putting these records into DNS TXT records. It would require >

[DNSOP] Proposal: Whois over DNS

All- In response to ICANN essentially removing most of the fields in WHOIS for domain records, Richard Porter and myself created a draft of an implementation putting these records into DNS TXT records. It would require self-disclosure which mitigates the sticky issues of GDPR et al. Would love

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

The problem here is that there is no post delegation maintenance occurring. If you are no longer under contract to serve the zone you should be able to request the NS records pointing to your servers be removed. If the zone operator continues to list your servers in the zone you are able to

Re: [DNSOP] Fwd: HTTPSSVC record draft

On 08/07/2019 22:17, Erik Nygren wrote: For DNSOP folks, and ANAME proponents in-particular, I/we are especially interested in understanding if this would address enough of the customer use-cases driving ANAME were major browsers to implement support for HTTPSSVC, or would any limitations

Re: [DNSOP] Fwd: HTTPSSVC record draft

Ray, thanks for introducing this to dnsop! I've published a -03 with some of the feedback received so far: https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03 For DNSOP folks, and ANAME proponents in-particular, I/we are especially interested in understanding if this would address

Re: [DNSOP] proposal: Covert in-band zone data

W dniu 08.07.2019 o 22:30, Wessels, Duane pisze: > > >> On Jul 8, 2019, at 1:05 PM, Witold Krecicki wrote: >> >> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: >> >>> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow >>> handling of DNSSEC. That is, covert types

Re: [DNSOP] proposal: Covert in-band zone data

W dniu 08.07.2019 o 22:40, jab...@hopcount.ca pisze: > Hi Witold, > > On Jul 8, 2019, at 16:05, Witold Krecicki wrote: > > W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > >> One more thing - this feature is intended for operators, not for regular >> users. We should have more tolerance

Re: [DNSOP] proposal: Covert in-band zone data

Hi Witold, On Jul 8, 2019, at 16:05, Witold Krecicki wrote: W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > One more thing - this feature is intended for operators, not for regular > users. We should have more tolerance for shootfooting features there. I don't have anything extra to add to

Re: [DNSOP] proposal: Covert in-band zone data

> On Jul 8, 2019, at 1:05 PM, Witold Krecicki wrote: > > W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > >> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow >> handling of DNSSEC. That is, covert types should not be included in a zone >> digest. > > As I

Re: [DNSOP] proposal: Covert in-band zone data

> On Jul 6, 2019, at 4:46 PM, Joe Abley wrote: > TSIG secrets are rarely rolled in practice, in my experience, and > being able to improve upon that also seems useful. Very much agreed, whether using this mechanism or other. -Bill signature.asc Description:

Re: [DNSOP] proposal: Covert in-band zone data

W dniu 08.07.2019 o 21:01, Brian Dickson pisze: > What about using namespace instead of class or rrtype, or perhaps in > addition to that? > By making it an in-band thing but out-of-name-space, it makes it a > little more difficult to achieve self-immolation. > The namespace could be specified as

Re: [DNSOP] proposal: Covert in-band zone data

W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > > >> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote: >> >> >> As far as this particular idea goes, I mentioned before what had given me >> pause: we're talking about taking a protocol where every RRSet in a zone to >> date has been public and is

[DNSOP] I-D Action: draft-ietf-dnsop-aname-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Address-specific DNS aliases (ANAME) Authors : Tony Finch Evan Hunt

Re: [DNSOP] [homenet] Montreal homenet activities -- front-end-naming

Normen Kowalewski wrote: > apologies for this really very late reply, but FAIW it's IMHO not > really a "Synchronization Server", because the flow is really > hierachical - from home via the to-be-named-entity, and then to the > place tha scales out, like the slaves of that

Re: [DNSOP] proposal: Covert in-band zone data

On Mon, Jul 8, 2019 at 11:47 AM Witold Krecicki wrote: > W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at > 9:20 AM, Joe Abley wrote: > >> > >> > >> As far as this particular idea goes, I mentioned before what had given > me pause: we're talking about taking a protocol

Re: [DNSOP] proposal: Covert in-band zone data

Class is a bad idea for a few reasons, but principal among them in my mind is the fact that per section 4.2 of RFC 1034, the concept of zone is subordinate to the concept of class—even if zone cuts were in the same places, example. in a new class would still be a distinct zone from example. in

[DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis

I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to propose some additional text for the Security Considerations section in the spirit of this sentence from the abstract: "Future versions of this draft will contain descriptions of different minimisation implementation

Re: [DNSOP] proposal: Covert in-band zone data

W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote: >> >> >> As far as this particular idea goes, I mentioned before what had given me >> pause: we're talking about taking a protocol where every RRSet in a zone to >> date has been public and is made

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Monday, 8 July 2019 18:02:32 UTC Michael J. Sheldon wrote: > On 7/8/19 10:56 AM, Paul Vixie wrote: > > i've always sent back SERVFAIL when the zone isn't loaded, on either a > > primary or secondary (authoritative, that is) server. and i cache > > SERVFAIL on the recursive/iterative side with a

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Jul 8, 2019, at 2:11 PM, Michael J. Sheldon wrote: > I'm not authoritative for those. Any response I send for the parent > should be ignored completely. > And it still leaves the issue that I can't return a TTL without a > record, and I don't have a record to return it on. In the case of a

[DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Hi all, FYI from the ADD list, please post there or to the authors with feedback. Forwarded Message Subject: [Add] new draft: draft-grover-add-policy-detection-00 Date: Mon, 8 Jul 2019 11:29:02 -0700 From: Andy Grover To: a...@ietf.org Hello all, We've posted an initial

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:59 AM, Ted Lemon wrote: > BTW, it would also be perfectly legitimate for an authoritative server > that doesn’t provide recursion to respond with NXDOMAIN for any query > within a domain that’s delegated to it, But again, since you have no SOA to return, you have no record to

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 11:05 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > > > > The parent zone TTL would work fine. What parent zone??? .. ? com. ? I'm not authoritative for those. Any response I send for the parent should be ignored completely. And it still leaves the issue

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

The parent zone TTL would work fine. Sent from my iPhone > On Jul 8, 2019, at 2:02 PM, Michael J. Sheldon wrote: > > > >> On 7/8/19 10:56 AM, Paul Vixie wrote: >> i've always sent back SERVFAIL when the zone isn't loaded, on either a >> primary >> or secondary (authoritative, that is)

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:56 AM, Paul Vixie wrote: > i've always sent back SERVFAIL when the zone isn't loaded, on either a primary > or secondary (authoritative, that is) server. and i cache SERVFAIL on the > recursive/iterative side with a holddown timer equal to the negative TTL > interval (SOA.MINIMUM).

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Jul 8, 2019, at 1:27 PM, Michael J. Sheldon wrote: > I agree it's somewhat legit to answer for it, but it's a literal > maintenance nightmare when you're dealing with a very large number of > zones. Things like that tend to get put in place, then never removed. Right, but as I said, it’s dead

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Monday, 8 July 2019 16:42:39 UTC Michael J. Sheldon wrote: > ... > > If a record is requested from an authoritative server, where the zone does > not exist, generally the response is REFUSED, but *this is not cached* by > the requesting server. This results in a nearly continuous stream of >

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:13 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > >   > > On Jul 8, 2019, at 1:04 PM, Michael J. Sheldon > wrote: >> Neither solution >> is good, and the second one, while probably justifiable, does not feel >> "legit" to me,

Re: [DNSOP] proposal: Covert in-band zone data

> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote: > > > As far as this particular idea goes, I mentioned before what had given me > pause: we're talking about taking a protocol where every RRSet in a zone to > date has been public and is made available in DNS responses. Any server that >

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Jul 8, 2019, at 1:04 PM, Michael J. Sheldon wrote: > Neither solution > is good, and the second one, while probably justifiable, does not feel > "legit" to me, and results in longer-term data maintenance issues. So this is a former customer who stopped paying but still has a valid

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 9:50 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > >   > > On Jul 8, 2019, at 12:42 PM, Michael J. Sheldon > wrote: > To put it another way, if you get a REFUSED from a server, that server > is not authoritative for the name

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On Jul 8, 2019, at 12:42 PM, Michael J. Sheldon wrote: > If a record is requested from an authoritative server, where the zone does > not exist, generally the response is REFUSED, but *this is not cached* by the > requesting server. This results in a nearly continuous stream of retries, >

[DNSOP] Caching of negative zone (non-authoritative) responses

This is something that has bugged me for a long time, and I'd love to see a good solution to. If a record is requested from an authoritative server, where the zone exists, but the records does not exist, the negative response is cached for period of time. If a record is requested from an

Re: [DNSOP] proposal: Covert in-band zone data

Hey, On 6 Jul 2019, at 19:59, Witold Krecicki wrote: > But why put it out-of-band when it can be in-band? I don't think there's a good general answer to this. Sometimes in-band signalling is good; other times out-of-band signalling has proved to be safer. I'm talking very generally, here,

[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Extended DNS Errors Authors : Warren Kumari Evan Hunt

Re: [DNSOP] ANAME loop detection

if HTTPSSVC goes through, i think we can all stop talking about ANAME. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] default harden-algo-downgrade: off / RFC 4509 sec 3 update?

Hello, is there any document obsoleting RFC 4509 sections 3 and 6.1? https://tools.ietf.org/html/rfc4509#section-3 >Implementations MUST support the use of the SHA-256 algorithm in DS >RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 >digests if DS RRs with

Re: [DNSOP] ANAME loop detection

Matthijs, On Mon, Jul 8, 2019 at 11:47 AM Matthijs Mekking wrote: > >> Also what is wrong with an authoritative server already giving out more > >> optimal answers than just the ANAME and sibling address records? > > > > I also understand the sibling address records only as a mean to gap > > the

Re: [DNSOP] ANAME loop detection

Jan, On 7/8/19 11:32 AM, Jan Včelák wrote: > On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote: >> On 7/4/19 2:32 PM, Matthew Pounsett wrote: >>> I would say they should rely on that. Why shouldn't they? Isn't our >>> goal to get downstream servers to adopt the extension and do their own

Re: [DNSOP] ANAME loop detection

On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote: > On 7/4/19 2:32 PM, Matthew Pounsett wrote: > > I would say they should rely on that. Why shouldn't they? Isn't our > > goal to get downstream servers to adopt the extension and do their own > > lookup? The server-side lookups and sibling

Re: [DNSOP] [homenet] Montreal homenet activities -- front-end-naming

Hi Michael, apologies for this really very late reply, but FAIW it's IMHO not really a "Synchronization Server", because the flow is really hierachical - from home via the to-be-named-entity, and then to the place tha scales out, like the slaves of that entity. I think it is also not really a

[DNSOP] Fwd: HTTPSSVC record draft

For those not paying attention to the HTTP-bis working group, this DNS RR was proposed there last week. It appears to subsume the ALT-SVC proposal and also covers the use case I had in mind with my HTTP Record draft (i.e. CNAME at the apex). Given that it has someone from at least major